Embedded Motion Control 2013 Group 5

Group members

Name:	Student ID:
Arjen Hamers	0792836
Erwin Hoogers	0714950
Ties Janssen	0607344
Tim Verdonschot	0715838
Rob Zwitserlood	0654389

Tutor:
Sjoerd van den Dries

Planning

Weekly meetings

DAY	TIME	PLACE	WHAT
Monday	11:00	OGO 1	Tutor Meeting
Monday	12:00	OGO 1	Group meeting
Friday	11:00	GEM-Z 3A08	Testing

Deadlines

DATE	TIME	WHAT
September, 25th	10:45	Corridor competition
October, 23th	10:45	Final competition
October, 27th	23:59	Finish wiki
October, 27th	23:59	Finish peer review

Progress

Figure 1:Coordinate system for PICO

Figure 2: Line detection OpenCV

Figure 3: Structure ROS

Figure 4: Graphical representation of drive-straight node

Figure 5:Strategy, steps for driving

Fig 6:Different types of junctions

Week 1 - 2

Week 1:

• Installed the software.

Week 2:

• Did tutorials for ROS and the Jazz simulator.
• Get familiar to 'safe_drive.cpp' and use this as base for our program.
• Defined coordinate system for PICO (see Figure 1)

Week 3 - 4

Week 3:

• Played with the Pico in the Jazz simulator by adding code to safe_drive.cpp.
• Translated the laser data to a 2d plot.
• Implemented OpenCV
• Used the Hough transform to detect lines in the laser data.
• Tested the line detection method mentioned above in the simulation (see Figure 2).
• Started coding for driving straight through a corridor (drive straight node)
• Started coding for turning (turn node)

Week 4:

• Reorganize our software architecture after the corridor competition
• Created structure of communicating nodes (see Figure 3)
• Finish drive straight node (see Figure 4)
• Finish turn node
• Started creating a visualization node

Week 5 -6

Week 5:

• Finish visualization node
• Started creating node that can recognize all possible junctions in the maze (junction node)
• Started creating node that generates a strategy (strategy node) (see Figure 5)
• Tested drive-straight and turn node on Pico, worked great!

Week 6:

• Finished junction node (see Figure 6)
• Started fine tuning strategy node in simulation
• Tested visualization and junction node on Pico, worked fine!

Week 7 - 8

Week 7:

• Finished strategy node (in simulation)
• Tested strategy node on Pico, did not work as planned
• Did further fine tuning of strategy node

Week 8 []

Software architecture

The software architecture is shown in figure 3. In this section the architecture is explained in more detail. First we present an overview of all nodes, inputs and outputs. Then the most challenging problems that have to be tackled to solve the maze and the solutions are discussed.

Overview nodes

The software to solve the maze is build around the strategy node. This node receives all the information that is needed to solve the maze, and sends information to the nodes that actuate Pico. An overview of all nodes is given below. The column "PROBLEMS SOLVED" give a short description of the problems that are solved in the node, more information about the solution can be found in the chapter Problems and solutions

NAME	INPUT	OUTPUT	PROBLEMS SOLVED
Strategy	*Laser data *Junction data *Turn data	*Command for left, right or straight	*Finding the next best step
Junction	*Laser data	*Type of junction	*Junction recognition
Turn	*Command for left, right or straight *Laser data	*Velocity command	*Localization *Control turning motion
Drive straight	*Command for left, right or straight *Laser data	*Velocity command	*Localization *Control straight drive motion
Arrow detection	*Odometry data	*Command for left or right	*Arrow recognition

Problems and solutions

The main problem in this course is making sure that Pico can solve a maze. This problem can be divided into sub-problems, these are explained here. On this page a short description of the problem and the answer is given. The more detailed description can be found by clicking on the title.

Localization

Problem: Localization is a problem in which Pico needs to determine what the geometry of its surrounding. More specific, for the purpose of solving the maze, the walls surrounding Pico must be identified based on the laser data.
Solution:

Drive trough a corridor

Problem:
When Pico is located in a corridor, it needs to drive trough the corridor until a junction appears at his path. The problem is to let Pico move trough the corridor, preferebly in the middle of the corridor but at least without hitting the wall.

