Proj-2013-2014-RobAIR-2/SRS

From air
Jump to navigation Jump to search

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


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 a tablet. It can also be used for disabled so that they can follow their courses behind home.
  • 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.
  • 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.
  • 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

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 the project

    General uml of the project

  • ROS architecture

    ROS architecture

  • Detailed ROS architecture

    Detailed ROS architecture

As mentioned earlier, RobAIR 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

    Simple usecase

  • More complete usecase

    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 developped 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, 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.

Functional, non-functional and interface requirements

Function: - Create a map of the current environment - Locate the robot with accuracy - Allow automatic and semi-automatic movements in regards of the environment (obstacles, stairs, dogs, etc...)

Description:

  • The map is dynamically established thanks to both tablet and camera sensors.
  • Using the accelerometers, gyroscope and compass, RobAIR is able to locate himself with accuracy. This way, it can avoid obstacles.

Inputs:

  • Robot state messages.
  • Data about the current location, the environment, the speed, orientation, etc

Source:

  • Robot sensors
  • Tablet sensors
  • State and problems given by the robot

Outputs:

  • Map with current location of the robot
  • Instructions and state changing orders

Destination:

  • RobAIR in order to operate itself
  • The remote controller
  • The tablet monitor

Action:

  • The user must be able to control the robot displacements.
  • The tablet interface shall access to external data.
  • The robot must move in its environment without troubles ( avoiding obstacles )
  • The map must be really accurate in order to give a good overview of the position of RobAIR


  • 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 or dogs.

Pre-condition:

  • Last version of RobAIR
  • A tablet with required sensors and ROS environment
  • A LDAP camera sensor

Post-condition:

  • RobAIR is controlled by the remote user using Skype (more information here)

Side-effects:

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.
  • The page of the other RICM4 groups working on this project can be found here : WebRTC group
  • The UML of the project can be found here.

5.2 Sources

The robAIR 2013 projects :

- Group 1
- Group 2
- Group 3

5.3 Licensing Requirements

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

Retrieved from "https://air.imag.fr/index.php?title=Proj-2013-2014-RobAIR-2/SRS&oldid=17037"