Mobile Robot Control 2024 The Iron Giant

Group members:

Caption

Name	student ID
Marten de Klein	1415425
Ruben van de Guchte	1504584
Vincent Hoffmann	1897721
Adis Husanović	1461915
Lysander Herrewijn	1352261
Timo van der Stokker	1228489

Week 1: theoretical exercises

For week one we had to do the following exercises:

Question 1: Think of a method to make the robot drive forward but stop before it hits something.

Question 2: Run your simulation on two maps, one containing a large block in front of the robot, the second containing a block the robot can pass by safely when driving straight.

These exercises were performed individually by the members leading to different outcomes.

There were a lot of similarities between the answers. Every group member used the laser data to determine if object were close. They implemented a way to loop over the laser range data and check the individual values to see whether that value was lower than a safety threshold. If this would be the case all members changed the signal that would be sent to the motors to a zero signal.

But there were some differences too, Lysander made his robot start turning when the object was detected. In the next loop the robot would therefore get different laser scan data and after a few loops the object might be outside the angles the laser scanner can check and so it will drive forward again as it has turned away from the obstacle.

Ruben decided to not loop over all laser ranges but only check the ones in front of the robot. To determine which laser data actually represents the area the robot is going to drive to, a geometric calculation is made by the code, using the arc tangent of the required safety distance and the width of the robot to determine the maximum angle the laser data needs to check. Afterwards when checking whether the values of the laser data are not too big, it adds a geometric term to make sure the safety distance is consistent when looking parallel to the driving direction of the robot and not shaped like a circle due to the lidar.

And overview of the codes and video demonstration can be found in the table below.

Name	Code	Video exercise 1	Video exercise 2
Lysander Herrewijn	Code	Screen capture exercise 1	Screen capture exercise 2 map 1 Screen capture exercise 2 map 2
Adis Husanovic	Code	Screen capture exercise 1	Screen capture exercise 2 map 1 Screen capture exercise 2 map 2
Marten de Klein	Code	Screen capture exercise 1	Screen capture exercise 2 map 1 Screen capture exercise 2 map 2
Ruben van de Guchte	Code	Screen capture exercise 1	Screen capture exercise 2
Vincent Hoffmann	Code	Screen capture exercise 1	Screen capture exercise 2 map 1 Screen capture exercise 2 map 2
Timo van der Stokker	Code	Screen capture exercise 1	Screen capture exercise 2 Map 1 Screen capture exercise 2 Map 2

Practical exercise week 1

The laser had less noise than we expected, it is fairly accurate with its measurements. However, only items at height of the laser can be seen, as the laser only works on its own height. For example, when standing in front of the robot, the laser could only detect our shins as two half circles.

When testing our don't crash files on the robot, it was noticed that the stopping distance needed to include the distance the measuring point is from the edge of the robot. This was measured to be approximately 10 cm. After changing this the robot was first tested on a barrier as seen in Robot stopping at barrier

Next we let a person walk in front of it to see if the code would still work. Fortunately, it did, as can be seen in Robot stopping at passing person

Finally we tested an additional code that turns the robot when it sees an obstacle, and then continues. This can be seen in Robot stopping and turning at feet

Local Navigation Assignment week 2

Vector field histogram (VFH)

The simplified vector field histogram approach was initially implemented as follows.

The robot starts out with a goal gotten from its global navigation, its laser data gotten from the lidar and its own position, which it keeps track of internally. The laser data points are grouped together in evenly spaced brackets. For the individual brackets the code checks how many points are lower than a safety threshold and saves this value.

Next it calculates the direction of the goal by computing the angle between its own position and the goal position. It then checks whether the angle of towards the goal is unoccupied by checking the values of the bracket corresponding to that angle and some brackets around that one specified by its bracket safety width parameter. If the direction towards the goal is occupied the code will check the brackets to the left and to the right and save the closest unoccupied angle at either side. It then picks whichever angle is smaller, left or right. and sets that angle as its new goal.

Afterwards it compares its own angle with the goal angle and drives forwards if it aligns within a small margin or turns towards the direction of the goal. It also checks whether it has arrived at the goal and if that is the case does not move at all and sends the information that it is at the goal position to the global navigation.

This initial implementation had some oversights and edge cases that we came across when testing using the simulator and the real robot. The first issue arose when the system was tested to turn a corner after driving next to an obstacle. At this small distance the cone of laser data that needs to be checked is very large. Though if this cone were used to look at larger distances, the robot would discard routes it could easily fit through. This was fixed by performing a second check on the laser data on the side the robot is turning to and if this check finds an object moving forward a bit more before turning.

Advantages:

• Implementing VFH for navigation is relatively straightforward, requiring basic processing of LiDAR data to compute the histogram of obstacles' directions.
• VFH can generate smooth and collision-free paths for the robot by considering both obstacle avoidance and goal-reaching objectives
• VFH is computationally efficient and robust to noisy sensor data

Disadvantages:

