Embedded Motion Control 2017 Group 6: Difference between revisions
| Line 112: | Line 112: | ||
In the first scenario Pico is located at one end of a corridor and needs to move to the other end. Pico will do so by first getting sensor data from the LRF and odometry, and then entering the corridor state via the main state machine. The LRF data is then used to check whether there is a junction or dead end near Pico. This is not the case, so a setpoint is created in front of Pico. The setpoint and the location of the walls are then used to create a potential field. With this potential field Pico is able to move a small distance through the corridor while avoiding the walls. | In the first scenario Pico is located at one end of a corridor and needs to move to the other end. Pico will do so by first getting sensor data from the LRF and odometry, and then entering the corridor state via the main state machine. The LRF data is then used to check whether there is a junction or dead end near Pico. This is not the case, so a setpoint is created in front of Pico. The setpoint and the location of the walls are then used to create a potential field. With this potential field Pico is able to move a small distance through the corridor while avoiding the walls. | ||
In the second scenario Pico is located near a junction, but the junction has not yet been detected. Similar to the first scenario Pico will obtain sensor information, enter the corridor state and use the LRF data to determine if there is a junction or dead end near Pico. However, this time a junction is detected and the state of the main state machine is changed into the junction state. | In the second scenario Pico is located near a junction, but the junction has not yet been detected. Similar to the first scenario Pico will obtain sensor information, enter the corridor state and use the LRF data to determine if there is a junction or dead end near Pico. However, this time a junction is detected and the state of the main state machine is changed into the junction state. This causes Pico to start the next iteration in the junction initiate state. Within this state the type of junction is determined, a decision is made by a maze solving algorithm and a setpoint is created in the direction Pico needs to move. | ||
=== Interfaces === | === Interfaces === | ||
Revision as of 09:37, 9 June 2017
About the group
| Name | Student ID | |
|---|---|---|
| Ties Hoenselaar | 0857112 | t.a.h.hoenselaar@student.tue.nl |
| Hasan Ilisu | 0852221 | h.h.ilisu@student.tue.nl |
| Laura de Jong | 0743679 | l.s.d.jong@student.tue.nl |
| Lars Moormann | 0861223 | l.moormann@student.tue.nl |
| Bas Straatman | 0777325 | s.r.t.straatman@student.tue.nl |
| Jeroen van der Velden | 0744957 | j.r.v.d.velden@student.tue.nl |
| Wouter Houtman | Tutor | w.houtman@tue.nl |
Introduction
The most memorable part of the course Embedded Motion Control is the 'A-MAZE-ING PICO' challenge, in which software is designed for and implemented into autonomous robots. These autonomous robots, called Pico and Taco, should then be to able to solve a maze with the software in a real-life environment. A maze can contain loops, dead ends, open spaces and doors that automatically open and close.
Pico will be provided with a basic software layer to carry out primary functions, such as communication and movement. However, to succesfully complete the 'A-MAZE-ING PICO' challenge it is required to design robust software for the changing environment. Several software subsystems will be put to the test in an intermediate challenge. During this challenge, called the corridor competition, Pico must move through a corridor and take the first exit. With the results of the corridor competition and all its software subsystems Pico should be able to finish the maze challenge. The course Embedded Motion Control is concluded with an overall conclusion.
Software design
The ever-changing environment in reality requires the design of a robust software architecture. It is prefered to design this software architecture before actually programming, because it gives a clear understanding/agreement of the different functions from the start. The first step in creating the software architecture is to mention the requirements that have to be met in order to complete the corridor competition and the maze challenge. Pico should be able to finish these challenges succesfully by using most of its components. Secondly, a list of specifications will be given to accuratly describe the robot, corridor and maze. With these requirements, components and specifications it is then possible to define functions for the software architecture. The software architecture is completed by specifying the interface between these different functions.
Requirements
To complete the corridor competition and maze challenge Pico has to meet the following requirements:
- Operate fully autonomous
- Avoid collisions with walls
- Robust against sensor disturbances and layout imperfections
- Update, compile, start and end software with single commands
- Corridor competition
- Move through a corridor that complies with the specifications
- Exit the corridor within the set time limit
- Recognize junctions
- Maze challenge
- Move through a maze that complies with the specifications
- Escape the maze within the set time limit
- Recognize junctions, loops, dead ends and doors
- Ring the bell at dead ends and doors
- Stand idle for a certain period of time
Components
The following components of Pico will be used to fulfill the requirements:
- Sensors
- Laser range finder (LRF) determines the distance to an object with a laser beam
- Wheel encoders (odometry) determine the position of Pico relative to a starting position
- Actuators
- Holonomic base with three omni-wheels to drive and turn
- Bell to request a door to open
- Computer
- Intel I7 processor
- Ubuntu 14.04 as operating system
Specifications
Pico, the corridor competition and the maze challenge are characterized by the following specifications:
- Pico
- Dimensions of 42 cm x 40 cm x 108 cm (LxWxH)
- Maximum translational speed of 0.5 m/s
- Maximum rotational speed of 1.2 rad/s
- Maximum amount of bell actions equal to the amount of doors plus dead ends
- Maximum idle time of 30 seconds
- LRF
- Located at ??
- Range of ??
- Horizontal field of view of 270°
- Frequency of ??
- Accuracy of ??
- Odometry
- Located at ??
- Resolution of ??
- Frequency of ??
- Accuracy of ?? (negligible compared to the slip of the omni-wheels)
- Corridor competition
- Maximum of two attempts within 5 minutes total
- Penalty of 5 seconds or 1 attempt when slightly touching or bumping a wall
- Corners are approximately 90°
- Walls are approximately parallel to each other
- Distance between walls can range from 0.5 to 1.5 meter
- Distance from start to finish is between 1 and 10 meters
- Start is located between the walls in the main corridor
- Finish is located 0.3 meter inside a side corridor on either the left or right
- Main corridor has open ends
- Maze challenge
- Maximum of two attempts within 7 minutes total
- Penalty of 5 seconds or 1 attempt when slightly touching or bumping a wall
- Corners are approximately 90°
- Walls are approximately parallel to each other
- Distance between walls can range from 0.5 to 1.5 meter
- Distance from start to finish is unknown
- Start is located inside the maze, but outside a door area
- Finish is located on the boundary of the maze behind a door
- Can contain loops, open spaces and more than one dead end
- Contains one door and it is located at a dead end
- A dead end is between 0.5 and 1.5 meter wide and at least 0.3 meter long
- A door area is located in front of a door and is 1.3 meter long
- Door opens when Pico is inside the door area, stands still and sends a request
- Door starts opening within 2 seconds and is fully opened within 5 seconds
- Door opens to the left or right with approximately constant velocity
Functions
The requirements can be met with the given components and specifications by defining various functions for the software architecture. These functions typically use sensor information to determine the next actuator action, or compute a variable that is used by another function. When defining functions it is important that each function has a single and clear purpose. All the functions that are required to complete the maze challenge are visualized in a function flow chart. The colors in the function flow chart indicate how much functionality of a function is necessary to finish the corridor competition instead. This design saves time because every function used in the corridor competition is reusable for the maze challenge. The function flow chart starts every iteration with getting sensor data, and based on the state of the state machines a different part of the code is executed. A dashed line is used to illustrate which function can alter the state in a state machine. Furthermore, the main and sub state machines are initialized at the corridor, initiate and request state.
The role of each function will be clarified with three small scenarios.
In the first scenario Pico is located at one end of a corridor and needs to move to the other end. Pico will do so by first getting sensor data from the LRF and odometry, and then entering the corridor state via the main state machine. The LRF data is then used to check whether there is a junction or dead end near Pico. This is not the case, so a setpoint is created in front of Pico. The setpoint and the location of the walls are then used to create a potential field. With this potential field Pico is able to move a small distance through the corridor while avoiding the walls.
In the second scenario Pico is located near a junction, but the junction has not yet been detected. Similar to the first scenario Pico will obtain sensor information, enter the corridor state and use the LRF data to determine if there is a junction or dead end near Pico. However, this time a junction is detected and the state of the main state machine is changed into the junction state. This causes Pico to start the next iteration in the junction initiate state. Within this state the type of junction is determined, a decision is made by a maze solving algorithm and a setpoint is created in the direction Pico needs to move.
Interfaces
The main relations between the interfaces are colored red and can be described as follows:
World model -> Task:The world model can give information about taken paths to the Task
World model -> Skill:The stored observations in the world model are used for movement skills
World model -> Motion:The world model can give data to the actuators
World model -> User interface: The user interface needs the data from the world model to visualize the world model to the human
Task -> World model:The task needs to store information about paths in world model
Skill -> World model :The world model is build from observations
Motion -> World model :The motion can give sensor data about the position to the world model
File:Initial design plan EMC group 6.pdf
Software subsystems
Setpoints
Potential field
Feature detection
Pledge algorithm
Corridor competition
During the corridor competition on the 24th of May Pico had to move through a corridor and take the first exit. The dimensions of the corridor and location of the exit were determined by the organisation and coin flip, respectively. For this intermediate challenge only
