Mobile Robot Control 2020 Group 6: Difference between revisions
(→Logs) |
No edit summary |
||
| Line 69: | Line 69: | ||
=Design Document= | =Design Document= | ||
The design document, which describes the design requirements, specification, components, functions and interfaces can be seen [[:File:4SC020_Design_Document_Group_6.pdf|here]]. | The design document, which describes the design requirements, specification, components, functions and interfaces can be seen [[:File:4SC020_Design_Document_Group_6.pdf|here]]. | ||
=Escape Room Challenge= | |||
== Perception == | |||
== Monitor and strategy == | |||
== Control == | |||
== Validation == | |||
== Challenge == | |||
On May 13th the escape room challenge was held, where the task was to exit a simple rectangular room through its one exit without any prior information about the room. We had prepared two branches of code, to allow ourselves to have a backup. With the software described in the previous sections, the first attempt showed behavior which was very close to the video below. Unfortunately, when the robot turned its back towards the wall it should be following, it got stuck in a loop which it could not escape. From the terminal we could read that the robot remained in a single state, called FollowWall. However, its reference direction did constantly change. | |||
[[File:ER_fail_4-2020-05-18_10.34.30.gif]] | |||
The code for the second attempt, which omitted the use of the states '''GoToGap''' and '''GoToFinish''', made use of two states only, being '''FindWall''' and '''FollowWall'''. This meant that the issue we faced in the first attempt was still present in the new code, hence exactly the same behavior was observed. | |||
During the interview, it was proposed by our representative that the issue was a result of the robot turning its back to the wall, meaning that the wall behind it is not entirely visible. In fact, because the robot can not see directly behind, the wall seems to be made out of two parts. During turning, the part of the wall which is closest to the robot is used in the FollowWall function changes, hence the reference point changes position. Then, with the new reference point the robot turns again, making the other section of the wall closest, causing the robot to turn back and enter a loop. | |||
During testing with the room that was provided after the competition, a different root to our problems was concluded. As it turned out, the wall to the rear left of the robot almost vanishes when the robot is turning clockwise and its back is facing the wall, as can be seen in the left video above. This means that this wall no longer qualifies as a wall in the perception algorithm, hence it is not considered as a reference wall anymore. This means that the robot considers the wall to its left as its reference, meaning that it should turn counterclockwise again to start moving parallel to that. At that point, the wall below it passes over the threshold again, triggering once again clockwise movement towards the exit. | |||
With this new observation about the reason the robot got stuck, which could essentially be reduced to the fact that the wall to be followed passed under the threshold, the first debugging step would be to lower this threshold. Reducing it from 50 to 20 points, allowed the robot to turn clockwise far enough, so that the portion of the wall towards the exit came closest and hence could be followed. This meant that the robot was able to drive towards the exit, and out of the escape room without any other issues, as can be seen in the video below. All in all, it turned out that the validation we had performed before the actual challenge missed this specific situation where the robot was in a corner and had to move more than 90 degrees towards the exit. As a result, we did not tune the threshold on the minimum amount of points in a wall well enough, which was actually the only change required to have the robot finish the escaperoom. | |||
[[File:ER_succ_4-2020-05-18_10.36.58.gif]] | |||
Revision as of 11:26, 18 May 2020
Group Members
Students (name, id nr):
Joep Selten, 0988169
Emre Deniz, 0967631
Aris van Ieperen, 0898423
Stan van Boheemen, 0958907
Bram Schroeders, 1389378
Logs
This section will contain information regarding the group meetings
| Date/Time | Roles | Summary | Downloads | |
|---|---|---|---|---|
| Meeting 1 | Wednesday 29 April, 13:30 | Chairman: Aris Minute-taker: Emre |
Introductionary meeting, where we properly introduced ourselves. Discussed in general what is expected in the Design Document. Brainstormed of solutions for the Escape Room challenge. Set up division of tasks (Software Exploration/Design Document). | Minutes |
| Meeting 2 | Wednesday 6 May, 11:30 | Chairman: Emre Minute-taker: Stan |
Discussing our V1 of the Design Document with Wouter. Devised a plan of attack of the escape room competition and roughly divided the workload into two parts (Perception + world model and Strategy + Control). | Minutes |
| Meeting 3 | Monday 11 May, 11:00 | Chairman: Stan Minute-taker: Joep |
Discussing what needs to be finished for the Escape Room challenge. | Minutes |
| Meeting 4 | (Date), Time | Chairman: Joep Minute-taker: Bram |
Evaluating the escaperoom challenge and the groupwork so far. Made agreements to improve the further workflow of the project. | Minutes |
| Meeting 5 | (Date), Time | Chairman: Bram Minute-taker: Pim |
(Summary goes here) | (Downloadable minutes goes here) |
| Meeting 6 | (Date), Time | Chairman: Pim Minute-taker: Aris |
(Summary goes here) | (Downloadable minutes goes here) |
Design Document
The design document, which describes the design requirements, specification, components, functions and interfaces can be seen here.
Escape Room Challenge
Perception
Monitor and strategy
Control
Validation
Challenge
On May 13th the escape room challenge was held, where the task was to exit a simple rectangular room through its one exit without any prior information about the room. We had prepared two branches of code, to allow ourselves to have a backup. With the software described in the previous sections, the first attempt showed behavior which was very close to the video below. Unfortunately, when the robot turned its back towards the wall it should be following, it got stuck in a loop which it could not escape. From the terminal we could read that the robot remained in a single state, called FollowWall. However, its reference direction did constantly change.
The code for the second attempt, which omitted the use of the states GoToGap and GoToFinish, made use of two states only, being FindWall and FollowWall. This meant that the issue we faced in the first attempt was still present in the new code, hence exactly the same behavior was observed.
During the interview, it was proposed by our representative that the issue was a result of the robot turning its back to the wall, meaning that the wall behind it is not entirely visible. In fact, because the robot can not see directly behind, the wall seems to be made out of two parts. During turning, the part of the wall which is closest to the robot is used in the FollowWall function changes, hence the reference point changes position. Then, with the new reference point the robot turns again, making the other section of the wall closest, causing the robot to turn back and enter a loop.
During testing with the room that was provided after the competition, a different root to our problems was concluded. As it turned out, the wall to the rear left of the robot almost vanishes when the robot is turning clockwise and its back is facing the wall, as can be seen in the left video above. This means that this wall no longer qualifies as a wall in the perception algorithm, hence it is not considered as a reference wall anymore. This means that the robot considers the wall to its left as its reference, meaning that it should turn counterclockwise again to start moving parallel to that. At that point, the wall below it passes over the threshold again, triggering once again clockwise movement towards the exit.
With this new observation about the reason the robot got stuck, which could essentially be reduced to the fact that the wall to be followed passed under the threshold, the first debugging step would be to lower this threshold. Reducing it from 50 to 20 points, allowed the robot to turn clockwise far enough, so that the portion of the wall towards the exit came closest and hence could be followed. This meant that the robot was able to drive towards the exit, and out of the escape room without any other issues, as can be seen in the video below. All in all, it turned out that the validation we had performed before the actual challenge missed this specific situation where the robot was in a corner and had to move more than 90 degrees towards the exit. As a result, we did not tune the threshold on the minimum amount of points in a wall well enough, which was actually the only change required to have the robot finish the escaperoom.
