Embedded Motion Control 2015 Group 3/Decision: Difference between revisions
| Line 20: | Line 20: | ||
After the algorithm function finishes, the Decision part will first check if it is in a dead end. If it is, it will call to the Drive function which handles dead ends. Otherwise, it will check if it is following a corridor, then driving with the regular potential field, by first calling Scan to make the vector, then communicating this to Drive which follows it. Finally, if it is approaching an intersection and it has a direction, it will call a function constructing_walls within the Scan block. It will then call Scan to make the vector again, with virtual walls, and Drive to follow it. For each of these cases, it will also check if collision avoidance is needed, and calls this if necessary. | After the algorithm function finishes, the Decision part will first check if it is in a dead end. If it is, it will call to the Drive function which handles dead ends. Otherwise, it will check if it is following a corridor, then driving with the regular potential field, by first calling Scan to make the vector, then communicating this to Drive which follows it. Finally, if it is approaching an intersection and it has a direction, it will call a function constructing_walls within the Scan block. It will then call Scan to make the vector again, with virtual walls, and Drive to follow it. For each of these cases, it will also check if collision avoidance is needed, and calls this if necessary. | ||
Within the Decision block there is also the possibility of creating a list of subsequent actions to take. This makes it possible to construct a route to any node in the network set up in the Mapping block. However, since this is not required for Trémaux's algorithm, it is not used. | |||
This page is part of the [http://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2015_Group_3 EMC03 CST-wiki]. | This page is part of the [http://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2015_Group_3 EMC03 CST-wiki]. | ||
Revision as of 21:28, 7 June 2015
Decision
The Decision block was made to be the highest in hierarchical order. It is called every iteration from the main. First, it calls the update function in the Scan block. One of the things this function does is recognizing the type of junction it is headed towards, when within range. It saves this junction in it's scandata, which is the class used for communication between blocks. This junction is an enum with several options:
- Crossroad, where it can go left, right or forward.
- Tjunction_1, where it can go left and right.
- Tjunction_2, where it can go right and forward.
- Tjunction_3, where it can go left and forward.
- Deadend, where it is at a dead end, within the range required for opening the door.
- Corridor, where it can see none of the above junction types, which means either the next junction is outside the range of detection, or the corridor it is following leads to a corner, which, since can be solved with the regular potential field driving, does not require a decision.
Next, the Decision block calls it's algorithm function. This function sends the junction type to the Mapping block, which handles it and returns the direction the robot should take next. The algorithm then stores this direction in the Scandata.
After the algorithm function finishes, the Decision part will first check if it is in a dead end. If it is, it will call to the Drive function which handles dead ends. Otherwise, it will check if it is following a corridor, then driving with the regular potential field, by first calling Scan to make the vector, then communicating this to Drive which follows it. Finally, if it is approaching an intersection and it has a direction, it will call a function constructing_walls within the Scan block. It will then call Scan to make the vector again, with virtual walls, and Drive to follow it. For each of these cases, it will also check if collision avoidance is needed, and calls this if necessary.
Within the Decision block there is also the possibility of creating a list of subsequent actions to take. This makes it possible to construct a route to any node in the network set up in the Mapping block. However, since this is not required for Trémaux's algorithm, it is not used.
This page is part of the EMC03 CST-wiki.