Embedded Motion Control 2017 Group 3: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
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
| Ayisha wafa  
| Ayisha wafa  
| ayisha.wafa@student.tue.nl
| ayisha.wafa 'at' student.tue.nl
|-
|-
| 0980790
| 0980790
| Aparnasri Sekar
| Aparnasri Sekar
| a.sekar@student.tue.nl  
| a.sekar 'at' student.tue.nl  
|-
|-
| 0976940
| 0976940
| Nick Peters
| Nick Peters
| @student.tue.nl
| n.peters 'at' student.tue.nl
|-
|-
| 0976467
| 0811091
| Jelte Borsboom
| Jelte Borsboom
| @student.tue.nl  
| j.j.borsboom 'at'student.tue.nl  
|-
|-
| Tutor
| Tutor
| Wouter Kuijpers
| Wouter Kuijpers
| w dot j dot p dot kuijpers at tue dot nl
| w.j.p.kuijpers 'at' tue.nl
|-
|-
|}
|}
<div style="clear:both"></div>


==Documents==
This is the WIKI page of group 3 of the Embedded Motion Control. 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.
The initial design document [[file:Emc-design-specification.pdf]] briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, the algorithm used and the system design.


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


==Overview==
__TOC__
There are 2 main goals for the PICO robot.
# Corridor competition: To navigate through a corridor and take the first exit without colliding with the walls.
# Maze competition: To solve and exit an unknown maze through a door without colliding with the walls.
The overall design of the project is mentioned in the following section:
# Requirements
# Specifications
# Functions
# Components
# Interfaces


==Requirements==
= Design =
The following requirements are listed for the robot (PICO) to complete maze successfully:
# PICO may not touch the walls or any other obstacle in the maze at any time
# PICO must operate fully autonomous (i.e. without input from the team)
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit
# 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
# 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==
== Initial Design ==
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:
The Initial Design was the design step to identify the  requirement and the higher level design used for the Corridor and Maze Challenge.
# Path-finding Supervisor
# Door Handling Supervisor
# Wall / Path Detection
# Motion Supervisor
# Actuator Supervisor


===Path-finding Supervisor===
[[File:EMC17-G3_Control.png|thumb|250px|right|Initial Control Hierarchy]]
1-'''Pledge Algorithm:'''
The following functions were conceived, as a starting point for further design:
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)
# The ''' Path Finding ''' Supervisor, reponsible 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 ''' Actuater ''' Supervisor, responsible for the actual setting of all PICO's actuators.
# The ''' Main Loop''', the actual program, calling every supervisor once every timestep (Time-division multiplexing).


2- '''Cornering:'''
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.
Take the corner using the wall information as input. (Corridor challenge)
== Corridor Design ==


===Door Supervisor===
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 ===
1-'''Ring Bell:'''
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:
Ring the bell if it detect the door possible deadends
# 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.
2-'''Standstill:'''
# 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.
Wait for 5 sec to for the door openingsequence.
# During turning the corner points of the new corner were found using the Laser Data.
 
===Wall / Path Detection===
=== Path Finding ===  
 
During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in.  
1-'''Read LRF data:'''
Gets raw data from the LRF sensor
 
2-'''Filter LRF data:'''
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:'''
If this supervisor detected an open space either left or right it would:
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.
# Alert the Motion Supervisor to go to a turning state.
# Alert the Wall Detection to detect corner points for the new corridor.


===Motion Supervisor===
=== 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:
# 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.
# Move in the middle of a new corridor.
# Move straight forward when no walls were detected in any of PICO's known sides.
# Making a 90 degrees turn, either left of right.


1-'''Position stabilizing:'''
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]], together with simulation results throughout the process.
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:'''
== Maze Design ==
Make a 90 degree turn either on left or on right


===Actuator Supervisor===
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:


1-'''Steady PICO:'''
=== World Interpreter ===
Keep the front of the PICO aligned to the direction of movement.


2-'''Omniwheels handeling:'''
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:
Set speed and angle of Omniwheels
# 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).


==Interfaces==
=== Path Finding ===  
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.
The different interfaces are described below.


1- Sending information about current state, which is the distance to walls at -90 degrees, 0 degrees and 90 degrees from the center point and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.
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.


2- Forward information about potential movement.<''Struct of Boolean''>.
=== Motion Supervisor ===


3- Forward information about wall distances.<''Struct of floats''>.
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.


4- Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.
=== Door Handling Supervisor ===


5- Send information about the possibility of a door.<''Boolean''>.
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.


6- Confirmation that door handling is finished <''Boolean''>.
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.


7- Setting the values for actuator.<''Struct of floats''>
= 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.


==Components==
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.


1- '''Sensors:''' Laser Range Finder (LRF), Odometry (Wheel Encoder).
== Corridor Challenge ==
               
2- '''Holonomic base (omni-wheels):''' Maximum translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.


3- '''Embedded platform''' Computer with Ubuntu 14.04 on an Intel i7 (other specifications are unknown)
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:


4- '''Bell:''' To produce sound from PICO so as to open the door.
=== Positive ===
The


==The Corridor Challenge ==
== Maze Challenge ==
The challenge is that PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. The Laser data (LRF) is used to detect the wall and space in corridor. This data is communicated among other supervisors such that the decision of turning at first exit is made by the path finding supervisor which then instructs the motion supervisor to move accordingly.

Revision as of 20:07, 16 June 2017

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

This is the WIKI page of group 3 of the Embedded Motion Control. 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

Initial Design

The Initial Design was the design step to identify the requirement and the higher level design used for the Corridor and Maze Challenge.

Initial Control Hierarchy

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

  1. The Path Finding Supervisor, reponsible 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 Actuater Supervisor, responsible for the actual setting of all PICO's actuators.
  6. The Main Loop, the actual program, calling every supervisor once every timestep (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

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 this design step are given in the Corridor Design page, together with simulation results throughout the process.

Maze Design

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

Maze Challenge

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