Embedded Motion Control 2015 Group 2

Go back to the main page.

---

---

Group Members

Name:	Student id:	Email:
Groupmembers (email all)
Wouter Kuijpers	0864565	w.j.p.kuijpers@student.tue.nl
Carel Wechgelaer	0874762	c.a.wechgelaer@student.tue.nl
Natalia Irigoyen	0929175	n.irigoyen.perdiguero@student.tue.nl
Stephanie Dávalos	0925756	s.davalos.segura@student.tue.nl
Georgi Hristov	0931293	g.s.hristov@student.tue.nl
Paul Padilla	0926256	g.p.padilla.cazar@student.tue.nl
Garbí Singla	0932046	G.Singla.Lezcano@tue.nl
Tutor
Luis Ferreira	n/a	L.F.Bento.Ferreira@tue.nl

Planning

Week 1 (22/4 - 29/4)

Problem formulation, ideas on design as well as task allocation. Additional work on :

• Intitial design document
• Presentation preparation
• Ubuntu set-up with all required software running
• C++ tutorials

Week 2 (29/4 - 06/5)

• Allocation of team roles in the project
• Finish of presentation
• Finish of C++ tutorials
• Meet tutor and discuss design
• Use his feedback to improve design document

Week 3 (06/5 - 13/5)

• Presentation of initial design
• Revision of design document
• Corridor completion task :
  • Tasks and code structure breakdown
  • Work allocation
• Testing on the actual robot :
  • 11/5 - Due
  • 12/5 - Due

Initial Design

Goal

Design and implement software for the PICO robot, such that the robot is able to find the exit of the maze as quickly as possible and in a fully autonomous way.

Requirements

• Use the PICO robot to solve the “A-Maze-ing challenge.”

• The PICO robot should reach the end of the maze in the shortest time.

• The PICO robot should operate fully autonomously; after starting the robot it should make all decisions about navigating autonomously.

• The operation of the PICO robot should be independent of the maze configuration.

• During operation the PICO robot should not collide with anything, e.g. walls, doors, robots and humans.

• The software used to interface with the PICO robot should contain a software-based kill- switch to allow manual termination of the robot.

Functions

• Basic - start, stop, move forward, turn
• Navigation - maze solving algorithms and optimal path calculation
• Maze mapping - survey the area, search for doors
• Safety - keep minimum distance from walls, respond to kill-switch

Components and Specifications

• Robot Context - Low-level specifications of the PICO Robot. The robots hardware abstractions layer which takes care of all low-level sensing- and actuation-capabilities of the robot (holonomic base, odometry sensors, LRF).
• Skills Context - Contains the above mentioned robot functionalities - navigation, perception, mapping, surveying, terminating.
• Environment Context - Semantic maze model.
• Task Context - Controls the execution of the robot’s skills depending on the challenge and the environment context. The task context is divided into three major parts :
  • Task control feedback: Depending on the information received from the task monitor contributes in controlling the robot skills, keeping the minimum distance to walls contraints and taking autonomous decisions.
  • Task control feedforward: Depending on the state and the goal of the challenge contribute in controlling the robot skills and help construct the semantic maze map.
  • Task monitor: Monitors the execution of the skills, interprets sensor readings and sends this information to the task control feedback which in turn decides upon a new control action.
• Challenge Context - Contains all the information about the maze-challenge at hand such as the rules of the game and goal of the game.

Interfaces

• Skill context – Robot context: This interface takes care of sending commands to low-level hardware and returns sensor signals.
• Challenge context – Environment context: This interface takes care of assumptions about the maze and goal approach.
• Task context – Environment context: This interface takes care of providing the correct information to the task context in order to make decisions based on the maze map.
• Task context – Skill context: This interface takes care of the skill selection based on both the contribution of the task control feedback and task control feedforward.
• Challenge context –Task context: This interface takes care of providing the goal of the challenge context to task context, in order to make decisions to aim for the goal of the challenge while adhering to the rules of the game.
• The Challenge context also provides the interface to control the robot from the outside of the field, this involves commands to start and stop the robot and provide information about the current status of the robot in the maze.

Files

• Design Document - File:Design Document.pdf
• Initial Presentation - File:Initial Presentation.pdf

Corridor Competition

On the 13th of May 2015 the Corridor Competition was scheduled. Videos of our both attempts to reach the finish of the corridor can be viewed by clicking on the two pictures below

Analysis First Try

• Keeping Minimum Distance-algorithm: performs oké, an initial limit estimation was used ensuring that the robot keeps a safe distance to the wall.
• Turning: after making a 90 degree turn the coordinator presumably switched back to normal mode, then it saw a new end of the corridor on the left and wanted to turn immediately. In this case the coordinator had to be overwritten by first driving forward without the possibility of again turning.

Analysis Second Try

• Keeping Minimum Distance-algorithm: performs oké, an initial limit estimation was used ensuring that the robot keeps a safe distance to the wall.
• Turning: we do not know what went wrong here. So far we have also not succeeded recreating the same behavior in the simulator.

