Embedded Motion Control 2017 Group 3: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==Group Members==
{| border="1" cellpadding="5" cellspacing="0" style="float:right;"
{| border="1" cellpadding="5" cellspacing="0" align="left"  
|+ ''' Group Members '''
! TU/e Number
! Name
! E-mail
|-  
|-  
| 1032791
| 1032791
Line 6: Line 9:
| ayisha.wafa@student.tue.nl
| ayisha.wafa@student.tue.nl
|-
|-
| 0980790
| 1033848
| Aparnasri Sekar
| Aparnasri Sekar
| @student.tue.nl  
| a.sekar@student.tue.nl  
|-
|-
| 0976940
| 0742670
| Nick Peters
| Nick Peters
| @student.tue.nl
| n.k.peters@student.tue.nl
|-
|-
| 0976467
| 0811091
| Jelte Borsboom
| Jelte Borsboom
| @student.tue.nl  
| j.j.borsboom@student.tue.nl  
|-
|-
| Tutor
| Tutor
Line 23: Line 26:
|-
|-
|}
|}
<div style="clear:both"></div>


==Documents==
This is the WIKI page of group 3 of the [[Embedded Motion Control 2017 | Embedded Motion Control]] course of 2017. The Team members and their contact information are found on the right side of this page. On this page, we will discuss the design and implementation choices we have made during this course and reflect on the results.
Here given is the initial design document namely, [[file:Emc-design-specification.pdf]] that points the approaches taken towards problem, algorithms used and system design for the robot to navigate through maze and find the exit autonomously.


The slides for the initial design presentation can be found here: [[File:group3_2017_Initial_design_presentation.pdf]]


==Overview==
__TOC__
This article presents a summary of the software design to solve the following challenges with the Pico robot.  
 
# Corridor competition: To follow a corridor and take the first exit.
= Design =
# Maze competition: To solve and exit an unknown maze.
 
The Initial Design was the design step to identify the  requirements and the higher level design are bulit over it for the Corridor and Maze Challenges.
 
[[File:EMC17-G3_Control.png|thumb|250px|right|Initial Control Hierarchy]]
The following functions were conceived, as a starting point for further design:
# The ''' Path Finding ''' Supervisor, responsible for finding the path PICO should follow.
# The ''' Wall Detection ''', responsible for finding information about the walls around PICO.
# The ''' Motion ''' Supervisor, responsible for making the higher level movements of PICO.
# The ''' Door''' Supervisor, responsible for taking over the system in a system with a (potential) door.
# The ''' Actuator ''' Supervisor, responsible for the actual setting of all PICO's actuators.
# The ''' Main Loop''', the actual program, calling every supervisor once every time step (Time-division multiplexing).
 
The interactions between these functionalities  are explained in the [[Embedded Motion Control 2017 Group 3 / Initial Design| Initial Design page]], together with more in-depth information about this design step.
== Corridor Design ==
Implementation page of the corridor design [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | here]].
 
For the corridor challenge, implementing the Door Supervisor was not necessary yet. The Actuator Supervisor was found redundant and was therefore included in the Motion Supervisor. The three remaining supervisors were designed separately.
=== Wall Detection ===
The Wall Detection had the responsibility to give information about the world around PICO. After the complete design step, the functionalities of the Wall Detection during the Corridor Challenge included:
# It calculated the initial angle to the walls (not actually used, because redundant for corridor Challenge).
# It calculated the filtered distance to the right and left wall, assuming PICO was aligned parallel to the walls.
# It made the conclusion if any of PICO's known sides (left, front and right) there is space for PICO to move in this direction.
# During turning the corner points of the new corner were found using the Laser Data.
   
   
The project is divided in the following aspects:
=== Path Finding ===
# Requirements
During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in.
# Specifications
 
# Functions
If this supervisor detected an open space either left or right it would:
# Components
# Alert the Motion Supervisor to go to a turning state.
# Interfaces
# Alert the Wall Detection to detect corner points for the new corridor.


==Requirements==
=== Motion Supervisor ===
After brainstorming section, requirements are listed for our robot (PICO) to complete maze successfully and is as follows:
The Motion Supervisor had the responsibility to do all the movements using the information from Wall Detection and Path Finding. After the complete design step, the functionalities of the Motion Supervisor during the Corridor Challenge included:
# PICO may not touch the walls or any other obstacle in the maze at any time
# Stabilizing PID controller to keep the left and right wall at equal size from PICO, keeping PICO in the middle of the corridor at all times.
# PICO must operate fully autonomous (i.e. without input from the team)
# Move in the middle of a new corridor.
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit
# Move straight forward when no walls were detected in any of PICO's known sides.
# PICO must be able to detect available space using the Laser Range Finder (LRF) and move to the detected space according to the motion planning algorithm
# Making a 90 degrees turn, either left of right.
# PICO must be able to find the exit in finite time (≤ 7 sec for maze and ≤ 5 sec for corridor.)
# PICO must be able to detect the objects (dead ends) that have a high probability of being a door
# PICO must be able to open the door in the maze and pass through it


