|
|
| (20 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| = Archive =
| | ksajdfkjdsakjfkjakjfdkajkfjadkfdjfkajdakjffdsakjfakjadsf |
| This page is part of the [http://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2015_Group_3 EMC03 CST-wiki].
| | kajdfkjdakdakjf |
| | kdasjfjdakfajkaj |
| | akjsdfffffffffdddddddddddddddddddddddddddddddddddddddddddd |
|
| |
|
| | ksajdfkjdsakjfkjakjfdkajkfjadkfdjfkajdakjffdsakjfakjadsf |
| | kajdfkjdakdakjf |
| | kdasjfjdakfajkaj |
| | akjsdfffffffffdddddddddddddddddddddddddddddddddddddddddddd |
| | ksajdfkjdsakjfkjakjfdkajkfjadkfdjfkajdakjffdsakjfakjadsf |
| | kajdfkjdakdakjf |
| | kdasjfjdakfajkaj |
| | akjsdfffffffffdddddddddddddddddddddddddddddddddddddddddddd |
|
| |
|
| == Old idea of dealing with doors == | | {|style="margin: 0 auto;"|right|thumb |
| If no exit is found under the assumption that there are no doors, the robot starts checking for doors. See Figure 1 for different possible situations of where the doors are located. At first it assumes that there can only be doors at dead ends (1). If still no solution is found the robot also checks for doors at corners (2), followed by intersections (3) and finally on every outside wall of the currently mapped maze. In order to detect these doors the robot stands in front of the potential door for a certain time and checks with its sensors whether the distance to the nearest wall changes.
| | | [[File:Originaldata.png|250px|thumb|right|Calibration: Difference between odometry and LRF data]] |
| | | | [[File:StaticLRF.png|250px|thumb|right|alt=Static LRF|Calibration: Static LRF]] |
| [[File:Corridorlayout.png|400px|thumb|center]] | | |} |
| | |
| == Old uncertainties ==
| |
| Certain aspects of the design are not yet clear due to uncertainties in the specifications of the robot and/ or the maze challenge.
| |
| Depending on the difference between the end of the maze and the inside of the maze, the robot may be enabled to detect it has completed the challenge. If however the outside of the maze is simply an open space similar to a place inside the maze, the robot might not be able to distinguish the difference. In this case the robot would have to be stopped manually.
| |
| | |
| The exact specifications of the robot are still unknown and without testing the precise accuracy and range of the sensors, the resolution of the map and the safe wall distance are unknown.
| |
| | |
| In order to make the robot complete the challenge faster control over the speed of the robot could be used. This way it could move faster in area’s it has already mapped. This is only possible if the robot has the capability of moving at different speeds.
| |
| | |
| == Old drive method - to drive through corridors ==
| |
| Going straight in a corridor is done by checking the closest points at the left-hand and right-hand side of the corridor, since this will be where the wall is perpendicular to the robot. Based on that, it checks what the correct angle for driving should be (difference between left and right angle). Then, it calculates the deviation from the centerline of the corridor, and based on a desired forward speed, it calculates a movement vector. Finally, it translates this vector to the local robot driving coordinates. It should be noted that the Drive class is not responsible for deciding whether it's driving in a corridor, so this particular algorithm is not robust for corners, intersections etc.
| |
| | |
| Taking a corner is done by looking at the two corner points of the side exit. Then, it tries to orient the robot to bisect the angle between those corner points, while maintaining forward speed. This way, a corner will be taken. The main vulnerability here is taking the corner too narrow, so a distance from the wall will be kept.
| |
