Embedded Motion Control 2014 Group 8
Jump to navigation Jump to search
This is the WIKI of group #8.
1. 1080 laser points for distance measurement
Below, the structure of the program is explained.
The Master file is the file which is taking control over everything that happens. Within the master file, there are the options that should be checked and actions that should be performed. The checking action "Detection" is constantly sending (with a frequency of 20 Hz) information to the master. The information which is sent is whether there is; nothing special, a corner, a corridor, a T-junction, a plus-crossing or a dead end.
For extra clearity, the movies below shows the nodes in use while PICO is running.
For the PICO to be able to drive straight to the corridors a “drive straight” component is implemented. This is used when no walls are critically close and no corners are detected yet. To do so first of all the ranges of N odd points, which are equally distributed over the frontal view of the robot, are evaluated. When any of these ranges is less than a certain treshold, the angle with the nearest wall is calculated. Therefor the smallest range of the set is selected, and it is assumed this represents the distance perpendicular to the wall. This is depicted in the left situation in the picture below where N=7, the use of the dashed lines is explained later. Now the angle θ is calculated with the use of the smallest range and the range straight ahead which are presented in red. When this angle is known the angular velocity is controlled with a PD controller which forces θ to zero. This basic controller equals: ω = P*θ + D*θ’. To calculate the time derivative of θ, a first order linear differential equation is used.
To drive safe is the main task of this project. For this reason it is always checked (if just driving forward, in a turn, etc.) whether or not a wall is too close. There are four possible cases of too close:
In the first two cases, the robot drives backwards and turns to the right (in the first case) or to the left (in the second). In the second two cases the robot keeps driving but steers to the right (in the third case) or to the left (fourth case).
The differences between several laser points are used to detect openings. On both sides five laser points diagonally to the front and diagonally to the rear are used, as well as five laser points straight ahead. When the difference between all the askew frontal and rear points are larger than some threshold, an opening is detected. Note that five laser points are used for robustness. If one or two laser points would go through a hole in the wall, no opening should be detected. The difference between the two points is taken in order to use relative distances instead of absolute ones. Otherwise a new corner could be detected whenever a distance is large, for example in a large open field.
Ideally a crossing is detected as in the left figure below: at both sides an opening is detected as well as the opening straight ahead. However, if PICO arrives in a direction not exactly parallel to the wall one side opening is detected first, as will be the case in practical situations. Therefore, if a side opening is detected, a new set of laser point (the green area in the right figure below) checks for an opening at the other side too. If so, a crossing is found.
If a single corner to the left or to the right is found without any other options, these corners should obviously be taken. But if, in case of a corridor, T-junction or crossing,where multiple options are available, a choice has to be made whether a corner should be taken or not. If an arrow is detected which points to a direction which is not an option for the pico (if there is no corner found in that direction), the arrow is neglected. This is for driving more robustly if the corner detection misses any corners. If an arrow is found which points to a direction in which a corner is found, the pico always follows the arrow, regardless of any previous choices made or any other strategic considerations.
Take the corner
Once there is decided that a corner or u-turn should be taken, a subfile is called from the master file. The input for this subfile is wheter the corner is to the right, to the left or a u-turn. In case of a u-turn, the pico simply spins approximately 180 degrees and continues driving in the opposite direction.
These are the steps taken by 'arrowDetection':
In the tests there was a problem. Arrows were detected at a too large distance from the arrow (see "Fourth test" on this wiki). This problem is solved by implementing two different sizes of arrows. The bigger template of the arrow is recognized if Pico is close to the arrow, the smaller if Pico is further away. Now at a way larger range an arrow can be detected. Also a history buffer that saves observed arrows for several iterations is added. This history buffer makes the algorithm more robust against "false positives". This was needed because false positives were detected. If in the last, for example, 6 iterations 5 arrows to the left, and 1 to the right are detected, it is possible the arrow to the right (the wrong arrow) is sent to the master node. After implementing the buffer, this problem was solved.
Algorithm to solve the maze
In order to complete the maze as fast as possible the program uses a fixed strategy. When the robot detects a situation where it can continue in multiple directions it chooses a preferable one. This decision is made based on two parameters, namely which options it detects and whether or not an arrow is observed.
During each test session, several things are tested seperately and observations are done. This chapter is about the logging of all the information.
First test [15/05/2014]
The first goal was to survive the corridor test. This means any corner, left or right, should be detected and taken without any collosion.
Global tactic (inserted in both programs):
However, the second tactic seems to work quite okay and will thus be used for the corridor competition
Corridor test [16/05/2014]
Unfortunately there was not enough time to implement the observations in the code. The second method is used and the corridor was passed in 32 seconds.
second test [21/05/2014]
In the second test the new safety driving, the new corner detection and the straight driving have been tested. The method to detect a corner was adjusted. Where earlier corners were detected with only one laser point, the new corner detection got a lift. They are detected via the subtraction of five laser points at the side and five laser points at the side a bit more backwards. Parameters such as the difference and the position of these laser points which are used are tuned within this meeting.
Third test [05/06/2014]
After a new strategy for driving straight was proposed, this was tested on the setup. The new PD controller worked properly after being tuned. Also the new method for taking corners and ensuring safety while doing so was tested with satisfying results. Thereafter the u-turn was tested and tuned however this yielded a problem. After turning 180 degrees the PICO can stand under an angle with respect to the wall. When there is a short distance to the next (T-)crossing there may not be enough time to counteract this. When PICO is still not nearly parallel to the wall at this time an opening can be missed, this could send PICO in the wrong direction.
Fourth test [12/06/2014]
Here we started to test the arrow detection in real life. We ran into some problems regarding its robustness, the arrows were not always recognized. Thereby, if the were recognized, it was at a too large distance. By the time the Master node requested the arrow direction it was not detected any more.
Fifth test [19/06/2014]
Here we fine tuned some thresholds for the arrow detection. In the previous test we only looked for the color red on one side of the spectrum. When this was altered the arrow detection was robust.
Sixth test [25/06/2014]
In the final test we fine tuned the thresholds for the situation recognition. Resulting in a robuster detection of corners, crossings, dead ends, etc.
Finally, the real maze challenge. The goal; drive as fast as possible through the maze.
When we arrived at the challenge, we saw the maze. Yes, we will solve it. But unfortunately the first crossing will not be taken efficiently. The corridors are too large to detect dead ends before driving in there.
Review on this challenge;
On behalf of group 08;
As depicted in the file above, the master file is the file which activates other files and which the other files answer to, but doesn't perform any actions itself. This file keeps looping the entire time, as long as all the hardware and software keep working correct. In every loop, the first thing the master node does is activiting the file which checks for corners or dead ends. This file answers with an integer, which stands for a corner to the right, left, dead end, corridor, T-junction or crossing. Also every loop a file for the arrow detection is called upon, which checks for arrows and stores the results. This file returns a integer, which stands for an arrow to the left, to the right or no arrow found.
This is the first file called every iteration from the master file. It has no inputs and checks for corners as described above. It returns an integer to the master file with information on what corner type is found: T-junction, crossing etc.
Arrow detection is built into a different node than the rest of pico's controllers. This is to make sure that the image processing is not interfering with the pico driving controllers. The master node can subscribe to the image processing node on the topic 'arrowDetection'. ArrowDetection is posting '0' if no arrow is found, 1 if a left arrow is found and 2 if a right arrow is found.
When the arrow detection node is started, it begins processing the camera topic of pico.
The strategy file is called by the master file in case a corner is detected. It takes two integers as input; one for the type of corner and one for the arrow detection. It returns an integer to the master file with an option to make the corner to the right, left or drive straight ahead.
This file is called by the master in case a corner has to be taken. It takes an integer with the option for a corner to the right, left or u-turn. The file keeps calling the safety file twice (one for the left side of the pico and one of the right side) to check if the pico is at a safe distance of the walls. As long as the safety file returns true, this files makes the corner for a fixed amount of time. If the safety file returns false, this file adds a side velocity to the pico away from the wall. The file gives no output back the the masterfile
This file is called by both the drive file (see below) and the make corner file. It takes 2 integers and a double as input; first a number for the laser where the file should start checking the distance, a number for the laser where the file should stop checking the distance and a double which represents the threshold for which the pico is safe or not. By including the start and stop number for which laser should be checked, this file allows the other files to only check certain areas relative to the pico (left, right, ahead, etc). The file returns a boolean saying if the pico is safe or not.
This file is called by the master in case the pico should just drive straight. It takes no input and gives no input back to the master file. In the file, first the laser values are read and, when needed, action is taken to prevent collision. When nothing is detected below a certain threshold, the pico can focus on driving straight. Thesefore a new file is called.
This file is called from the drive file and takes no input nor returns an output. It uses the PD controller to keep the pico straight.