Mobile Robot Control 2023 Group 6
Group members:
| Name | student ID |
|---|---|
| Xingyi Li | 1820443 |
| Alexander De Pauw | 1877267 |
| Timo van Gerwen | 1321854 |
Exercise 1: The art of not crashing
Before performing tests with the robot, being BOBO, the laser data of the robot is looked at. First of all, some noise can be seen on the laser data as visualized by rviz. Especially objects further away, with the range of the lasers being a couple of meters. Objects that can be seen by the robot are solid objects around 10cm from the ground up. Objects that are either higher or lower are not in the range of the lasers. Black objects as well as glass objects are hard to observe due to light absorbance and light refraction respectively instead of reflection. Human legs can also be observed. The robot sees just above the ankles from one side, therefore it sees legs as half circles.
Simulation
Code is written in dont_crash.ccp to have the robot move forward until it detects a wall closely in front of itself. To make sure the robot only stops when a wall is in front of the robot, only the laser data within 30 degrees to both the left and the right of the robot are considered. The dont_crash file can be found in exercise1/src/dont_crash.ccp. Note that this code has an extra step because of which the robot will stop and turn until the path forward is clear again instead of simply stop.
Testing
The first test was to see whether the robot would stop if a box is placed head on in front of the robot. The robot would have to drive forward for about three meters and when close to the wall, it should stop. The second test was to see whether the robot would keep driving when a box is placed in parallel to the path of the robot. The box does not block the robot and should keep driving forward as only specific range of laser data is considered in the code.
Both tests were successful, as can be seen in the videos. Next to that, we noted that the robot also stops when confronted with smaller object than a big box, like a single human leg.
The final video of the rosbot not crashing can be found here: https://tuenl-my.sharepoint.com/:v:/g/personal/a_h_d_pauw_student_tue_nl/EYhKaW_zeu5Jo1Jdxsm22J4BHX9xfxyHwInA22WbUBwDhQ?e=1amYTU
Assignment 1: A-star
How could finding the shortest path through the maze using the A* algorithm be made more efficient by placing the nodes differently?
The efficiency of A* algorithm in solving a maze depends primarily on the heuristic used and the layout of the nodes. The placement of nodes could potentially impact the efficiency of the algorithm. For given map, we cam put nodes at decision points: This would be to place nodes only at intersections or decision points, and dead ends within the maze, reducing the total number of nodes. This would be a form of graph pruning, which would significantly cut down on the number of nodes the algorithm needs to process.
Sketch the small maze with the proposed nodes and the connections between them. Why would this be more efficient?
This approach would be more efficient because A* works by expanding nodes, starting from the start node, based on a cost value that's the sum of the path cost from the start node to the current node and the estimated cost from the current node to the goal node. By reducing the number of nodes, we also reduce the number of these cost computations, resulting in a more efficient algorithm.
To make hero navigate through the corridor we started with the art of do not crash exercise. The first thing we tried to implement is a very easy solution which scans the area in front of the robot and when and when an obstacle is detected in a certain range we would calculate if that obstacle is on the right or the left of the robot using the mid point from exercise 1 as reference. The rosbot would then incrementally rotate in the opposite direction until the obstacle is not present anymore and continue straight.
This worked well in simulation in easy corridors but sometimes, as expected, the robot would turn the wrong way and end up back at the start of the corridor or event get stuck in sharp angles.
So to add onto that we instructed the robot to try and always go straight(midpoint when the robot starts to drive), resulting in the robot turning back to the straight trajectory after it has turned to avoid an obstacle. This final behaviour can be seen in the video bellow.
Testing
The robot was making very discrete decisions resulting in rapid and abrupt accelerations. Therefore, we decreased the speed of the robot significantly to avoid that non smooth behaviour, this can be see in the video.
The final video of the hero robot navigating can be found here: https://tuenl-my.sharepoint.com/:v:/g/personal/a_h_d_pauw_student_tue_nl/ETomJyr9VBpJhzhW5_v6GaUBnpDclHuzAsFZNdebVRyjjQ?e=et9oCv