Embedded Motion Control 2017 Group 3

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]