SRS RobAir RICM Group

overview of the robot

This document describes the software requirements specification of the project RobAIR2013.

Document History

	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	January 27th, 2013	Laurène Guelorget	First draft	Morgan bidois	February 8th, 2013
	0.1.1	January 29th, 2013	Morgan bidois	First draft	Thomas Nunes	January 29th, 2013
	1.0.0	January 31th, 2013	Morgan bidois	Definitions 1.3 & some reference 1.4	Thomas Nunes	January 1st, 2013
	1.0.1	February 1st, 2013	Thomas Nunes	General description 2.1 to 2.5	Morgan bidois	January 4th, 2013
	1.1.0	February 4th, 2013	Morgan bidois	Evolution 4 & specific requieremnt 3	Thomas Nunes	January 4th, 2013
	1.1.1	February 7th, 2013	Laurène Guelorget	Scope	Morgan bidois	February 8th, 2013
	1.2.0	February 7th, 2013	Thomas Nunes	3.1 requierement	Morgan bidois	January 7th, 2013
	1.3.0	February 8th, 2013	Morgan bidois	appendices 5 & complete part 2	Thomas Nunes	January 8th, 2013
	2.0.0	February 11th, 2013	Thomas Nunes	Merge of two SRS for a group of 6.	Laurène Guelorget	February 12th, 2013
	2.0.1	February 17th, 2013	Laurène Guelorget	Appendices & Evolution of the product	Thomas Nunes	February 17th, 2013
	2.1.0	February 17th, 2013	Laurène Guelorget	Images & corrections	Thomas Nunes	February 17th, 2013
	2.1.1	February 17th, 2013	Thomas Nunes	1.5, 5.3, 2.1	Laurène Guelorget	February 17th, 2013

1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for the robot RobAIR.
In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

• The product we are developing is a telepresence robot that can be used for museum tours and the user will be able to guide the robot with an Android tablet.
• It is a low cost robot (well below the maket price).
• The platform and software used for this robot are extensible and open-source.

1.3 Definitions, acronyms and abbreviations

• Roaming: It ensures that a wireless device is kept connected to the network, without losing the connection.

