Embedded Motion Control 2017 Group 3

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 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

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