==Functions==
The functions are separate modules called supervisors where, the supervisor unknown of what is inside the other supervisor. This approach makes software architecture simpler, it is also easier to edit and error count will be less since no direct interaction of modules. Supervisors are listed below:
# Path-finding Supervisor
# Door Handling Supervisor
# Wall / Path Detection
# Motion Supervisor
# Actuator Supervisor


===Path-finding Supervisor===
The software implementation and more in-depth information about some of these functions are given in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]], together with simulation results.
1-'''Pledge Algorithm:'''
 
Takes in the extracted wall information as input and sets a movement goal for the PICO and move towards it. This algorithm is useful when the robot is challenged to solve loop inside the maze. The algorithm functions as a continuous loop. (Maze challenge)
== Maze Design ==
Implementation page of the maze design [[Embedded Motion Control 2017 Group 3 / Maze Design | here]].
 
For the Maze Challenge big changes were made to the approach of our program. Besides that the Wall Detection was renamed to the World Interpreter Supervisor to better reflect its functionality. The Door Supervisor was also implemented in this design step. The four supervisors were redesigned to:
 
=== World Interpreter ===  
 
The World Interpreter was designed as a virtual circle around PICO. After the complete design step, the functionalities of the World Interpreter during the Maze Challenge included:
# Find the closest distance that is inside the right side of the virtual circle, including the angle with respect to PICO.
# Detect a dead end and with that a potential door.
# Count all the 90 degrees corners that PICO made.
# Find obstacles in front of PICO (to prevent collisions).
 
=== Path Finding ===
 
For the Path Finding the Pledge Algorithm was implemented using the difference between the  left and right corners counted by the World Interpreter. Path finding could be in 2 states:
# Right-wall following, if difference is non-zero or an obstacle is in front of PICO.
# Moving straight forward, if difference is zero, until a obstacle is in front of PICO.
 
=== Motion Supervisor ===
 
The Motion Supervisor was redesigned to create continuous turning behaviour. After the complete design step, the functionalities of the Motion Supervisor during the Maze Challenge included:
# Stabilizing PID controller to keep the smallest right distance inside the virtual circle at a pre-set distance (inside the virtual circle) from PICO.
# Stabilizing PID controller (separate) to keep the angle of PICO to the smallest point always around 0.5 PI radians right of PICO.
# Slowing down if there are obstacles in front of PICO.
 
=== Door Handling Supervisor ===
 
The Door Handling was designed to stop everything and do the Door procedure if a potential door is detected. After the procedure, normal operation is resumed.
The functionalities were:
# Ring the doorbell
# Stop all other supervisors from doing anything
# Count the time PICO has been waiting.
# Prevent ringing for the same dead end twice.
 
The software implementation and more in-depth information about this design step are given in the  [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]], together with simulation results throughout the process.
 
= Results =
During the little testing hours we quickly found out that simulation is nothing in respect to real life operation. It took us for instance quite a long time to figure out that the inertia of PICO was the reason behind the overshoot problems we encountered during testing.


2- '''Cornering:'''
Our strategy was to test our program to as many different corridors / mazes as possible. But that didn't gave any guarantees that it would work in real life. Every iteration step for the code took a week, resulting in very slow progress.  
Take the corner using the wall information as input. (Corridor challenge)


===Door Supervisor===
== Corridor Challenge ==  


1-'''Ring Bell:'''
In the corridor Challenge, we crashed PICO into a wall two times. Which was of course sad, but we tried to learn from this experience the best we could. We will discuss the positive and the less positive points of the behaviour of our program:
Ring the bell if it detect the door possible deadends


2-'''Standstill:'''
=== Positive ===
Wait for 5 sec to for the door openingsequence.


===Wall / Path Detection===
The PID control of keeping PICO in the middle worked very robust, it only oscillated a little bit and it was certainly working as designed in the corridor. We can only say that PICO did wonderful up to the moment it tried to do a corner.


1-'''Read LRF data:'''
=== Negative ===
Gets raw data from the LRF sensor


