Embedded Motion Control 2014 Group 12

Introduction

Members of group 12

Groupmembers (email all)
Name:	Student id:	Email:
Anthom van Rijn	0737682	e-mail Anthom
Jan Donkers	0724801	e-mail Jan
Jeroen Willems	0755833	e-mail Jeroen
Karel Drenth	0863408	e-mail Karel

Corridor Challenge

The goal of the corridor challenge is to make pico drive autonomously trhough a corridor, recognize a T-junction successfully, and have it take the appropriate corner.

Planning

Week 1

• First Lecture

Week 2

• C++ tutorials
• ROS tutorials
• SVN tutorials
• Run the first test on pico (safe_drive.cpp) to get some hands-on experience.

Week 3

• Start the actual coding, based on the safe_drive.cpp file. Paying special attention to robustness and exceptions.
• Have pico recognize situations (corridor, corner, t-junction,dead-end, etc.) and act accordingly
• Have the script succesfully run in simulation

Week 4

• Fine tuning of script
• Corridor Competition

Software Architecture

The initial choice was made to first create a robust, well working robot that would successfully recognize a situation using only the laser data, and then take an appropriate action. In this case, it's assumed that all junction/corners are right handed, although it should equally work for left handed situations.

Situation recognition

Goal: to successfully recognize a pre-programmed situation and take the appropriate action corresponding to it.

Recognize a corridor (action: keep on driving)