Lessons Learned

• A new algorithm is needed for keeping the minimum distance to the wall, this algorithm causes a large variation in the robot's orientation. In designing this new algorithm use can be made of the algorithm as a basis.
• A new algorithm is needed to detect possible turns or, in the real maze, intersections and T-junctions. In designing this new algorithm use can be made of the algorithm as a basis.

Composition Pattern

On the 27th of May the Composition Pattern presentation was given in the EMC lecture. In this presentation the (slightly revised) Task-Skill-Motion-framework was presented and the mapping from this to the Composition Pattern Hierarchy; which is shown in the picture below.

The slides of the presentation can be found here: * Design Document - File:Presentation 27052015.pdf

Final Design

(Mapping the Maze) Robot Position

The Global Robot Positioning System

The main function of the Global Robot Positioning System (GRPS) is to provide the location of Special Situations after visiting them and "predict" the location of Special Situations when encountering one. The Global Position of Special Situations is of great importance in building a topological maze map. This functionality was fully integrated in a robotPosition-class in the C++-language. This class mainly contains the following elements, a more detailed explanation/description is given after this short one:

 * initialDistance - this method determines the distance to the next perpendicular wall.
 * readyForCorner - this method executes all the functionality when a Special Situation is detected for the first time. 
 * Cornering - this method is active when the robot is turning and keeps track of the robot's position during it. 
 * CorneringFinished - this method  executes after a corner has been completed. It makes sure that the LandMark position in the Global Robot Positioning System (GRPS) is updated as well as PICO's own position. 

Some remarks about definitions: a special situation is defined as being a: corner (both to left and right), X-junction, T-junction, Dead-End, U-Turn. In the function-names above Cornering is being used, this method actually refers to turning of the robot it activates whenever the robot is changing orientation. Also throughout the next explanation the term LandMark will be used to indicate the representation of a Special Situation in the Maze Map.

Detailed Explanation/Description - Corners

Now we will give a more detailed explanation/description of the Global Robot Positioning System (GRPS)-class, this will be done using following the robot throughout a sample maze presented in the picture to the left. The following functionality is executed during its execution

1. The Robot is initialized at Position 1 where first the initialDistance-method determines the distance from Position 1 to the perpendicular wall in front of the robot which is denoted by A. We store this distance in StoredDistance
2. The Robot then starts driving, at some point it will reach Position 2, where the method readyForCorner will be triggered by the detection of a Special Situation. At this point the distance from Position 2 to the perpendicular wall (A) in front of the robot is determined and stored in LeftInCorridor. Knowing the orientation of the robot (which is North when starting by definition) we can find the current position of PICO by adding the distance [math]\displaystyle{ StoredDistance-LeftInCorridor, }[/math] to the right coordinate. E.g.: the robot starts at (0,0) facing North, if then StoredDistance = 5 [m] and after arriving at Position 2, we find LeftInCorridor = 1 [m], we know that Position 2 is located at (0,4) with PICO (still) facing North.
3. As the distance from the mid-point of the Special Situation (which will be the Global Position stored in the LandMark) to the point where the Special Situation is detected Position 2 is quite constant we can now estimate the Global Position of the LandMark. (This is also represented at Position 6) E.g.: using the previous example and the fact that the distance from the mid-point of the Special Situation to the point where the Special Situation is detected is 1 [m], we estimate that the LandMark is at (0,5).
4. A side from estimating the global position of the LandMark, the readyForCorner-method also stores the odometry data in StoredOdometry of the robot at Position 2 is stored in method, the General Coordinator then starts the execution the Cornering at the Special Situation.
5. During turning the CurrentOdometry is compared to the StoredOdometry if the orientation of the robot changed 90 degrees in the correct direction (turning left or right) the distance from Position 3 to the perpendicular wall (B) in front of the robot is determined and stored in StoredDistance.

• Once the robot detects the Special Situation of Wall b the algorithms executes from step 2 above.

Maze Challenge

On the 17th of June 2015 the Maze Challenge was scheduled. The maze which has to solved is shown in the pictures below.

Videos of our both attempts to reach the end of the maze can be viewed by clicking on the two pictures below

Videos currently are uploaded

Analysis First Try

• The code we used was adjusted at many places without testing. Therefore, the robot made wrong decisions at some points. In the beginning the robot already had a collision with a wall. But after the collision, the safety algorithm made the robot to drive backwards and continue the maze challenge. Then, at the T-junction with the door, the robot chose to go forward, which was also implemented in our algorithm of the solving. Then, when the robot did the T-junction for the second time, the dead end was not recognized and therefore, a possible door was not checked.

Analysis Second Try

• For the second try, the code of the test time, the day before, is used. As there were some bugs in there, the robot was not able to take the turn and proceed to the open space. Therefore, the robot was making loops. At the X-junction, the potential field placed the target at the wrong point which leaded a turn of 360 degrees.
• In the end, our team thinks that the code of our first trial was able to perform the maze challenge successfully when the door is open. Unfortunately, during the maze challenge, we chose for the safe version.