Embedded Motion Control 2015 Group 1
Embedded Motion Control (EMC) Group 1 is a multidisciplinar and multilingual project group working on the 'A-MAZE-ING PICO'. This wikipedia page consists of the weelky progress presented in the #Journal, the written report and some other practical and useful stuff.
The report focussus on the individual components of the software architecture, this includes basic idea description, mathematical analyses and possible software implementation.
Journal
The proces of developing a software architecuter and the implementation requires great coordination and collaboration. This journal will be updated to present and track the progress of the group. This journal includes weekly progress, countered problems and divided tasks.
Week 1
In the first week the overall process was discussed. Information from old groups was gathered and shared to clarify certain aspects and to get everyone in the group on the same level. The requirements, which were a selfstudy assignment, were setup using the FURPS model in the meeting for the initial design report. Additionally, the installation of ubuntu and all the software was given as selfstudy assignments next to a division of tasks for the initial design report.
Week 2
In the second week the we defined the roles System’s Architect, Team Leader, Secretary. Split the team in pairs in order to approach the code development and the initial design document. And went deeper in the system’s description and the definition of clearer software functions, communication and context tasks.
Later in the same week the separately created system architectures where checked out made by the earlier defined pairs. Ideas on how to apply the 5C’s to low and low-level functionality were presented. Advantages and disadvantages on the use of potential fields were discussed. Tips were given by the tutor in the first meeting with the tutor, these also contained a lot of practical stuff for the challenge.
For the self study assignments another division was created, separately work on the report, presentation and the basics of the code, including potential field and low level functions. Additionally, the installation of Ubuntu, tools, software and simulators was given as mandatory assignments for everyone.
Week 3
After the long weekend, lasting through two-fifth of week 3, the presentation was given on Wednesday whereafter a meeting took place. We colaboratly did a walkthrough of Git. For development we will only use the developping branche. The master branch will just be used for final versions, supervised by the software architect. From that meeting until friday’s meeting we worked constantly on writing code for the corridor challenge. Coordination of tasks was done by the software architect.
Not everyone installed ubuntu and all the tools yet, this created a lot of frustration for the other group members. The final deadline was set on 12:00 pm Wednesday.
Week 4
Over the weekend from week 3 to 4, a lot of coding is done. On monday morning the first test on Pico were run. Afterwards solutions for the cornering were discussed. And a proposal to have a hybrid solution between Potential Field and States-Decision was discussed. The State Machine consists of a Corridor Mode and a Intersection Mode.
For the code overview and explaination, the #Potential_Field and #Lower Level Skills are separatly discussed. The results of the #Corridor Challenge are shown afterwards.
After the corridor challenge, the group meet to discuss the overall proces and the to do list and to do a quick intermediate evaluation of the group collaborationa and the individual contribution thusfar.
The following topics were discussed and divided as self study assignments:
- Mapping strategy - To be defined during next meetings.
- Decision Making - Refine behavior via updating parameters.
- Improve Driving - Fine tuning the parameters for corridors and cornering.
- Update Wiki
- Explanation of Safety Measurements.
- System Architecture.
- Videos from the simulators’ testing.
- Big corridor + Potential Field
- Previous stable versions of the system. Test them in simulator and get video.
- Get positive and negative points from them. Analyze.
- Use of figures and diagrams explaining the methods.
- Potential Field grid (visualization).
- Explanation of our implementation of Potential Field.
- Minutes, meetings, requirements.
- Include time-based description of the project.
- Wiki Distribution
- System Architecture (initial design)
- Potential Field
- Lower Level Skills
- Drive
- Safety Layer
- Corridor Challenge Results
- Clean up code - To be done in a new Branch
- Remove hard-coded stuff. Define possible new (and neat) states for current hacks.
- After cleaning up the code a new stable version (develop-2) should be available by next week.
Week 5
Now the corridor challenge is successfully completed, we need to think about more advanced decision making, maze mapping, and a quicker turning skill. In week 5, not much coding was done, but several design ideas were thought through.
Design Architecture
In this section, the initial idea of an embedded software design will be discussed. The main goal of the design is to make the Pico robot able to solve a maze. In this brief report, the requirements, functions, components specifications, and the interfaces of such a system will be discussed.
Requirements
The requirements of the system will be divided according to the FURPS model. The abbreviation of this model stands for Functionality, Usability, Reliability, Performance, and Supportability. Functionality in this case denotes the features and capabilities of the system. Usability includes the human factors, consistency, and aesthetics. Reliability stands for the failure frequency, accuracy, predictability, et cetera. Performance here means the efficiency, speed, response, i.e. measures of system performance. Finally, the supportability incorporates testability, maintainability, configurability, and so forth.
The main requirement of the system will be to navigate the maze. It must be completed according to the challenge specification, which forms the main functional aspect of the requirements.
Furthermore, the system design must be robust. The layout of the system must constitute all possible functions to account for the various system architecture, which enable the usability of that design. To achieve this, possible fault modes can be taken into account.
Also, the system design should pose a robust solution. This means the provided system solution must be robust enough to cope with the environmental uncertainties, so that the solution as a whole is reliable.
Next, the doors in the maze should be handled correctly. The behaviour of the door should be analysed to help differentiate the door from the wall. Firstly, the robot should be able to recognize a door from a wall and, secondly, cross the door.
Fifthly, the generated design should be tested for its reliability, and accordingly changes are required to be captured to improve the same.
Furthermore, The major functional requirement of the robot is the ability to solve the maze on its own.
Next, the given hardware (PICO robot) must be used for the maze challenge without any modification and additional components mounted on it.
Penultimately, the performance requirement of taking quick decision is one of the essential factors for the PICO robot for completing the challenge within 7 minutes.
And finally, the need for smart decision making is a crucial necessity due to the fact that the environment changes.
In the table below, the above requirements are summarized according to the FURPS structure.
| Requirement | F | U | R | P | S |
|---|---|---|---|---|---|
| Navigate the maze | x | ||||
| Subsystem based design | x | ||||
| Adaptable to environment | x | ||||
| Door handling | x | ||||
| Testing and simulation | x | ||||
| Autonomous operation | x | ||||
| Use given hardware | x | ||||
| Fast decision making | x | ||||
| Smart decision making | x |
Functions
The functions of the system are classified according to three levels: high-level, mid-level, and low-level functionalities.
The high-level functionality incorporates the following three aspects:
- Obtain relative position with respect to the global frame of reference in the maze.
- Identification of the open or closed door.
- Maze solving algorithm or strategy.
The mid-level functionality consists of:
- Straight corridor navigation.
- Collision avoidance algorithm.
- Intersection mapping.
The low-level functionality contains:
- The ability to read the laser and camera input.
- Actuate the wheels according to the input.
- System initialization for the working of the sensors and actuators.
Components
To obtain a clear overview of the system, its architecture is shown in the figure above, including its various components.
Specifications
The specifications of the system are formed by the available hardware and software, and by some of the requirements for the challenges.
- Limited time to complete the maze challenge (7 min).
- Limited access to the actual PICO robot.
- Robot hardware is not to be modified.
- Hardware access is facilitated via ROS.
- Translational/rotational speed limit of the robot actuators.
- Use of C++ and SVN.
- Available sensors: Kinect and laser.
- Use of controller feedback.
- Unknown location of entrance and exit on the boundary of the maze.
Interfaces
Within the system, two types of interfaces are distinguished. First, there is the communication between the different components of the system, shown in the figure above as arrows. The second type of interface, is the interface on which the robot interacts with the environment. This includes a user interface to program the robot, and sensors to sense the environment. There is no user interface to communicate with the robot while it is solving the maze, for it is autonomous. The sensors used by the robot are discussed in the specifications.
Potential Field
In order to solve the maze successfully, the robot needs to be able to drive autonomously. This involves collision prevention and the ability to reach a certain target. While the target itself is provided by a higher level of control, we need some skill that actually reaches it. Our driving skill is able to do both by using a so-called resulting force vector. In principle, this system works quite easy. Objects and locations which are to be avoided have a repelling force, while desirable ones are given an attracting force. Then, the resulting force will give the most desirable direction to drive in, which only needs to be normalised and sent to the lowest level of drive control. For this to work, mathematically the function to calculate the force should be of a different order for undesirable and desirable targets, otherwise the robot could get stuck.
In practise, this is implemented as follows. For all wall points provided by the laser range finder, the following 'force' is calculated:
[math]\displaystyle{ F_{w,i} = \frac{1}{r_m (r-0.05)^5}. }[/math]
Of course, this gives numerical problems when the distance to the wall [math]\displaystyle{ r=0.05 }[/math]. Then, a very high value is assigned. [math]\displaystyle{ r_m }[/math] is a scaling constant, which can be tuned to reach the desirable behaviour later on. The contribution of each wall point in both in plane directions (x,y) is summed to obtain one force vector. Then, the target point is given force
[math]\displaystyle{ F_t = r_t^2, }[/math]
with [math]\displaystyle{ r_t }[/math] the Euclidean distance to the target. The resulting force will be pointing in the direction which is most desirable to drive in. Note how this method is self regulatory, i.e. when the robot for some reason does not actually drive in the direction of the resulting force, the new resulting force of the subsequent time step will automatically correct for this. There is no need to store forces of all wall points, simply summing them vector wise will do. Also, there is no need for additional collision avoidance.
Add gif of force vector with walls and target. Add gif of pico driving.
Lower Level Skills
Drive Skills
It is based on the information from the Potential Field. The driving instructions sent to the motors is related to the "wall rejection force vectors".
Safety Layer
The first safety measure is the potential field algorithm itself. It's very nature should prevent the robot to getting too close to the walls. However, looking for completeness and having safety redundancies in the code, another safety routine was implemented. The basic idea is to prevent the robot to hit the walls, so the distance to the walls is continuously compared to a safety margin. If the distance is smaller the robot will stop and enter a routine that should take the robot away from the wall and put the robot in place to keep driving safely.
Turn Skill
In order to have a modular approach to solving the side turns, the operation was separated using a simple state machine. When advancing through the corridor, the robot is checking for large magnitude differences between the laser's measurement vectors. These differences could represent an "opening" in the wall, which being large enough indicate a new corridor. If the robot detect that the corridor has two possible paths, the state is changed to "Junction" mode. Immediately after, the information that at this point in the maze a junction is located will be stored. This information is not used for the turning itself, but could prove useful when designing the higher decision skills to solve the maze. Once the data is stored, the current state will be "Drive Junction", which takes the robot to an estimate of the junction's center. At this point, the robot will turn to whichever side the new corridor is. These states are represented graphically in the following figure.
Once the robot has turned it must enter the new corridor, detect the walls so that it can navigate again and continue. Such operations are carried out by a "Drive Out" state. If the laser signal indicates that the robot is again in a corridor it moves back to the "Navigate Corridor" state and continues. When the robot detects that there are no more walls ahead of to the sides and there are no large differences between the laser vectors (so, there are no new corridors), its interpretation is that the corridor challenge has been completed. So a "Victory" state is reached that will stop the robot's motion. The next figure shows these states.
Corridor Challenge
Preparation of the Embedded Motion Control #Corridor Competition and the results shown in a short movie.
- Available Approaches
Based on the results from the test run with the real robot, the following solutions were proposed: Robust Turning. Safe or Fast modes. Simple Turns. Hard-coded turns.
A relevant concept in the development of the solutions was to be able to identify that the robot was turning and not only turn as an extension of "regular corridor driving". As a result, a simple state machine was implemented. It modifies the decision making of the robot as long as it recognizes to be in a turn.
 |
