Embedded Motion Control 2019 Group 8: Difference between revisions
TUe\s157974 (talk | contribs) |
TUe\s157974 (talk | contribs) |
||
Line 40: | Line 40: | ||
== Design Document == | == Design Document == | ||
For the Escape Room Challenge a design document has been made. | For the Escape Room Challenge a design document has been made. This document contains a description of the requirements, specifications, components, interfaces and functions. | ||
The file can be found here: [[File:Design_document.pdf]] | The file can be found here: [[File:Design_document.pdf]] | ||
Revision as of 10:24, 16 June 2019
Group Members
Name | Student ID | |
---|---|---|
Stan (C.M.) den Hartog | 0953184 | c.m.d.hartog@student.tue.nl |
Elise (E.D.T.) Verhees | 0950109 | e.d.t.verhees@student.tue.nl |
Rob (R.J.G.) Dorussen | 0968849 | r.j.g.dorussen@student.tue.nl |
Gosse (G.) Bijlenga | 0950642 | g.bijlenga@student.tue.nl |
Max (M.J.) van Haren | 0953564 | m.j.v.haren@student.tue.nl |
Introduction
The goal of the course Embedded Motion Control (EMC) is to design software such that the robot (PICO) can perform tasks autonomously in a real life setting. The implementation of the software skills to fulfill real-life robotic tasks in real-time situations, takes into account both planning and basic programming. In order to see how well the objective is reached, PICO is tested in the following two challenges.
The first challenge is the Escape Room Challenge, in which the robot is placed in a room with a single exit with a random orientation. Upon placement, the robot should autonomously find the exit, move towards the exit and exit the room without touching the surroundings. The second challenge is the Hospital Challenge, in which the robot should autonomously function within a hospital, based on a specific map. The goal for the robot is to go from cabinet to cabinet, while on the way encountering random disturbances as deemed normal in a hospital.
This wiki page will give an overview of the designs for both the Escape Room and Hospital challenges.
Escape Room Challenge
Design Document
For the Escape Room Challenge a design document has been made. This document contains a description of the requirements, specifications, components, interfaces and functions. The file can be found here: File:Design document.pdf
Escape Room Execution
A short summary of the actions the robot will undertake can be seen in the State machine showed below.
Wall Following
Since the most robust solution is to follow a wall, this is chosen to be implemented first. The decision has been made to make the robot always keep the wall on its left side. Good results are achieved in the 2 random maps that are shown in Figure 2 and 3.
Scanning for an exit
Next, the robot is made a bit 'smarter'; It will first scan the room for an exit. If an exit is found, it will stop rotating, rotate a bit back, to make sure it will head for the left wall, start heading for the exit, and then continue with the wall following procedure to exit the corridor. The result using both wall following and scanning for an exit can be seen in Figure 4.
Escape Room Result
The result in the escape room challenge can be seen in Figure 5.
Evaluation of the Escape Room
The escape room challenge clearly showed robustness is key in solving robotics problems. Figure 5 shows the robot is stuck in the corridor. This can be explained since there was a wall place skewed in the corridor and the robot thought it was located at an outside corner. Implementing the ideas itself did not seem a big issue, however robustly solving these problems did. In the hospital challenge, there is tried to tackle all the problems as robustly as possible.
Hospital Challenge
Hospital Challenge Brainstorm Session
To prepare for the hospital session, a brainstorm session is done and several new requirements, specifications, functions and components are thought of.
The following diagram is the result of this brainstorm session.
Components of the Hospital Challenge
The components seen in in Figure 6 are explained in this section.
Localization
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
Route planning
As in this challenge our focus lies on robustness and not on the speed at which the task is fulfilled, throughout the map there are waypoints that are placed at convenient places. These waypoints can be seen in Figure x. The waypoints are placed in such a manner that the robot could drive in straight lines from waypoint to waypoint, thus at corners and corridors or doors. In order to decide the order of the waypoints for the path of the PICO robot, some paths are hardcoded. Each path starts in the hallway and goes to each cabinet, as it is assumed that each cabinet will be accessible through the corridor. For each cabinet, there are multiple paths that are hardcoded, and PICO cycles through these paths if obstacles are found to be blocking the path in such a manner that continuing along this path would be impossible.
State machine
In Figure 7 the state machine can be seen. The state machine cycles through the steps of route planning and actuator control in order to fulfill the task. At the start of each assignment, there is an initialization state where the robot starts up and checks functionality. Next, it will place itself using the localization, where he will determine his route to the next cabinet. Then, the robot will rotate itself in such a way that a straight path can be made towards the next waypoint, after which PICO will drive towards the waypoint.
Once a waypoint is reached, there are three options. The first option is that a next waypoint is to be gone to, after which the robot will orient itself again. The second option is that the robot has arrived at a cabinet and is required to orient itself to be aligned with the cabinet and afterwards determine a new route, towards the new waypoint. The third option is that a new route is required, due to obstacles, doors, etc.
Throughout the state machine, localization and object detection/avoidance are running, which both override the state machine in importance. If localization cannot take place, the robot will pause the state machine in order to regain the location. If an object is detected and required to be avoided, the state machine will be paused in order to keep PICO from touching foreign objects.
Object detection/avoidance
In order to be able to drive from waypoint to waypoint without any collisions, there are two different options hardcoded. The first option is when driving in open space and the second options is when driving through a narrow opening, such as a door. Each case will be explained below.
Open space object avoidance
In the open space, objects can be encountered, which could be either dynamic objects, such as people walking around, and static objects, such as cupboards. In order for PICO to know how to act upon sensing an object nearby, an area around PICO is taken as seen in Figure x.
If an object is in the green space, which is more than half a meter away from PICO, PICO will not react at all as there is no interference with the foreseeable path of PICO. Once an object enters the yellow space, PICO pauses and tests hypotheses. The first hypothesis to be tested is whether it is a static dynamic object. If the shortest distance to the sensed object stays within a minimum angle difference and minimum difference in shortest distance, the object is assumed to stand still. If the object is not in the direction that PICO is desired to move in, PICO will continue on its path. If the object is in the way, PICO will sense the quadrant where the static object is in, and move to the open space in the opposing quadrant, until the object is no longer within the circle and the path will be free. If PICO cannot find a way around the static object after 3 trials, PICO will delete the waypoint for this trajectory and continue by finding a different path.
The second set of hypotheses to be tested is the direction of the dynamic object. PICO measures the angle and magnitude of the minimum distance to the object and saves this in the world model. PICO pauses for a second and measures the magnitude and angle of the minimum distance again. If the difference in angle of the minimum distance differs minimally, whereas the minimum distance decreases/increases, the hypotheses can be made that the object is moving closer/further away. If the object is moving closer, PICO will check which quadrant the object is entering, and check for free space in the opposing quadrant. If there is free space, PICO will move into that quadrant until the threat is no longer moving towards PICO. If the object is moving further away, PICO waits until the object exits the circle and continues driving. Next, if the difference in angle of the minimum distance changes after the waiting time, whereas the minimum distance can change, the object is assumed to move across from PICO, without hitting PICO. PICO then waits until the object moves across from the path that PICO desires and PICO then continues driving.
Once an object crosses the yellow circle, by for example unexpected behavior by dynamic objects, and enters the red circle, PICO does not test hypotheses. PICO checks in which quadrant the object enters, and checks the minimum distance in the opposing quadrant and drives there if said quadrant is free. If the opposing quadrant is not free, PICO will drive backwards until the object is no longer in the red circle, and until there is free space in the opposing quadrant. Here it is assumed that the path that PICO just travelled is free to drive backwards.
Narrow way object avoidance
Once in between doors, the second option is utilized. In this case there is only a small circle as seen in Figure x. In this case the red zone is slightly larger than the red zone as in the open space in order to give more time to build hypotheses. Once an object enters the red zone, quick hypotheses are tested as in the yellow circle of the open space. Once an object enters the space, a very short time is waited in order to determine whether an object is static or dynamic. If the object is dynamic, the quadrant is tested and PICO moves into the opposing quadrant if the quadrant is free, else PICO moves backwards. If an object is static, it is tested whether is a door, by testing whether there are areas where the maximum distance seen when facing towards the wall is larger than expected. If it is a door, PICO requests for the door to be opened. If it is a static object in the way, the waypoint is deleted for this trajectory and a new path is decided. Once an object enters the circle on the right or left, PICO moves in the opposite direction in order to stay around the middle of the doorway, to avoid collision with the walls.
Motor Control
Due to investigations it was already clear that no complicated control was necessary. To make the movements of Pico slightly more smooth, a gain has been implemented.
The function furthermore returns the relative distance travelled each sampling interval.
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
Simulation results of the hospital challenge
Two simulation examples have been made for the hospital challenge. One nominal situation and one situation where clutter objects are apparant on the map. These can be seen below.
Results of the Hospital challenge
The official hospital challenge, with static objects, doors and dynamic objects has been tried twice. The trials can be seen below.
- Trial1 group8.gif
Figure x: Trial one of the Hospital Challenge
- Trial2 group8.gif
Figure x: Trial two of the Hospital Challenge
This shows results which were expected, since the simulation results already showed there were flaws in the localization when there was deviation compared to the nominal situation. A run with only a dynamic objects and no doors or static objects has been done after the challenge. Pico fully completed this challenge as seen below.
Evaluation of the Hospital challenge
As can be seen in the trial runs in the Hospital Challenge, the main fault in the concept lies within the localization. As the localization is implemented, it runs every iteration and calculates the position again. As the robot reaches the area where the 'couch', 'cupboard' and 'door' are placed, the robot is unable to locate itself, even though PICO has access to its location from a previous time step which is reliable. If the software for PICO would have been built to trust the odometry when there is an unsure localization for PICO until a new trusted location for PICO is available, this would have improved the robustness of PICO greatly. If PICO did not know its location as built now, PICO would spread particles all over the map in order to try locate itself, which causes great disturbances for the localization, thus creating a position on the map with a large error.
Next to this, during the Hospital Challenge, PICO is lifted and put inside the right room, which it recognized. However, the path planning was designed in such a way that PICO had to follow a list of waypoints until it got stuck. Once regaining its location in the right room, PICO's path planning intended for PICO to drive back to the waypoint on the way to the cabinet. As an improvement, the path planning should have taken into account the actual location and closest distances to different waypoints and planned its route accordingly.
Thirdly, the localization did not take map known disturbances into the map, which could have greatly helped. Adding static disturbances could increase robustness, as PICO has gathered more information of its surroundings. This could have placed the knowledge that an object, such as the 'cupboard', is in the hallway and will anticipate this now known disturbance during future encounters. This could have helped during localization in further iterations and thus strengthen the knowledge of its location.
Lastly, PICO bases its hypotheses of off short time periods. In order to increase robustness, PICO should test certain hypotheses, such as the hypothesis whether a static object is truly static throughout the entire Hospital Challenge or is static for certain periods of time, multiple times and should have the ability to turn certain waypoints on and off.
NOTE: maybe different way of path planning to increase scalability?