• VFH may have difficulty distinguishing overlapping obstacles, especially if they are close together and occupy similar angular regions in the LiDAR's field of view.
• In complex environments with narrow passages or dense clutter, VFH may struggle to find feasible paths due to the limited information provided by the LiDAR sensor and the simplicity of the VFH algorithm.
• VFH performance can be sensitive to parameter settings such as the size of the histogram bins or the threshold for obstacle detection. Tuning these parameters for optimal performance may require extensive experimentation.
• VFH primarily focuses on local obstacle avoidance and may not always generate globally optimal paths, especially in environments with long-range dependencies or complex structures.

Possible failure scenarios and how to prevent them:

Implementation of local and global algorithms:

---

Dynamic Window Approach (DWA)

Implementation:

The algorithm starts by defining the velocity and acceleration constraints, such as maximum velocities and acceleration limits. It then creates a set of possible velocities, creating a grid from minimum to maximum allowable velocities in discrete steps. Then, the velocities that are not reachable within a single time step, based on the current velocity and acceleration limits, are filtered out.

Each remaining velocity in the set is checked for potential collisions with obstacles detected by the laser sensors. If the combination of the forward and angular velocity would result in a collision, it is removed from the set. This is done by calculating the distance to obstacles and comparing it with the robot’s stopping distance.

In order to determine which combination of the forward and angular velocity suits the best in the particular position. For each feasible velocity, a score is computed based on three criteria in the cost function. The first one is the heading towards the goal, the second one is the forward velocity, and the third one is the distance to the nearest obstacle. The weights for these criteria are defined to balance their importance. The weights are tuned based on the performance in simulation and experiments.

Finally, the robot’s velocity is updated with the best-scoring velocity, resulting in the robot to move in a safe and effective manner.

Advantages:

• Effective at avoiding obstacles detected by the LiDAR sensor in real-time. It dynamically adjusts the robot's velocity and heading to navigate around obstacles while aiming to reach its goal.
• Focuses on local planning, considering only nearby obstacles and the robot's dynamics when generating trajectories. This enables the robot to react quickly to changes in the environment without requiring a global map.

Disadvantages:

• Can get stuck in local minima, where the robot is unable to find a feasible trajectory to its goal due to obstacles blocking its path. This can occur in highly cluttered environments or when the goal is located in a narrow passage.
• Does not always find the optimal path to the goal, especially in environments with complex structures or long-range dependencies.
• The performance can be sensitive to the choice of parameters, such as the size of the dynamic window or the velocity and acceleration limits of the robot. Tuning these parameters can be challenging and may require empirical testing.

Possible failure scenarios:

• A possible scenario is a target position inside a wall. In this case the robot will never reach the target position because the required velocity to reach the target will be ommitted from the velocity set. Instead it will either stop as close as possible to the target position when no velocities are feasible anymore due to collision risk or the robot will keep moving around the target position trying to minimise the heading angle.
  • Solution: ensuring that a target position is never inside a wall could be a method, however this only works for known obstacles. If the target position is part of a set of target positions the robot could try to skip this target position and immediately go to the next position, with the risk of getting stuck in a local minima. The best solution is giving the global planner a signal with an updated map and letting it create a new set of target positions.
• A second possible scenario is that the target position is inside the radius of curvature of the robot resulting in a circling motion of the robot around the target without ever reaching the target.
  • Solution: this scenario can be fixed by tuning the parameters of the algorithm. Ensuring that the heading angle is more important that the forward velocity is a method of avoiding getting stuck in a radial loop. However, when the target is still far away this is less desired because obstacle avoidance works better with a high score on the forward velocity. A solution would be to create a somewhat dynamic parameter setting where if the robot is located far away from the target it uses different values for the tuning parameters compared to when it is close to the target.
• A third possible scenario is that odometry data is not correct resulting in a wrong calculation of the desired heading angle. This would result in the robot targetting a different goal location.
  • Solution: A solution is to reduce the acceleration values to reduce the robot slipping. This makes the robot slightly slower but better controlled. Another solution which will be implemented later will be the addition of a localization algorithm that ensures that the robot has a higher positional accuracy.

Linking global and local planner:

The global and local planner can be easily connected via a main script. In the main script the global planner is called first generating a set of target goals. Then the local planner is called and only given the first target goal. The main script keeps track of the distance from the robot to the target goal and if this distance is smaller than a given value the local planner is given the next target goal until it reaches the final target goal and the main velocity is set to zero. In case a target goal is not reachable (e.g. the distance to the target goal does not reduce for a given time) the global planner should be called again with an updated map.

Demonstration:

Simulation:

Experiment:

In the video, the robot smoothly moves towards its goal, adjusting its path as needed when it encounters obstacles. At the start, the robot moves towards the goal until it meets a wall, then it turns in the right direction to avoid the obstacle. After turning, it keeps moving parallel to the wall. Approaching a corner formed by two walls, the robot slows down, ensuring it has enough space to make a left turn. There is enough space available for the robot to fit through the left gap so it turns there. After turning left, the robot again moves forward parallel to the wall while keeping a safe distance from the adjacent wall. When it completed it last turn around the wall, the robot arrived at its destination accurately enough and stopped smoothly.

Experimental Demonstration Video DWA