- Results
The driving through the straight part of the corridor was smooth and fast reactions were not evident. Just as in the simulation shown previously, the robot detected the side exit appropriately.
 |
The separation of the turning action into states is meant to facilitate the implementation of higher level navigation afterwards. After the challenge some new scenarios were tested to gain some insight of the robustness of the code. First, a small separation between the wall-blocks. Second, narrower corridor. And finally, remove the side exit walls to check if the robot could still recognize it, turn and stop. From these new scenarios, the results were as follow: 1) the code is able to navigate well even is some discontinuities exist in the walls, 2) The robot can drive through the corridor regardless of it having a different width, however, if the width is smaller than the safety margin established in the code, the robot will not move. And 3) Even if the side-corridor has no walls the robot was able to recognize it, turn and stop. These tests show that the robust approach can deal with an uncertain environment up to this level.
Maze Challenge
Training Maze Description
The scenarios that can be faced during the final challenge are diverse. Based on the description from the course's Wiki the test maze of the following Figure was designed.
It has multiple dead-ends, T junctions, X junctions and several corners. It also has three different possible loops marked by the red, green and blue lines of the following Figure.
Maze Mapping
Appendix
The Appendix consists of the unrelevant parts of the report. This includes a list of the group members and some tips and tricks for programming.
Group members
Group 1 consists of the following members:
| Name | Student nr | |
|---|---|---|
| Maurice Poot | 0782270 | m.m.poot@student.tue.nl |
| Timo Ravensbergen | 0782767 | t.ravensbergen@student.tue.nl |
| Bart Linssen | 0786201 | a.j.m.linssen@student.tue.nl |
| Rinus Hoogesteger | 0757249 | m.m.hoogesteger@student.tue.nl |
| Nitish Rao | 0927795 | n.rao@student.tue.nl |
| Aakash Amul | 0923321 | a.v.h.amul@student.tue.nl |
| Ignacio Vazquez | 0871475 | i.s.vazquez.rodarte@student.tue.nl |
Qt from terminal
If Qt Creator is not run from the terminal, the programs inside cannot connect to the ROS master. To be able to run Qt Creator from the desktop without any problems, follow a similar procedure to the one that is used in the Customizing Ubuntu tutorial for the Terminator file:
Edit
~/.local/share/applications/QtProject-qtcreator.desktop
and change the third line to:
Exec=bash -i -c /home/rinus/qtcreator-3.3.2/bin/qtcreator
This will run QtCreator from a terminal even if the desktop icon is used.