Mobile Robot Control 2024 Rosey

Group members:

Name	student ID
Tessa Janssen	1503782
Jose Puig Talavera	2011174
Ruben Dragt	1511386
Thijs Beurskens	1310909
Pablo Ruiz Beltri	2005611
Riccardo Dalferro Nucci	2030039

Week 1 - Don't crash code:

Exercise 1 - The art of not crashing.

Tessa Janssen

The basic idea of this code was to loop through the data from the laser. If one of the laser points returned a distance short than acceptable (e.g. 0.5m), the robot was commanded to stop and turn to the left. If after looping over the laser data again, no points were found within the 0.5 m, the robot was commanded to stop turning and move forward again. In the for-loop going over the laser data, only the middle 300 points were used out of the total range of 1000, resulting in a cone of vision of approximately 1.2 rad. The latter was chosen to make sure the robot only stops for obstacles it will actually run into when it moves forward. A wall on the side of the robot, for example, should not be reason to stop as the robot can move along the side perfectly fine.

*Add screencapture of code*

Jose Puig Talavera

*Insert description of method here*

*Add screencapture of code*

Ruben Dragt

*Insert description of method here*

*Add screencapture of code*

Thijs Beurskens

*Insert description of method here*

*Add screencapture of code*

Pablo Ruiz Beltri

*Insert description of method here*

*Add screencapture of code*

Riccardo Dalferro Nucci

*Insert description of method here*

*Add screencapture of code*

Comparing Remarks:

Overall the concept of each implementation is similar: check if the laser data returns a distance that is too short. The difference between our implementations is what the robot is instructed to do after avoiding collision. This ranges from simply stopping or turning away, to a more complex implementation from Thijs that takes into account the nearest obstacle to determine which way the robot is better of turning towards. This final method is very robust against different types of maps compared to a code only turning left (guaranteed to get stuck at some point).

Exercise 2 - Testing your don't crash.

Findings after testing the code on both Hero and Coco:

Most important was that the velocity used in the simulation needs to be adjusted to which robot is used in real life. Hero automatically limits the speed it takes, but Coco/Bobo don't. Having too high velocity makes it hard to stop in time for an obstacle. This happened a few times when testing the code on the robot for the first time. These parameters, however, were easily tuned. The implementation from Thijs worked really nice in real life when putting up some obstacles. See video below:

*INSERT VIDEO FROM TEST SESSION*

*INSERT SCREENCAP FROM TEST MAPS??*

Week 2 - Local navigation:

Local navigation 1 - Vector field histogram:

Group 1
Thijs Beurskens
Pablo Ruiz Beltri
Riccardo Dalferro Nucci

Local navigation 2 - Attraction/Repulsion vector potential field:

Group 2
Tessa Janssen
Jose Puig Talavera
Ruben Dragt

The main idea behind the artificial potential field is calculating both an attractive potential toward the target and a repulsive potential away from obstacles, which are summed together. The resulting force vector is calculated by taking the negative of the gradient of the summed potentials. The attractive potential is determined by the formula given in the lecture, which depends on the difference between the current pose of the robot and the target pose. The target pose was provided beforehand as a point 6 meters down the corridor (1.5, 6, 0), the current pose was calculated by using odometry data from the robot (with starting coordinate (1.5, 0, 0)). Because the odometry is not perfect, this introduced a small error to the final position of the robot, which was not corrected for this exercise. The repulsive force is similarly determined by the formula from the slides, which uses the laser data to determine the distance between the robot and an obstacle. For this specific implementation, each laser point returning a distance that fell within the predefined space buffer was registered as an obstacle, with the corresponding repulsive force being added to the total force. The constants k_att and k_rep were used to adjust the relative importance of attracting and repulsing.

The resulting force vector was used as input to the robot by calculating the angle corresponding to the vector. This was used as reference angular velocity for the robot, while velocity was kept mostly constant. Mostly constant here means that in the original implementation the velocity of the robot was kept low to allow the robot to have enough time to respond to any obstacles, but at the final session code was added that made sure the robot picked up its speed when there were no obstacles in sight.

*Upload screen recording of the simulation*

Comment on observations

*Upload video of implementation on the robot*

Comment on observations

Answer the following questions:

1. Advantages of the approach
   1. This method makes a lot of intuitive sense and uses relatively easy mathematical concepts to calculate the required forces.
   2. Calculating the repulsion based on real-time laser data makes this method robust against changes in the environment. New obstacles should be incorporated relatively fast into the navigation.
   3. As an extension of point 2: this robustness makes it easier to scale the robot to new and more complex environments.
2. Disadvantages of the approach
   1. Local minima can occur where the total force is zero, but the robot has not reached its target.
   2. ??
3. What could result in failure?
   1. A position where the resultant attractive force is equal to the repulsive force in opposite direction (local minima). Here the robot would be stuck forever as no control input is calculated.
   2. ??

How would you prevent these scenarios from happening?

Week 3 - Global navigation:

Global navigation 1 - A* algorithm:

Group 1
Pablo Ruiz Beltri
Riccardo Dalferro Nucci
Ruben Dragt

Global navigation 2 -:

Group 2
Tessa Janssen
Jose Puig Talavera
Thijs Beurskens