Mobile Robot Control 2023 HAL-9000
Group members:
| Name | student ID |
|---|---|
| Xingyi Li | 1820443 |
| Alexander De Pauw | 1877267 |
| Timo van Gerwen | 1321854 |
| Yuzhou Nie | 1863428 |
| Ronghui Li | 1707183 |
| Guglielmo Morselli | 1959301 |
Design Presentation:
https://cstwiki.wtb.tue.nl/wiki/File:Midterm_presentation.pdf
Tasks Divide:
Data-flow Diagram& State Diagram:
[[File:|center|thumb|600px]]
Towards Final Challenge
Introduction (Ronghui)
// introduction of challenge
Strategy (Timo)
// What do we aim for and how do we want to do it
// Table sequence and map
To complete the final challenge, an efficient and robust code is created to make the robot deliver orders to multiple tables in a restaurant which environment is known beforehand. However, as the world around us is not static nor constant, even in the presence of unknown static or dynamic obstacles the robot should still complete its task. To solve this challenge, an approach that incorporates global path planning, local path planning for obstacle avoidance and localization is proposed.
// State & data flow diagrams?
The first task the robot performs during the challenge is to find out where it is. This is called localization, for which a particle filter algorithm is utilized. Particle filters, or sequential Monte Carlo methods, are a set of Monte Carlo algorithms used to find approximate solutions for filtering problems for nonlinear state-space systems. The algorithm will estimate the robot's position with respect to the restaurant map by resampling particles until convergence to the position of the physical robot is achieved. The more particles used in the algorithm, the more accurate the algorithm can determine the position of the robot. However, the increase in particles will have a substantial effect on the computation time and could result in lag. Therefore, a balance has to be found, with the amount of particles as a tuning knob, between the computation time and the accuracy of the algorithm.
With the robot having determined its location with respect to the map, it will try and find the most optimal global path to reach the first table. The global path planning requires prior knowledge of the robot's environment, being the supplied map, the current position of the robot and the location of the next table. This is done using the A* algorithm, which identifies the path from an initial position to a targeted position in a nodal map with the smallest cost. The cost in this challenge is time or distance, therefore the shortest path will be selected by the A* algorithm.
Unknown objects cannot be taken into account by the A* algorithm. For to robot to handle these objects as well, a local path planning is required. The local path planning relies on laser data obtained by the sensors of the robot scanning the environment. Within their range, these sensors can detect any unknown obstacles present around the robot. As the obstacles are detected, the robot has to navigate around them locally by utilizing the artificial potential field algorithm.
Algorithms
// algorithms used for the separate blocks
Localization - Particle filter (Yuzhou)
// Particle filter
Global path planning - A* (Alex)
// A* algorithm
Local path planning - Artificial Potential Field (Xingyi & Guglielmo)
The Artificial Potential Field method has been chosen as a local path planning algorithm. The main idea behind it is to model obstacles and the goal as, respectively, repulsive and attractive vector fields. From a potential point of view this implies assigning a low potential to the goal and a large potential to the obstacles. According to these potential fields, the robot is expected to move autonomously towards the lowest potential coordinates.
Basing on the resulting potential of the robot’s position, the induced velocities can be computed and sent to the robot as references for the navigation. Practically speaking, the APF was designed as a function that given the current pose of the robot, the goal pose and the laser data, returns the reference velocities needed to move towards the minimum potential position.
The laser data is used to model obstacles. One easy approach could be to just take into account the closest obstacle represented as a point in the space. Its relative position with respect to the robot would be given by the range and the angle of the minimum laser scan. This approach would however not be robust, since a single laser measurement is not robust and thus the obstacle position would be uncertain. To tackle this, every laser measurement below a fixed detection threshold is chosen to represent an obstacle. In this way, every obstacle is modeled as a point cloud, of which every point generates a repulsive velocity reference for the robot. The overall repulsive velocity is then the sum of all these point-generated velocity, considering the orientation of those. Summing up these values allows the algorithm to find the right balance between forces pointing in different directions. It also fights the uncertainty of the laser data compensating for outliers.
Calling the APF function until the goal is reached allows the robot to get to the destination avoiding both static and dynamic obstacles. This is due to the fact that the obstacle set is re-calculated every time the function is called, dealing with errors or moving objects.
The goal is just a point in the map as well, thus the attractive velocity is unique. To address this, all the parameters have been tuned to find the right balance between the attractive and the repulsive action.
The pros of this approach:
- It can deal with all kinds of obstacles;
- It is robust with respect to uncertainties in the measurements;
- It is able to find a smooth path towards the goal.
The cons of this approach:
- It relies on good localization: the attractive force is, in fact, a function of the current pose and the goal pose;
- It is intrinsically affected by local minima issues, leading the robot to a low-potential position which might not be the goal;
- It relies on parameter tuning: all the velocity coefficients and al the thresholds must be found through a trial-and-error process.
Integration (Xingyi & Guglielmo)
// How we have combined the blocks
Performance (Ronghui)
// Explain what performance is reached
// Include simulation vs final challenge test
Deficiencies
// What did not work
Conclusion
// Conclusions on project
Recommendations (Timo)
// Recommendations and next steps
openDoor function