2-'''Filter LRF data:'''
The problem happened at the moment PICO wanted to make a turn. Reality and simulation were not the same at this situation,as explained further in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]].
Reduces noise from raw LRF data and splits it into 3 directions (left, right and front).
3-'''Transform data:'''
Calculate one distance approximation for the 3 directions.
4-'''Possiblity checker:'''
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.


===Motion Supervisor===
The cause of the crash can be traced back to the PID controller, unlike in simulation, PICO was pushed inside by the last PID action. This put PICO in a different position and orientation (state) than we anticipated, our code still tried to find the corner points even though they were behind PICO. The results of the corner detection were of course meaningless and this caused the crash of PICO to the wall.


1-'''Position stabilizing:'''
The problem of our code was that we made assumptions about the state PICO is in. This resulted in non-robustness to changes happening in real life, which resulted in a crash itself. Besides that, we turned only on odometry sensor, which in itself is not a robust solution.
Feedback loop that keep PICO approximately in the center of the corridor by implementing a feedback controller for the distance to the walls on the left and right of the robot.


2-'''Turn Corner:'''
=== Conclusion ===
Make a 90 degree turn either on left or on right


===Actuator Supervisor===
We concluded that major changes should made to the design of the code, we therefore redesigned our controller, further information on that can be found in [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]]. The basic idea was to do better state estimation and go back to one controller that can handle all the states.


1-'''Steady PICO:'''
== Maze Challenge ==
Keep the front of the PICO aligned to the direction of movement.
[[File:Maze_sollution_pledge.png|200px|thumb|right|Figure 1. pledge sollution to the maze]]
During the maze challenge the maze visible in figure 1 was used. The maze was a bit bigger than originally anticipated, but we had great confidence that we could finish this maze. Using the pledge algorithm in our heads we saw that we could easily solve this. The correct way pico had to go is visible in figure 1, first we discuss the behaviour in simulation, followed by the real challenge.


2-'''Omniwheels handeling:'''
=== Simulation ===
Set speed and angle of Omniwheels


==Interfaces==
Looking at the simulation, we see that PICO walks like it is supposed to go, going trough the maze effortless. However, PICO is very eager to find the door and it tries to this many times. The dead end detection was tuned during real world tests where this kind of false positive for the door detection happens a lot less frequently, so we decided to keep the code this way.
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.
The different interfaces are described and the italic sentences are type of codes in implementation.


# Sending information about current state, which is distance to walls at -90 degrees, 0 degrees and 90 degrees from the centerpoint and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.
The simulated solution for the maze can be seen here https://www.youtube.com/watch?v=lJhQru467kg


# Forward information about potential movement.<''Struct of Boolean''>.
=== Real Maze ===
[[File:Maze_challenge_2017_group3.png|200px|thumb|right|Figure 2. PICO taking long route after not counting a turn]]


# Forward information about wall distances.<''Struct of floats''>.
During the real challenge, we only had one good try. The first time PICO started the counted started with an initial value which wasn't zero and therefore PICO couldn't detach from the inner loop. We immediately reset PICO and retried, the mysterious error luckily only happened once.


# Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.
Sadly, in the second attempt, we did not make it to the finish-line either. This was due to a number of reasons, but in the end we failed on the time-limit. PICO was nearing the finish line when the 5 minutes deadline was passed. PICO did move effortless trough the maze, but to leave the outer loop of the maze, PICO had to go all the way around the right side of the maze, visible in figure 2.  


# Send information about the possibility of a door.<''Boolean''>.
The reason can be tracked back to the turn counter, the 'desired' direction of PICO was changes from North to West, between the origin and point A, resulting in detaching from the wall at point A, instead of a right turn. Although this was inconvenient, we know the pledge algorithm can still find the exit, but, unlucky for us, with the 'desired' direction to the west, the pledge path to the exit is a very sub-optimal solution.


# Confirmation that door handling is finished <''Boolean''>.
The recorded attempt can be viewed here https://youtu.be/gtlqmMJ6KB8


#Setting the values for actuator.<''Struct of floats''>
== Code Snipets ==