Recognize a T-junction (action:take a right turn

Recognize a corner (action: take the corner

Recognize a crossing (action: take a right turn

Recognize the exit (keep on driving, then stop).

Robustness

As can be seen, it is important to calibrate the ranges of the laser data to make sure that the situation is evaluated correctly. If this is done wrong, the situation might be evaluated incorrectly and PICO might come to a halt (due to a hard constraint) and be unable to continue. To illustrate this, below are some possible pitfalls and the solution.

To avoid measuring the laser range of the wall behind the closest wall (due to a gap), an average of data points is taken. This way, if the gap isn't to big, the closest wall will always be noticed,

Due to whatever reason (for instance, not completely straight walls to begin with) PICO can find itself being positioned at an angle within a corridor. When this happens, the action to keep on driving, will eventually lead to a collision with the wall. To prevent this, PICO will actively measure it's relative pitch and will try to correct for this. Some bounds are implemented to allow for a little deviation of the pitch, to assure that PICO's actuators do not show chattering like behaviour.

A disadvantage of being reliant on proper tuning is shown in the picture above. If the tuning is done wrong, PICO will steer itself in a position in which it is unable to perform the proper action. For example, in the picture above, if PICO would now try to take the corner at exactly the same way as it did before, it would get to close to the left wall and the hard constraint would kick in, resulting in a standstill. Because of this, it is important to test extensively and to make sure all the situations are recognized correctly and the actions are properly tuned.

Another example of what would happen if the tuning is not done correctly. In a widened section, PICO could now decide to take a right turn followed by a left one, to follow the right wall, in stead of simply continuing to drive forward.

As can be seen in the figures above, it is quite difficult to use only the laser range data to figure out the situations and still be robust for all the things that can be encountered. While the presented situations are good enough for a simple corridor challenge, other alternatives should be considered when regarding finding the way through a maze, for the reliance on proper tuning isn't good practice when writing code.

Experiments

• 09-05-2013

Tested the provided safe_drive file, making small alteration to see the effects on Pico. Tested how hard constrains are handeld and some different safety protocols.

• 13-05-2013

Tried, and failed, to run corridor_challenge_v2 due to numerous bugs in the script (most importantly: stuck in situation zero, unsure what to do). Received help from tutor regarding tips and tricks regarding Qt creator for debugging, building/making C++ in ROS and running simulations. Information was used to create a "how to start: Pico" tutorial. Remainder of time spent on bugfixing.

Change log

09-05

Created scipt corridor_challenge.cpp with basic siteval to recognize conditions

13-05

• Testing corridor_challenge on Pico.

With new input from experiments: updated the corridor_challenge.cpp to corridor_challenge_v2.cpp. Brought the function sit-eval withing the callback loop for sensor messages. This way, the situation is evaluated and updated whenever new laser data is present. Some minor typo's. Added a situation that when things are to close (hard constraint) pico shuts down. After testing it was revealed that pico is stuck in condition 0 (does not know where he is).

15-05

• Revised corridor_challenge_v2.cpp -> renamed to corridorchallenge_v2.cpp and added some new functions:
• Extended laser 'vision' with left- and right diagonal view and updated amount of laser data used for each 'vision' vector.
• Extended the amount of possible situation PICO can be in to nine. Currently using:

- Corridor
- T-Junction (L+R)
- Crossing
- Corner (L+R)
- Dead End
- Exit

• Added a function that compares the left and right laser data and 'strafes' PICO to the middle using the y coordinate.
• Added an 'integrator'-like function that aligns the front vector of PICO to the walls of the corridor.
• Included front laser data to this function to ensure 'backup' when PICO comes too close to a wall.
• Added corresponding functions to new situations.
• Tweaked variables to ensure functioning simulations. (Allowance of some initial angle with reference to wall 'disturbance'). PICO is currently able to pass corridors, T-junctions and corners, for this however, the amount of possible situations PICO can be in is reduced for the sake of simplicity.

Final Design

The final design that was used was corridor_challenge_v2. It's goal was to use the laser data to recognize one of 9 conditions (ranging from freedom, corridor) and act in a preprogrammed way (outside of the loop) on how to handle these, and then turn on the loop again.

Result

Due to some unforeseen circumstances, corridorchallenge v3 failed to load on PICO. We resorted back to v2, which, while less robust, was still able to find the t-junction and act accordingly. The result was a first place in the "limited speed" category, with a time close to 20 seconds.

Maze Challenge

The goal of the Maze Challenge is to have PICO drive autonomously through a maze and successfully navigate itself towards the exit. There are three major assumptions

• (1) The Maze is two dimensional (all the walls, as well as the entrance and exits are on the ground floor level. There is no way to go either up or down).
• (2) Both the entrance and the exits are on the outer edge of the maze.
• (3) The maze does not change with time.

While these assumptions might seem redundant, they are of major importance when determining the strategy

Planning

Week 5

• Group meeting discussing the new strategy to finish solve the maze challenge
• Start coding on the line detection script

Week 6

• Debugging and finalizing the line detection script
• Beginning with coding the function for map generation
• Beginning with function to combine line detection with a situation evaluation

Week 7

• Lecture

Week 8

• Lecture

Software architecture / Road map

When regarding the designed software from the corridor competition, it became apparent that simply reading out the laser range data and comparing it against a set of reference values to determine the current situation was not really a robust solution. A better alternative would be to recognize lines surrounding PICO, instead of data points, and use this information to evaluate the situation.

(1) Line recognition of the upcoming junction, which is also robust against small gaps. The point where the two lines intersect is stored for later use. (2) Pico continous to drive until a second line (down the corridor) can be plotted. The point where the second line of the junction and the corridor meet is saved. The two saved points can now be used to estimate the corridor width. (3) Finally, with the width known, an arc is plotted around the corner of the corridor, allowing PICO to go around the corner. Because of the way the new trajectory is plotted, the corner may vary in width while PICO will still be able to end up in the middle of the corridor.

Experiments

22-05

• Found and tweaked the previously used script corridor_challenge_v2, based on new calculations. While it did work for one turn, a new calculations showed a situation where an error would occur when taking two turns successively. This turned out o also be true in practice, which again shows the importance of calculations and proper simulation.
• Experienced a new bug that would make PICO disconnect from the server for no apparent reason.
• Recorded a bag-file for line detection.

28-05

• Tested a new line detection script

Final result

PICO succesfully found the exit