air - User contributions [en]

Proj-2013-2014-RobAIR-2/SRS

2014-04-09T08:28:28Z

RICM4-prj14-grp3: /* 2.4 General constraints */

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|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 [[Proj-2013-2014-RobAIR-1|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 [[RobAIR2013|here]].
* The page of the other RICM4 groups working on this project can be found here : [[Proj-2013-2014-RobAIR-1 | WebRTC group]]

* The UML of the project can be found [[RobAIR2013-RICM4-Groupe3-UML | here]].

==5.2 Sources ==
* An exemple of JAVA node to communicate with ROS by Rémi Barraquand: [https://github.com/PALGate/palgate-trial/blob/master/prima/knx_control/ http://github.com/PALGate/palgate-trial]

*The RobAIR 2012 project by Thomas Calmant: [https://github.com/tcalmant/robair/blob/master/trunk/platforms/wifibot http://github.com/tcalmant/robair]

The robAIR 2013 projects :

:- [[RobAIR2013-RICM4-Groupe1-Suivi | Group 1]]
:- [[RobAIR2013-RICM4-Groupe2-Suivi | Group 2]]
:- [[RobAIR2013-RICM4-Groupe3-Suivi | Group 3]]

==5.3 Licensing Requirements==
RobAIR will be released under a GPL license and will be open-source.

Proj-2013-2014-RobAIR-2

2014-04-09T07:45:06Z

RICM4-prj14-grp3: /* Project objectives */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]
* Our report : [[File:Projet-robAir.pdf|here]]

= Project objectives =

*Build the new robAIR with his new architecture and sensors
*Create a strong documentation in order to help future students and apprentices in robotics to build their own robot

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2

2014-04-09T07:44:24Z

RICM4-prj14-grp3: /* Project objectives */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]
* Our report : [[File:Projet-robAir.pdf|here]]

= Project objectives =

*Build the new robAIR with his new architecture and sensors
*Create a strong documentation in order to help future students and apprentices in robotics to build their own robots

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2

2014-04-09T07:44:12Z

RICM4-prj14-grp3: /* Project objectives */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]
* Our report : [[File:Projet-robAir.pdf|here]]

= Project objectives =

Build the new robAIR with his new architecture and sensors
Create a strong documentation in order to help future students and apprentices in robotics to build their own robots

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2

2014-04-09T07:32:53Z

RICM4-prj14-grp3:

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]
* Our report : [[File:Projet-robAir.pdf|here]]

= Project objectives =

Not decided yet (in progress...)

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2

2014-04-09T07:31:58Z

RICM4-prj14-grp3:

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]
* Our report : [[Projet-robAir.pdf|here]]

= Project objectives =

Not decided yet (in progress...)

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

File:Projet-robAir.pdf

2014-04-09T07:31:34Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:56:02Z