==Components==
The main loop (short and well commented): [https://gitlab.com/nick_peters/group3/blob/master/src/main.cpp#L38]


# '''Sensors:'''Laser Range Finder (LRF), Odometry (Wheel Encoder).
Wall followinf code (virtual circle): [https://gitlab.com/nick_peters/group3/blob/master/src/motion.cpp#L44]
               
# '''Holonomic base (omni-wheels):'''Max. translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.


# '''Embedded platform'''Computer with Ubuntu 14.04 on an intel i7 (other specifications are unknown)
Turn detection & counter: [https://gitlab.com/nick_peters/group3/blob/master/src/worldinterpreting.cpp#L224]


# '''Bell:'''device to produce sound from PICO as bell to open door.
Pledge implementation: [https://gitlab.com/nick_peters/group3/blob/master/src/pathfinding.cpp#L17]

Latest revision as of 09:19, 23 June 2017

Group Members
TU/e Number Name E-mail
1032791 Ayisha wafa ayisha.wafa@student.tue.nl
1033848 Aparnasri Sekar a.sekar@student.tue.nl
0742670 Nick Peters n.k.peters@student.tue.nl
0811091 Jelte Borsboom j.j.borsboom@student.tue.nl
Tutor Wouter Kuijpers w dot j dot p dot kuijpers at tue dot nl

This is the WIKI page of group 3 of the Embedded Motion Control course of 2017. The Team members and their contact information are found on the right side of this page. On this page, we will discuss the design and implementation choices we have made during this course and reflect on the results.


Design

The Initial Design was the design step to identify the requirements and the higher level design are bulit over it for the Corridor and Maze Challenges.

Initial Control Hierarchy

The following functions were conceived, as a starting point for further design:

  1. The Path Finding Supervisor, responsible for finding the path PICO should follow.
  2. The Wall Detection , responsible for finding information about the walls around PICO.
  3. The Motion Supervisor, responsible for making the higher level movements of PICO.
  4. The Door Supervisor, responsible for taking over the system in a system with a (potential) door.
  5. The Actuator Supervisor, responsible for the actual setting of all PICO's actuators.
  6. The Main Loop, the actual program, calling every supervisor once every time step (Time-division multiplexing).

The interactions between these functionalities are explained in the Initial Design page, together with more in-depth information about this design step.

Corridor Design

Implementation page of the corridor design here.

For the corridor challenge, implementing the Door Supervisor was not necessary yet. The Actuator Supervisor was found redundant and was therefore included in the Motion Supervisor. The three remaining supervisors were designed separately.

Wall Detection

The Wall Detection had the responsibility to give information about the world around PICO. After the complete design step, the functionalities of the Wall Detection during the Corridor Challenge included:

  1. It calculated the initial angle to the walls (not actually used, because redundant for corridor Challenge).
  2. It calculated the filtered distance to the right and left wall, assuming PICO was aligned parallel to the walls.
  3. It made the conclusion if any of PICO's known sides (left, front and right) there is space for PICO to move in this direction.
  4. During turning the corner points of the new corner were found using the Laser Data.

Path Finding

During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in.

If this supervisor detected an open space either left or right it would:

  1. Alert the Motion Supervisor to go to a turning state.
  2. Alert the Wall Detection to detect corner points for the new corridor.

Motion Supervisor

The Motion Supervisor had the responsibility to do all the movements using the information from Wall Detection and Path Finding. After the complete design step, the functionalities of the Motion Supervisor during the Corridor Challenge included:

  1. Stabilizing PID controller to keep the left and right wall at equal size from PICO, keeping PICO in the middle of the corridor at all times.
  2. Move in the middle of a new corridor.
  3. Move straight forward when no walls were detected in any of PICO's known sides.
  4. Making a 90 degrees turn, either left of right.


The software implementation and more in-depth information about some of these functions are given in the Corridor Design page, together with simulation results.

Maze Design

Implementation page of the maze design here.

For the Maze Challenge big changes were made to the approach of our program. Besides that the Wall Detection was renamed to the World Interpreter Supervisor to better reflect its functionality. The Door Supervisor was also implemented in this design step. The four supervisors were redesigned to:

World Interpreter

The World Interpreter was designed as a virtual circle around PICO. After the complete design step, the functionalities of the World Interpreter during the Maze Challenge included:

  1. Find the closest distance that is inside the right side of the virtual circle, including the angle with respect to PICO.
  2. Detect a dead end and with that a potential door.
  3. Count all the 90 degrees corners that PICO made.
  4. Find obstacles in front of PICO (to prevent collisions).

Path Finding

For the Path Finding the Pledge Algorithm was implemented using the difference between the left and right corners counted by the World Interpreter. Path finding could be in 2 states:

  1. Right-wall following, if difference is non-zero or an obstacle is in front of PICO.
  2. Moving straight forward, if difference is zero, until a obstacle is in front of PICO.

Motion Supervisor

The Motion Supervisor was redesigned to create continuous turning behaviour. After the complete design step, the functionalities of the Motion Supervisor during the Maze Challenge included:

  1. Stabilizing PID controller to keep the smallest right distance inside the virtual circle at a pre-set distance (inside the virtual circle) from PICO.
  2. Stabilizing PID controller (separate) to keep the angle of PICO to the smallest point always around 0.5 PI radians right of PICO.
  3. Slowing down if there are obstacles in front of PICO.

Door Handling Supervisor

The Door Handling was designed to stop everything and do the Door procedure if a potential door is detected. After the procedure, normal operation is resumed. The functionalities were:

  1. Ring the doorbell
  2. Stop all other supervisors from doing anything
  3. Count the time PICO has been waiting.
  4. Prevent ringing for the same dead end twice.

The software implementation and more in-depth information about this design step are given in the Maze Design page, together with simulation results throughout the process.

Results

During the little testing hours we quickly found out that simulation is nothing in respect to real life operation. It took us for instance quite a long time to figure out that the inertia of PICO was the reason behind the overshoot problems we encountered during testing.

Our strategy was to test our program to as many different corridors / mazes as possible. But that didn't gave any guarantees that it would work in real life. Every iteration step for the code took a week, resulting in very slow progress.

Corridor Challenge

In the corridor Challenge, we crashed PICO into a wall two times. Which was of course sad, but we tried to learn from this experience the best we could. We will discuss the positive and the less positive points of the behaviour of our program:

Positive

The PID control of keeping PICO in the middle worked very robust, it only oscillated a little bit and it was certainly working as designed in the corridor. We can only say that PICO did wonderful up to the moment it tried to do a corner.

Negative

The problem happened at the moment PICO wanted to make a turn. Reality and simulation were not the same at this situation,as explained further in the Corridor Design page.

The cause of the crash can be traced back to the PID controller, unlike in simulation, PICO was pushed inside by the last PID action. This put PICO in a different position and orientation (state) than we anticipated, our code still tried to find the corner points even though they were behind PICO. The results of the corner detection were of course meaningless and this caused the crash of PICO to the wall.

The problem of our code was that we made assumptions about the state PICO is in. This resulted in non-robustness to changes happening in real life, which resulted in a crash itself. Besides that, we turned only on odometry sensor, which in itself is not a robust solution.

Conclusion

We concluded that major changes should made to the design of the code, we therefore redesigned our controller, further information on that can be found in Maze Design page. The basic idea was to do better state estimation and go back to one controller that can handle all the states.

Maze Challenge

Figure 1. pledge sollution to the maze

During the maze challenge the maze visible in figure 1 was used. The maze was a bit bigger than originally anticipated, but we had great confidence that we could finish this maze. Using the pledge algorithm in our heads we saw that we could easily solve this. The correct way pico had to go is visible in figure 1, first we discuss the behaviour in simulation, followed by the real challenge.

Simulation

Looking at the simulation, we see that PICO walks like it is supposed to go, going trough the maze effortless. However, PICO is very eager to find the door and it tries to this many times. The dead end detection was tuned during real world tests where this kind of false positive for the door detection happens a lot less frequently, so we decided to keep the code this way.

The simulated solution for the maze can be seen here https://www.youtube.com/watch?v=lJhQru467kg

Real Maze

Figure 2. PICO taking long route after not counting a turn

During the real challenge, we only had one good try. The first time PICO started the counted started with an initial value which wasn't zero and therefore PICO couldn't detach from the inner loop. We immediately reset PICO and retried, the mysterious error luckily only happened once.

Sadly, in the second attempt, we did not make it to the finish-line either. This was due to a number of reasons, but in the end we failed on the time-limit. PICO was nearing the finish line when the 5 minutes deadline was passed. PICO did move effortless trough the maze, but to leave the outer loop of the maze, PICO had to go all the way around the right side of the maze, visible in figure 2.

The reason can be tracked back to the turn counter, the 'desired' direction of PICO was changes from North to West, between the origin and point A, resulting in detaching from the wall at point A, instead of a right turn. Although this was inconvenient, we know the pledge algorithm can still find the exit, but, unlucky for us, with the 'desired' direction to the west, the pledge path to the exit is a very sub-optimal solution.

The recorded attempt can be viewed here https://youtu.be/gtlqmMJ6KB8

Code Snipets

The main loop (short and well commented): [1]

Wall followinf code (virtual circle): [2]

Turn detection & counter: [3]

Pledge implementation: [4]

Retrieved from "https://dsdwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3&oldid=44673"