Solution:
Figure 4 is an example of a situation of Pico in the corricor. The current position (p1) of Pico is the intersection between the blue and red line. The orientation of Pico is displayed by the blue line. The red line connents the current position (p1) with the reference point (p2). The error angle, which is given by the difference between the current angle of Pico and the reference angle. This error angle is used as control input fot the velocity of Pico.

Algorithm:

1) Sort vector of Walls such that theta1<theta2<...<thetaN

2) Select the first entry of vector as right wall and last entry of vector as left wall.

3) Define a fixed frame (x0,y0,z0) on the left wall. x0 at left wall pointed in driving direction, y0 perpedicular to wall, pointed inwards to Pico, z0 along right hand rule.

4) Define position Pico (p1) in (x0,y0,z0) coordinates

5) Define angle Pico in (x0,y0,z0) coordinates

6) Define reference point (p2) in (x0,y0,z0) coordinates

7) Definieer referenceangle phi from (p1) t0 (p2) in (x0,y0,z0) coordinates

Assumptions:

1) Pico starts with his “face” pointed inside the corridor.

2) The referencepoint (p2) is positioned at the middle of the corridor, 1 meter ahead of Pico’s current position.

Example:

Junction recognition

Next, the data gathered from the laser range finder (LRF) is converted into a set of lines using the hough transform. Here, each line is represented by a radius (perpendicular to the line) and an angle w.r.t. reference line. The top view of the robot with these parameters are depicted in figure 7. Using these angles, we can identify the walls that are located to the left and to the right of PICO by sorting the data received from the hough transform by angle. We now know the location and orientation of the left and right wall w.r.t. PICO.

Before we transform the LRF data using the Hough function, we check at which type of surroundings we are dealing with. There are a number of possibilities, which are displayed in figure 8.

Using the laser range data, we can distinguish these situations by analyzing their values. Each situation has an unique amplitude-angle characteristic. We can generalize variations on the situations by assuming that a junction exit will reach a scanning range value above r_max. Setting the limit at r_max and thus truncating the scanning values will return characteristic images for each junction type:

figure t-splitsing/tim

If the average value (angle) of the truncated tops reach setpoint values (i.e. 0, 90, 180 degrees) w.r.t. the y axis we know what kind of junction we are dealing with. Now that we can identify the type of surroundings, we can tell if we have to navigate in a straight manner (corridor) or if we need to navigate towards an exit. With this information we can send messages to our motion node.

Up till now we have only used local positioning of PICO. No global mapping algorithm was implemented. This can be done by projecting maps on top of each other and aligning these with waypoints or markers. Since we are dealing with slip we have to add margins to these waypoints (e.g. circles) because the waypoints will not align exactly. An idea is to use a map without physical dimensions. This can best be represented by a tree structure, where the bottom of the tree is the starting point of the maze and the exit is in one of the branches. If we keep track of the junction types and orientation where we have been (where the branches split), we can rule out the investigated branches in the next run. The investigated branches can be identified by storing the spot and orientation of the junction by means of a "compass". Although simple in nature (just storing the junctions, orientation, location and wheter or not they have been chcked), it is hard to identify loops (If there are multiple ways (corridors) to reach the same junction). With no anti-loop mechanism they will be viewed as a new branch of possible solutions. If this is an actual problem, global mapping / localisation is required.

References

• A. Alempijevic. High-speed feature extraction in sensor coordinates for laser rangefinders. In Proceedings of the 2004 Australasian Conference on Robotics and Automation, 2004.
• J. Diaz, A. Stoytchev, and R. Arkin. Exploring unknown structured environments. In Proc. of the Fourteenth International Florida Artificial Intelligence Research Society Conference (FLAIRS-2001), Florida, 2001.
• B. Giesler, R. Graf, R. Dillmann and C. F. R. Weiman (1998). Fast mapping using the log-Hough transformation. Intelligent Robots and Systems, 1998.
• Laser Based Corridor Detection for Reactive Navigation, Johan Larsson, Mathias Broxvall, Alessandro Saffiotti http://aass.oru.se/~mbl/publications/ir08.pdf