• XML: (Extensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.

• XMPP: (Extensible Messaging and Presence Protocol) is a communications protocol for message-oriented middleware.

• P2P: Peer-to-Peer Protocol is an Application-layer protocol that can be used to form and maintain an overlay among participant nodes. It provides mechanisms for nodes to join, leave, publish, or search for a resource-object in the overlay.

• Jingle: Jingle is an extension to XMPP which adds peer-to-peer (P2P) session control for multimedia interactions like videoconferencing communication.

• ROS: (Robot Operating System) It is a software framework for robot software development.

• Jitsi: It is a videoconferencing and instant messaging application developed in JAVA and using XMPP/Jingle.

• telepresence: It is refers to a set of technologies which allow a person to feel as if they were present, to give the appearance of being present.

• Wiimote: It is the primary controller for Nintendo's Wii console. A main feature of the Wii Remote is its motion sensing capability,which allows the user to interact with and manipulate items on screen.

• Ubuntu: is a computer operating system based on the Debian Linux distribution and distributed as free and open source software, using its own desktop environment.

1.4 References

• differents progress pages:

- Roaming

- Operating system

- Multimedia interface page.

• The main page of the project: RobAIR2013<br\>
• Wikipedia for definitions.
• OSGi tutoriel by Didier Donsez. Version: 08/04/2005
• LibJitsi for sources, tutoriel and support for visioconferencing

1.5 Overview of the remainder of the document

The rest of the SRS examines the specifications of the robAIR2013 project in details. Section two of the SRS presents the general factors that affect the robAIR and its requirements, such as user characteristics and project constraints. Section three outlines the detailed, specific and functional requirements, performance, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

2. General description

2.1 Product perspective

• 

  general uml of our project

• 

  ROS architecture

• 

  detailed ROS architecture

As mentioned earlier, the RICM's RobAIR2013 project is part of a larger system consisting of the assembly of the robot (by the 3I4 students) and the ENSIMAG's RobAIR project.
The project interacts with a STM card linked with a serial connection to transmit orders to the robot.
The ensimag project consists of the development of a platform to reserve a robot.

This UML diagram is the general UML, representing the different parts of the project.
This global diagram represents how the different parts of the project are connected through ROS.
This detailed diagram explains the ROS architecture of the project in detail.

2.2 Product functions

• 

  simple usecase (in French)

• 

  more complete usecase

The robot interface functions:

- Control the robot

- See where the robot goes

- Know where is the robot

- Have a feedback on the robot state (battery level, problems encountered)

- Display data about the robot environement to get a feedback (robot velocity, position on the map)

This usecase is a simple usecase of our project (in French), representing the list of interactions between the user and the robot.
This usecase is a more complete usecase of our project, offering more action choices.

2.3 User characteristics

The user doesn’t need to be familiar with programming and doesn't need a specific formation. <br\> He just needs to know how to use a tablet and a television. <br\>

2.4 General constraints

• Platform constraints:

- ROS must operate on an Ubuntu platform.

- Tablet's controller interfaces are devlopped for the Android platform.

• Environemental constraints:

- Wifi with Internet access for the robot and for the controller.

- The robot can’t climb up steep slopes.

2.5 Assumptions and dependencies

- The robot site has wifi access in all the visit area.

- A 3D map of the visit site is provide.

- The robot knows the position of its base.

- The robot base can be accessed at any time.

- The robot can estimate the battery life time to know where he needs to go back at its base.

3.Specific requirements

• Document external interfaces,
• Describe system functionality and performance
• Specify logical database requirements,
• Design constraints,
• Emergent system properties and quality characteristics.

3.1 Functional, non-functional and interface requirements

Function

- Control a robot and interact with videoconferencing.

- Establish the communication between the robot and the server.

- Establish the communication between the server and the robot.

Description

links between the robot and the user's tablet

This diagram explains how the robot and the user's tablet are communicating.

• The user controls the robot with the tablet and a server is connected to the smartTV.
  
• Commands are sent to the server with websockets and then the server transmits these to the robot with XMPP.
  
• The videoconferencing between the robot and the server uses XMPP and Jingle extensions.
• The Server displays video and some data about the robot state like the battery level.
• The tablet interface can display external data like a plan, wiki pages, etc.

Inputs

- Robot state message.

- Problems encountered.

- Extra documentation (wiki pages, open street map plan).

- Video for videoconferencing.

Source

- The robot provide data about its state and problems.

- Internet for external documentation.

- The video come from camera and WebCam.

Outputs

- Video on robot screen and on the Smart TV.

- Robot state indicators.

Destination

- Users front the SmartTV.

- People meeting the robot.

Action

• The Robot must inform the user in case of troubles.
• The user must be able to control the robot deplacements.
• The user mustn't lose connection with the robot.
• The Interface shall be user-friendly.
• The video has to be in good quality.
• The tablet interface shall access to external data.

Non functional requirements

• The robot navigate in a safe area without dangers like:

- Cars circulation,

- Constructions,

- Young children.

• Nothing hides cameras in the robot or on the SmartTV.

Pre-condition

• materials conditions:

- A RobAIR 2013 connected in the selected place.

- A ubuntu server connected to a display device and a camera.

- A android tablet.

• Software conditions:

- Install the RobAIR2013-Server software on the ubuntu server.

- Install the RobAIR2013 android application.

Post-condition

The robot is controlled by the user front of the SmartTV with the tablet.
The user can do videoconferencing with people who met the robot.
The user has data feedback on the robot state and it’s environement.

Side-effects

• Connected people.
• Allow intervention of specialist at distance.

4. Product evolution

- Use several tablets (with only one main tablet controlling the robot).

- Ability to read QRcodes and display related contents on the tablet.

- A vocal interface like a GPS.

- Control the robot thanks to a neuronal device.

- Switch between different robots.

- Thanks to a lidar, the robot makes its own map.

- 3D visioconferencing with the treament of two video stream.

- ...

5. Appendices

5.1 Specification

• The global project's page can be found here.
• Three RICM4 groups are working on this project. Here are their wiki page:

- Group 1

- Group 2

- Group 3

• The UML of this project can be found here.

5.2 Sources

• An exemple of JAVA node to communicate with ROS by Rémi Barraquand: http://github.com/PALGate/palgate-trial

• The RobAIR 2012 project by Thomas Calmant: http://github.com/tcalmant/robair

5.3 Licensing Requirements

RobAIR will be released under a GPL license and will be open-source.