Embedded Motion Control 2013 Group 7

Approach to be used:

Strategy -> Software architecture -> Work division -> Test

Group members

Jordy Senden, 0716539, j.p.f.senden@student.tue.nl, Mechanical Engineering, NL

Erik van Broekhoven, 0637413, e.c.v.broekhoven@student.tue.nl, Mechanical Engineering, NL

Luigi Corvino, 138588, l.corvino@student.tue.nl, Mechatronics Engineering, IT

Martin Huberland, 131492, m.huberland@student.tue.nl, Mechanical Engineering, BE

Marcello Di Giandomenico, 138554, m.digiandomenico@student.tue.nl, Mechatronics Engineering, IT

Tutor: Jos Elfring

Meeting #1 - 9/9/2013

Topic:

• Introducing with group members (Background, C-knowledge)

• Installed required software / solved software issues

• Refreshing C language knowledge

• Started to work on the tutorials

• Set-up a meeting with our tutor

• Set standard meeting days on monday and thursday afternoon

Meeting #2 - 12/9/2013

• Meeting with our tutor

• Installed gazebo software

• Solved remaining software issues

• RECAP 12/9/2013

To do before next meeting: read the ROS concepts on the EMC website.

Meeting #3 - 16/9/2013

• Thinking about strategies for the corridor competition

• RECAP 16/9/2013

Meeting #4 - 18/9/2013

• Concluded the work on the strategy
• Started implementing some basic functionalities
• RECAP 18/9/2013

Meeting #5 - 30/9/2013

• Decide once for all the modular software architecture
  • Choose modules, nodes, inputs and outputs to split the work (30/9)
  • Think about a initialization function that corrects PICO's orientation.
  • Think about a function that restores the motion after an avoided collision from the safety measures.
• Choose the maze solving strategy
  • Choose between the simplest approach, i.e. right wall following, and the most complex one, SLAM.
• Split up the group according to the required functionalities of PICO

Meeting #6 - 7/10/2013

• Started working on new line detection algorithm
• Started working on image acquisition
• Started working on decision making node

Strategies

Corridor competition

For the corridor we decided to develop a simple code, possibly recyclable for the maze navigation. This deadline is a required step in order to really get our hands dirty and acquire some familiarity with C++ programming and ROS.

The robot has to stay approximately in the middle of the corridor, which has been divided into a safe zone and a dangerous zone. PICO compares two distances measured from the laser scans and based on their difference it will correct its orientation by rotating to the left or to the right. During this this rotation a small forward velocity is fed to the base in order to get a smooth movement. When he detects the exit, he starts the turning maneuver.

At the end we decided to change our turning method. The exit detection remained the same, after this we changed the turning maneuver into a more safe movement as the previous one was successfully at the 50%. Comparing the scan ranges Pico is able to compute the distance to the exit center and the exit amplitude, so we use some counters in the code in order to define exactly the time needed for decided velocities to reach the wanted position. In this way Pico's movements depend on the environment and should not go wrong and hit the walls.

The Competition(25/09)

Today is the day. We used our "safety" code: not the fastest, but we were nearly sure that PICO would find the exit. In fact, he managed to within 38 seconds. This gave us the 4th place.Unfortunately we had no time to test efficiently the code on Pico in order to achieve bigger velocities. We still have a lot of work to do, but this result is really encouraging. We also noticed that our wall following function needs to be improved as Pico seems to be 'drunk' while moving. Here is a little view of the competition: https://vimeo.com/75465839

Maze solving

Jazz robot comes with complete compatibility with ROS. For further information: Gostai Open Jazz.

After the corridor competition we decided to spend one week trying the different solutions proposed during a brainstorming. In order to solve the maze, two main different approaches can be used: a complex one, involving real time map building, localization and path planning, and a simple one, involving wall following and easy decision making.

For the first approach, different tools already exist: for instance, rviz+Navigation stack. In the beginning for the second approach we thought about developing the corridor competition strategy, but after some work on it we understand that is really difficult to achieve our goal in this way, in fact in the maze there are different configurations to be aware of, and using this code everything can be compromise by the smallest error. Our exit detection needs to scan the next wall with a 30° angle at least and so cannot be accurate because of the various and insufficient wall lenghts.

However the simplest, but quite efficient strategy (on paper) we decided to adopt is the right wall following with the aid of camera's arrow detection. This won't let us achieve the fastest time in the final competition, but has a certain robustness (the maze has no islands, and following the right wall will lead PICO to the exit for sure, in absence of failures) and it's easier to implement, thus avoiding waste of time and resources in trying to understand difficult concepts about SLAM. So we opted to use a better organized method with different ROS nodes and line detection, this can help us handling efficiently the possible occurring situations.

We can focus on basic programming problems and on software modularity. We decided to use four ROS nodes even if some say that this is not useful, not because we want to complicate our job but to help us understand how ROS nodes work. Basically, our robot must be able to detect different type of junctions and move accordingly. The goal is thus very simple at first glance, and could be handled by using a "blind navigation" approach towards the environment (the walls), consisting in reading the local information about the surroundings with the laser and acquiring and processing images to help PICO find his way. Solving algorithms, like Trémaux, will be implemented only if we have time.

Line and corner detection

...

Brain node

This node merges the information sent by camera topic and from the line detection node in order to turn in the right way.

The priority is to read the camera information; if there's none, turn right if possibile. In case of dead end, turn 180° and keep following the right wall.

Arrows detection

...

Software architecture

A first rough structure of our software can be represented in the following image:

We decided to change it and reduce the number of nodes, since not all of them are strictly necessary.

Work division

• Eric -> Image acquisition
• Jordi -> Line detection algorithm
• Martin -> Line detection algorithm, Camera
• Marcello -> Software architecture, inputs/outputs, custom messages, nodes
• Luigi -> working on previous algorithm

Tests

First test (19/9)

Experiments are performed on PICO, however the testing did not go as planned. PICO had to be resetted sometimes and did not respond to our commands as expected. The data shown in the terminal however, did show the proper values while running.

Second test (20/19)

We experienced again some connection issues. We were able to move the robot, and again some delay seemed to occur. The discharged batteries have put a premature end to our tests.

Third test (24/9)

We had 15 minutes to verify our new code, developed in a few hours of this very day, that allows PICO to turn on the spot. Everything worked fine, but improvements have to be made to get a more robust algorithm and, most of all, a fastest one: the turning maneuver is too slow.

Links

Wall following algorithm