SRS RobAir RICM Group

This document describe 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

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 [1] for definitions.

1.5 Overview of the remainder of the document

???

2. General description

2.1 Product perspective

The product is a part of the RobAIR platform and interacts with other components through ROS.

2.2 Product functions

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)

2.3 User characteristics

The user don’t need to be familiar with programming and don't need a specific formation. <br\> The interface must be simple and intuitive.

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 users know how to use a tablet.

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

3.Specific requirements, covering functional, non-functional and interface requirements

• document external interfaces,
• describe system functionality and performance
• specify logical database requirements,
• design constraints,
• emergent system properties and quality characteristics.

3.1 Requirement X.Y.Z (in Structured Natural Language)

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:

• 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 have to be in good quality.
• The tablet interface shall access to external data.

• Natural language sentences (with MUST, MAY, SHALL)
• Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
• Mathematical Notations
• Tabular notations for several (condition --> action) tuples

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 have data feedback on the robot state and it’s environement.
Side-effects:

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

4. Product evolution

- Using some Tablets with one main which control the robot

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

- A vocal interface like a GPS

5. Appendices

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.

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