RICM4-prj14-grp3:

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|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, 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 [[Proj-2013-2014-RobAIR-1|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 [[RobAIR2013|here]].
* The page of the other RICM4 groups working on this project can be found here : [[Proj-2013-2014-RobAIR-1 | WebRTC group]]

* The UML of the project can be found [[RobAIR2013-RICM4-Groupe3-UML | here]].

==5.2 Sources ==
* An exemple of JAVA node to communicate with ROS by Rémi Barraquand: [https://github.com/PALGate/palgate-trial/blob/master/prima/knx_control/ http://github.com/PALGate/palgate-trial]

*The RobAIR 2012 project by Thomas Calmant: [https://github.com/tcalmant/robair/blob/master/trunk/platforms/wifibot http://github.com/tcalmant/robair]

The robAIR 2013 projects :

:- [[RobAIR2013-RICM4-Groupe1-Suivi | Group 1]]
:- [[RobAIR2013-RICM4-Groupe2-Suivi | Group 2]]
:- [[RobAIR2013-RICM4-Groupe3-Suivi | Group 3]]

==5.3 Licensing Requirements==
RobAIR will be released under a GPL license and will be open-source.

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:55:34Z

RICM4-prj14-grp3: /* 5. Appendices */

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|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, 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 [[Proj-2013-2014-RobAIR-1|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 [[RobAIR2013|here]].
* The page of the other RICM4 groups working on this project can be found here : [[Proj-2013-2014-RobAIR-1 | WebRTC group]]

* The UML of the project can be found [[RobAIR2013-RICM4-Groupe3-UML | here]].

==5.2 Sources ==
* An exemple of JAVA node to communicate with ROS by Rémi Barraquand: [https://github.com/PALGate/palgate-trial/blob/master/prima/knx_control/ http://github.com/PALGate/palgate-trial]

*The RobAIR 2012 project by Thomas Calmant: [https://github.com/tcalmant/robair/blob/master/trunk/platforms/wifibot http://github.com/tcalmant/robair]

The robAIR 2013 projects :

:- [[RobAIR2013-RICM4-Groupe1-Suivi | Group 1]]
:- [[RobAIR2013-RICM4-Groupe2-Suivi | Group 2]]
:- [[RobAIR2013-RICM4-Groupe3-Suivi | Group 3]]

==5.3 Licensing Requirements==
RobAIR will be released under a GPL license and will be open-source.

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:52:48Z

RICM4-prj14-grp3: /* 4. Product evolution */

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|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, 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 [[Proj-2013-2014-RobAIR-1|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. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:51:03Z

RICM4-prj14-grp3:

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|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, 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 [[Proj-2013-2014-RobAIR-1|here]])

'''Side-effects''':

=4. Product evolution=

=5. Appendices=

==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:49:11Z

RICM4-prj14-grp3: /* 2.2 Product functions */

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|This usecase]] is a more complete usecase of our project, offering more action choices.

==2.3 User characteristics==

==2.4 General constraints==

==2.5 Assumptions and dependencies==

=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 [[Proj-2013-2014-RobAIR-1|here]])

'''Side-effects''':

=4. Product evolution=

=5. Appendices=

==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:48:41Z

RICM4-prj14-grp3:

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|General uml of the project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|Detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

<gallery>
Image:usecase.jpg|Simple usecase
Image:RobAir2013-RICM4-UseCase.jpg|more complete usecase
</gallery>

 
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)
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot. 
[[Media:RobAir2013-RICM4-UseCase.jpg|This usecase]] is a more complete usecase of our project, offering more action choices.

==2.3 User characteristics==

==2.4 General constraints==

==2.5 Assumptions and dependencies==

=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 [[Proj-2013-2014-RobAIR-1|here]])

'''Side-effects''':

=4. Product evolution=

=5. Appendices=

==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:43:32Z

RICM4-prj14-grp3:

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

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [[RobAIR2013 | 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==

*Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]]
*The main page of the project: [[RobAIR2013 | RobAIR]]<br\>
*[http://en.wikipedia.org Wikipedia] for definitions.

==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 [[robAIR2013|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==

<gallery>
Image:DiagDeploymentRobAIR.png|general uml of our project
Image:Architecture_04_02.jpg|ROS architecture
Image:ArchitectureROS.jpg|detailed ROS architecture
</gallery>
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.
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project. 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS. 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail. 

==2.2 Product functions==

==2.3 User characteristics==

==2.4 General constraints==

==2.5 Assumptions and dependencies==

=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 [[Proj-2013-2014-RobAIR-1|here]])

'''Side-effects''':

=4. Product evolution=

=5. Appendices=

==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

=6. Index=

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:41:15Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:39:57Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:39:12Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2/SRS

2014-04-08T12:34:15Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2

2014-04-08T12:27:42Z

RICM4-prj14-grp3: /* Related documents */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to create your own robot : [[Proj-2013-2014-RobAIR-2/How_to_create_robAIR|here]]
* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]
* How to configure and launch your robot : [[Proj-2013-2014-RobAIR-2/How_to_configure_robAIR|here]]

= Project objectives =

Not decided yet (in progress...)

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:26:01Z

RICM4-prj14-grp3: /* Maps folder */

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {

 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :

== Bags Folder==

In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag

==Launch folder==

To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>

 <- Allows you to move the robot simply Keyboard ->

 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>

 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>

 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>

</launch>

Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML

==Maps folder==

The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:

http://wiki.ros.org/hokuyo_node

http://wiki.ros.org/hector_slam

Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .

== Msg folder==

It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:25:49Z

RICM4-prj14-grp3: /* Maps folder */

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {

 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :

== Bags Folder==

In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag

==Launch folder==

To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>

 <- Allows you to move the robot simply Keyboard ->

 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>

 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>

 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>

</launch>

Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML

==Maps folder==

The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node

http://wiki.ros.org/hector_slam

Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .

== Msg folder==

It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:25:32Z

RICM4-prj14-grp3:

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {

 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :

== Bags Folder==

In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag

==Launch folder==

To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>

 <- Allows you to move the robot simply Keyboard ->

 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>

 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>

 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>

</launch>

Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML

==Maps folder==

The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .

== Msg folder==

It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:24:51Z

RICM4-prj14-grp3:

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {

 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :

== Bags Folder==

In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag

==Launch folder==

To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>

 < - Allows you to move the robot simply Keyboard ->

 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>

 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>

 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>

< / launch >

Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:23:24Z

RICM4-prj14-grp3:

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {

 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :
== Bags Folder==
In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag
==Launch folder==
To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>
 < - Allows you to move the robot simply Keyboard ->
 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>
 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>
 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>
< / launch >
Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:23:13Z

RICM4-prj14-grp3:

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {
 NewPing (27 , 26, max_distance ) / / front left

 NewPing ( 2, 3, max_distance ) / / front center

 NewPing (4 , 5, max_distance ) / / front right

 NewPing (6 , 7, max_distance ) / / rear right

 NewPing (8 , 9, max_distance ) / / rear center

 NewPing (10 , 11, max_distance ) / / rear left

} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :
== Bags Folder==
In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag
==Launch folder==
To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>
 < - Allows you to move the robot simply Keyboard ->
 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>
 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>
 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>
< / launch >
Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:22:50Z

RICM4-prj14-grp3: /* Setting the Arduino sketch */

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.

We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~\arduino_sketches\infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .

Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:

NewPing sonar [ SONAR_NUM ] = {
 NewPing (27 , 26, max_distance ) / / front left
 NewPing ( 2, 3, max_distance ) / / front center
 NewPing (4 , 5, max_distance ) / / front right
 NewPing (6 , 7, max_distance ) / / rear right
 NewPing (8 , 9, max_distance ) / / rear center
 NewPing (10 , 11, max_distance ) / / rear left
} ;

Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .

=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :
== Bags Folder==
In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag
==Launch folder==
To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>
 < - Allows you to move the robot simply Keyboard ->
 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>
 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>
 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>
< / launch >
Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:22:01Z

RICM4-prj14-grp3:

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.
We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~ \ arduino_sketches \ infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .
Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:
NewPing sonar [ SONAR_NUM ] = {
 NewPing (27 , 26, max_distance ) / / front left
 NewPing ( 2, 3, max_distance ) / / front center
 NewPing (4 , 5, max_distance ) / / front right
 NewPing (6 , 7, max_distance ) / / rear right
 NewPing (8 , 9, max_distance ) / / rear center
 NewPing (10 , 11, max_distance ) / / rear left
} ;
Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .
=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :
== Bags Folder==
In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag
==Launch folder==
To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>
 < - Allows you to move the robot simply Keyboard ->
 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>
 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>
 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>
< / launch >
Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2/How to configure robAIR

2014-04-08T12:21:35Z

RICM4-prj14-grp3: Created page with "=Setting the Arduino sketch= Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to ma..."

=Setting the Arduino sketch=
Now for a very important step for the proper functioning of the robot. To retrieve all the information environment through sensors , we need to make a sketch on the Arduino board to turn. With it, the card will be traced all the necessary information.
We used when setting the robot infrared_and_ultrasound_mega.ino file found at the location ~ \ arduino_sketches \ infrared_and_ultrasound_mega .
We will begin to set our sketch . As a first step , we will set the global variables so that our number of sensors in the sketch correspond to the number of sensors in the robot . For this, we used the variable INFRA_NB and SONAR_NUM .
Then, we define an integer array to identify the pins on which we connected the infrared sensors:
const int INFRA_PINS [ INFRA_NB ] = { A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 } ;
Fat , we can see references pines on which we connected our sensors, we must adapt this part depending on the configuration of the robot.
For ultrasonic sensors , we define an array of NewPing corresponding to objects of type Ultrasonic Sensor:
NewPing sonar [ SONAR_NUM ] = {
 NewPing (27 , 26, max_distance ) / / front left
 NewPing ( 2, 3, max_distance ) / / front center
 NewPing (4 , 5, max_distance ) / / front right
 NewPing (6 , 7, max_distance ) / / rear right
 NewPing (8 , 9, max_distance ) / / rear center
 NewPing (10 , 11, max_distance ) / / rear left
} ;
Bold values correspond to the numbers of pins on which we connected the TRIG and ECHO our sensors in order that the . The following functions correspond to recovery algorithms basic data, which need to be changed if a particular behavior is desired .
=Description and configuration files=
We will see the most important file in the handling and control of the robot . So we'll see what they do and how to configure so that the robot is working properly :
== Bags Folder==
In this case it will find all files with extension. Bag . The " bags " are formats to store and replay the messages exchanged. This system is used to collect such data measured by sensors and then replay it as many times as desired to make the simulation with real data . This system is also very useful for debugging a system afterwards.
So every time we make a record card by the lidar , we will save the messages in this file format bag .
More information about the bag on the next page : http://wiki.ros.org/rosbag
==Launch folder==
To launch different scenario our robots, we need to use format files . Launch . A " launch " file is used to run multiple nodes / application and the ROS core command line .
A simple example file for keyboard navigation :
<launch>
 < - Allows you to move the robot simply Keyboard ->
 <node pkg="robair_demo" type="kb_control.py" name="kb_control"/>
 <node pkg="robair_demo" type="motion_control_node.py" name="motion_control_node"/>
 <node pkg="robair_demo" type="arduino_sensors.py" name="arduino_sensors"/>
< / launch >
Thus we see that in this launch, we will use the nodes kb_control , motion_control_node and arduino_sensors . Thereafter, we can complicate the launch by adding parameters to our nodes to perform the actions we desire.
More information on the launch on the next page : http://wiki.ros.org/roslaunch/XML
==Maps folder==
The maps folder is where all the maps generated will be recorded. The creation of maps can be done either with hokuyo_node node is the node hector_slam that exist for different versions of ros .
There are enough tutorials developed the following addresses:
http://wiki.ros.org/hokuyo_node
http://wiki.ros.org/hector_slam
Thus, during the execution of the node creation map, we can create and save a file type . Yaml representing our map. The background idea is that any data YAML can be represented by a combination of lists, tables ( hash ) and scalar data . YAML described forms of these data ( YAML representations ) , and a syntax to present these data as a character stream ( stream YAML ) .
== Msg folder==
It is in this folder that we will position the files that define the names of all parts of the robots :
===file Command.msg===
In this file , it was possible to set all the movements of our robot :
int8 move
uint8 speed1
uint8 turn

=== encoderData.msg file===
In this file, it has been defined the names of our two wheels
int32 Wheelright
int32 wheelLeft

===InfraredPotholes.msg file===
In this file , it has been defined names infrared sensors . Infrared sensors were defined as Boolean . This boolean is set to True if there is a hole, False otherwise. They were named as follows :
bool rear_left
bool rear_center_left
bool rear_center_right
bool rear_right
bool front_left
bool front_center_left
bool front_center_right
bool front_right

===UltrasoundObstacles.msg file===
As InfraredPotholes.msg folder, it has been defined in this file ultrasonic sensors. The value of these sensors correspond to the distance they have an obstacle. They were named as follows :
uint32 north_left
uint32 north_right
uint32 NORTH_EAST

uint32 south_left
uint32 south_right
uint32 south_east
Thus, if we want to build a robot with more sensors , either infrared or ultrasound, or add movements, it is these files that we are going to touch .
==Rviz_cfg folder==

In this case, we have all the configurations rviz program, which will be used to display the map that we create the lidar . However, the extension is vcg type and extension of the current configuration files rviz program is . Rviz . So we have to redefine a configuration file.
==Script folder==

In this case, we have all the script files that will turn on our shelf , and serve the functioning of our robot .
=== kb_control.py===
Here are defined keys that serve to move forward, backward or turn the robot . It will modify this file if we want to use different keys.

===motion_control_node.py===
This file corresponds to the node control the robot. We will have to check properly configure the port or the controller is connected .
===arduino_sensor.py===
This file corresponds to the node management sensors . It will also verify that the port is correct sensors .
==Src folder==
===Arduino.py===
In this file, we have all the functions to handle the sensors. The two main functions are:
process_infrared_line
This function will loop through all the infrared sensors of the robot, and update the value of these sensors.
process_ultrasound_line
This function is similar to the previous one, but it works on ultrasonic sensors.
===keylogger.py===
This file is used to record the information entered on the keyboard. It is not necessary to modify this file .
=== motorcmd.py===
send_order : Function to send a move command to the robot
isFrontSensorsOK : Function that checks if no obstacle / hole interferes with the movement of the robot forward
isRearSensorsOK : Function that checks if no obstacle / hole gene robot motion backwards
move: Sending order the robot to move

==Util folder==

Configuration file on the local IP and serial ports. We did not change these file, because the work had been done the previous year and operating correctly
==Voice folder==

In this case, we set all the audio files that serve the robot when it moves and meets a person or another . Audio files must be wav category.

=Starting the robot=

We will launch the robot command line using scripts . We often use the run.sh script, which will give rights to different ports (sensors and motor control ) and launch a launch scenario .
Before starting the robot , check that all controllers and sensors are correctly connected and that they have the rights to operate.

Proj-2013-2014-RobAIR-2

2014-04-08T12:07:57Z

RICM4-prj14-grp3: /* Week 11 (March 31th - April 4th) */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]

= Project objectives =

Not decided yet (in progress...)

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR hardware, so that the connecting branches are clean
*Repairing of the wheel that is not working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2

2014-04-08T12:07:22Z

RICM4-prj14-grp3: /* Week 10 (March 24th - March 28th) */

= Introduction =

The Robair project aims to develop a platform for robotic telepresence used for both teaching ambient intelligence and testing low cost (ie well below the price of market platforms) of service robotics in real environments. This platform aims extensible and open source (open software, open hardware, open design, open data).

More information on Project [[RobAIR]]

= Team =

*Tutors : Didier Donsez, Amr Alyafi

*Members : David Levayer, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Related documents =

* How to install ROS and run your first package : [[Proj-2013-2014-RobAIR-2/getStarted|here]]

= Project objectives =

Not decided yet (in progress...)

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[Proj-2013-2014-RobAIR-2/SRS|here]].

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - January 19th) ==
*Project discovery
*Research on related projects (previous years: [http://air.imag.fr/index.php/RobAIR2013 2013], [http://air.imag.fr/index.php/RobAIR2012 2012])
*Learning of ROS: [http://www.ros.org/ Official website]

== Week 2 (January 20th - January 26th) ==
*Learning of ROS (in progress)
*Installation of ROS packages on Ubuntu (in progress)
*Assembly of two new RobAIRs (they will be named soon...) (in progress)

== Week 3 (January 27th - February 2nd) ==
*Assembly of two new RobAIRs (they will be named soon...)
*Beginning of the redaction of Software Requirements Specification
*ROS environment installed on Ubuntu
*RobAIR can now move by itself ! (debug in progress)
*Meeting with Amr Alyafi (effective code obtained)

== Week 4 (February 3rd - February 7th) ==
*Integration of basic sensors (infrareds and ultrasonics)
*Debug of Amr Alyafi code (a lot of variable are written directly in the code, so it's not portative at all...)

== Week 5 (February 10th - February 14th) ==
*Installation and configuration of Arduino IDE
*Basic sketch test ( diode, sensor )
*Meeting with Amr Alyafi in order to check if everything is plugged and installed corretly
*Switch Meduino card to Arduino Mega 25.60 card in order to solve transfer problems
*Implementation, debug and test of arduino sketches and ros code using only one ultrasonic sensor
*RobAIR works! http://www.youtube.com/watch?v=g5XhrDY0tFI&feature=youtu.be

== Week 6 (February 17th - February 22th) ==
*Installation of 5 other ultrasonic sensors
*Adaptation of arduino code and ros cos for our installation ( with pin and trigger numbers )
*Debug
*All sensors finally work
*Presentation of RobAIR at Polytech Open Day the 22th

== Week 7 (February 24th - February 28th) ==
*Installation of 8 infrared sensors
*Adaptation of arduino code and ros cos for our installation ( with pin trigger numbers )
*Debug ( in progress )

== Week 8 (March 10th - March 14th) ==
*Mid-Project presentation in order to check the advanced
*Final debug of infrared sensors
*Installation of lidar with library

== Week 9 (March 17th - March 21th) ==
*We tried several package, and Hokuyo Node was the best one.
*Lidar works, but isn't doing what we expected, there is only cloud point and it's not generating a sort of map.
*We are currently working on RVIZ configurations, because previous configs was cfg files and not rviz files.

== Week 10 (March 24th - March 28th) ==
*Still working on rviz and lidar, trying to figure out why we cant get map from the lidar
*Rework on the script to launch robAir, in order to use our config on Hokuyo and RVIZ

== Week 11 (March 31th - April 4th) ==
*Scripts are finished
*Rework on the robAIR Hardware, so that the connecting branches are clean
*Repairing of the wheel that isnt working properly
*Meeting with Amr Alyafi in order to know how the lidar is working to generate a map
*It seems like we cant generate a map with lidar, so we will try to use a kinect

== Week 12 (April 7th - April 9th) ==
*Trying to install Kinect, but it's currently not working
*Finalisation of everything, in order to have a clean project for the presentation
*Creation of presentation, flyer, poster

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T12:05:10Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|thumb|center|Battery used in our robot]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|thumb|center|Mounting of batteries]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[Image:Branchement_carte_moteur.png|400px|thumb|center|Connection the engine board]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|thumb|center|Infrared sensor]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|thumb|center|Mounting the infrared sensors]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|thumb|center|Ultrasound sensor]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|thumb|center|Mounting the ultrasound sensors]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|thumb|center|Robot overview]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|thumb|center|Final rending of the map]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|thumb|center|Placing the lidar]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|thumb|center|Connecting the ultrasound]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|thumb|center|Connecting the infrared]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|thumb|center|Connecting sensors to the shield]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T12:02:05Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|thumb|center|Battery used in our robot]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|thumb|center|Mounting of batteries]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[Image:Branchement_carte_moteur.png|400px|thumb|center|Connection the engine board]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|thumb|center|Infrared sensor]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|thumb|center|Mounting the infrared sensors]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|thumb|center|Ultrasound sensor]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|thumb|center|Mounting of wheels]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T12:01:09Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|thumb|center|Battery used in our robot]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|thumb|center|Mounting of batteries]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[Image:Branchement_carte_moteur.png|400px|thumb|center|Connection the engine board]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|thumb|center|Infrared sensor]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|thumb|center|Mounting of infrared sensors]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|thumb|center|Ultrasound sensor]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:59:51Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|thumb|center|Battery used in our robot]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|thumb|center|Mounting of batteries]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[Image:Branchement_carte_moteur.png|400px|thumb|center|Connection the engine board]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|thumb|center|Infrared Sensor]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:58:06Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|thumb|center|Battery used in our robot]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|thumb|center|Mounting of batteries]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[Image:Branchement_carte_moteur.png|400px|thumb|center|Connection the engine board]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]
[[Image:Roues_robot.png|400px|thumb|center|Mounting of wheels]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:53:23Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|thumb|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:51:42Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center|Devantech RD02]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:49:50Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|300px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:49:10Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|400px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|300px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:48:44Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|400px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|600px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|400px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:47:16Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|400px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg|400px|center]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png|400px|center]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png|400px|center]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg|400px|center]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png|400px|center]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg|400px|center]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png|400px|center]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg|400px|center]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg|400px|center]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png|400px|center]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png|400px|center]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png|400px|center]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg|400px|center]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:45:52Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|400px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|300px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:45:39Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|300px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png|300px|center]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:45:28Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|300px|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:45:04Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[Image:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[Image:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[Image:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[Image:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[Image:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[Image:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[Image:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[Image:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[Image:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[Image:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[Image:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[Image:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:44:22Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg|center]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[Image:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[File:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[File:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[File:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[File:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[File:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[File:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[File:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[File:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[File:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[File:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[File:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[File:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:43:19Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[Image:Devantech-rd03-24v-robot-drive-system-a.jpg]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[File:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[File:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[File:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[File:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[File:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[File:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[File:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[File:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[File:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[File:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[File:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[File:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[File:Branchement_shield.jpg]]

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:42:17Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[File:Devantech-rd03-24v-robot-drive-system-a.jpg]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[File:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[File:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[File:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[File:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[File:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[File:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[File:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[File:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[File:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[File:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[File:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[File:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors:

[[File:Branchement_shield.jpg]]

File:Branchement shield.jpg

2014-04-08T11:41:50Z

RICM4-prj14-grp3:

Proj-2013-2014-RobAIR-2/How to create robAIR

2014-04-08T11:40:00Z

RICM4-prj14-grp3:

We will present all the steps of mounting the robot. The model of the structure was created by Didier Donsez , professor at the University Grenoble 1 and in particular Polytech'Grenoble .

=Mounting wheels=

Our robot will use a propulsion system 24V type robot Devantech RD02 presented below:

[[File:Devantech-rd03-24v-robot-drive-system-a.jpg]]

We 'll climb the two wheels on the underside of the base of our robot with the screws that were provided . For stability, we will add multidirectional wheels at the front and rear so that the robot can move properly. Here is a photo montage :

[[File:Roues_robot.png]]

Driver Robot System 24 V RD03 Devantech RD03 is a powerful robot control system , consisting of a DC Motor Controller MD49 - 24V 5A Devantech , two 24V Gear Motor with encoder , two mounting brackets, two 125 mm wheels with hubs already set. Screws to attach the motors to the brackets and a hex wrench to screw the hub are included. Only a 24V battery is needed to power the system. The MD49 is controlled with a series of logic level port, as well selectable 9600 to 38,400 baud. The MD49 has two modes of operation, direct individual motor control or the ability to send commands to speed and steering .

=Installation of batteries=

The batteries we have chosen to use are 12V batteries from Yuasa brand:

[[File:Yuasa-batteries.jpg]]

We subsequently positioning the battery stands on the base of the robot and the battery placed in the following manner :

[[File:Batteries.png]]

We will then connect in series via connectors and directly on the engine controller as follows :

[[File:Branchement_carte_moteur.png]]

The wheels are then powered by the battery via map . In addition, the motors are connected directly to the card , which will link information to the tablet via the connector that we can see on the right.

=Determination of sensors =
To continue with the installation of our robot , we will fix all the sensors that will be used later on our structure. We have two different types of sensors : infrared sensors on the basis of the structure , and the ultrasound sensors fixed on the sides of the structure .
== Infrared sensors ==
The infrared sensors are Arduino switch adjustable infrared sensor to detect 3 -80cm Type :

[[File:Ultrasound.jpg]]

The switch of the infrared sensor is an adjustable set of the transmitter and receiver to a photoelectric switch of sensors . The detection distance can be adjusted depending on the application . The sensor has a detection range from 3cm -80cm . The output switching signal is different depending on obstacles . It remains high when no obstacle is low when there are obstacles.
We will fix the structure through the rings provided with sensors:

[[File:Infrarouge_wiki.png]]

== Ultrasonic sensors ==

Our robot will use ultrasonic sensor HC- SR04 we can see below :

[[File:Capteur-ultrason-hc-sr04.jpg]]

This module simply has 4 output pins : VCC, trig , ECHO, GND . It is very easy to interface to a microcontroller . The entire process is as follows :
*Put the pin " TRIG " a high level pulse (5V ) for at least 10us and the module starts reading
*At the end of the extent, if detects an object in front of him , the pin " ECHO" goes high (5V) " PulseIn ()" .
* The remote location of the obstacle is proportional to the duration of this pulse . It is very easy to calculate this distance.

We have established the structure as follows :

[[File:Capteur-ultrason.png]]

= Installing the Kinect =
In our implementation , we did not use the Kinect camera, but as it will be used in subsequent iterations , we decided to place it. Given that the Kinect camera will enable remoting . We must place it on top of the robot, so it is an overall view of the room, just above the tablet support :

[[File:Photo_robot.jpg]]

It will be directly connected to the tablet via USB hub.

= Positioning Lidar=
During the movement of the robot, we dynamically construct a map showing the room. The final result will look like this :

[[File:Map.jpg]]

To do this, we need to place the Lidar on top of the substrate as follows :

[[File:Lidar.png]]

Lidar we used is sensor type Distance Scanning Laser URG- 04LX - UG01 Hokuyo. The Scanning Laser Rangefinder URG- 04LX - UG01 Rangefinder is a small , affordable and accurate laser scanner which is perfect for robotic applications. The URG- 04LX - UG01 is capable of indicating the distance of 20 mm to 5600 mm ( 1 mm resolution ) in an arc of 240 ° ( angular resolution 0.36 °) . It will be connected directly to the tablet via USB hub.

=Connecting sensors to the Arduino board=

Connection of sensors on the Arduino board is a very important step in the assembly of our robot, bad connections on the pins may cause a malfunction of the robot. Here is a precise ultrasound sensor diagram :

[[File:Ultrason.png]]

Thus we see that to connect the sensors to the Arduino board , we need to connect the VCC pin to power the Arduino board , the pin corresponding to the emission of ultrasound or the TRIG pin to output , corresponding to the spindle receiving the ECHO signal to an input pin , and finally to the ground pin GND of the Arduino .
We will have to ensure noted pines on which the TRIG and ECHO are connected, because we will need to configure the Arduino sketch based .
Digital sensors also have 3 son connection : a 5V supply (usually red wire) , ground wire (green wire) and the output value (yellow wire).

[[File:Infrarouge.png]]

Three son are connected as follows :
- Red wire sensor 5V : 5V (power) Arduino (+ on the shield )
- Green wire sensor GND : GND (ground) Arduino ( - on the shield )
- Yellow wire sensor output : DIGITAL INPUT (DIGITAL) Arduino (S on the shield )

Please note once again the digital inputs used as the Arduino sketch strongly depends .

Here's a final photo of the connection of sensors: