Embedded Motion Control 2017 Group 6
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 |
Introduction
For the course Embedded Motion Control the "A-MAZE-ING PICO" challenge is designed, providing the learning curve between hardware and software. The goal of the "A-MAZE-ING PICO" challenge is to design and implement a robotic software system, which should make Pico or Taco be capable of autonomously solving a maze in the robotics lab.
PICO will be provided with low level software (ROS based), which provides stability and the primary functions such as communication and movement. Proper software must be designed to complete the said goal. Various models are used to design the behavior and structure of the software, see Software Design. The final software design, including Git-links, is also discussed in this section. The details of the various software functions can be found in the Software Subsystems. At the end of the page, the Maze challenge is discussed and an overall conclusion is presented.
Initial Design
File:Initial design plan EMC group 6.pdf
Requirements
In order to achieve the goal, the following requirements have to be met:
- The robot has to drive through any maze complying with specifications
- It has to escape the maze within the time limit
- Collisions with the walls must be avoided
- Doors must be opened
- Doors must be recognized in order to achieve the previous requirement
- The software has to be robust for imperfections in the measurement data and disturbances
- The robot must not be idle for a long period of time
- The robot must not ring the bell too often
- The robot must autonomously solve and navigate through the maze
- The Software must be started with only one executable
Functions
The software must have the following functions in order to meet the requirements and fulfill the goal:
Function: | Description |
---|---|
Drive forward | The robot must drive forward unless something, for
example a wall or a corner, is detected |
Drive backward | The robot must drive a little bit backward if it is unable to rotate |
Turn left | Make a 90degree left turn |
Turn right | Make a 90degree right turn |
Ring bell | The bell must be rang in order to open the door |
Localize | The robot has to localize itself in the world model, because the
odometry data isn't that accurate |
Wait | The robot must wait at a dead end in order to check if it is a
door |
Components
The following components will be used to reach the goal:
Sensors
- Laser range finder which uses a laser beam to determine the distance to an object
- Wheel encoders (odometry) to estimate the position of the robot relative to a starting location
Actuators
- Holonomic base with omni-wheels
- Bell to open the door
- Pan-tilt unit for head (which will not be used)
Computer
- Intel I7
- Ubuntu 14.04
Specifications
The goal and the requirements will be achieved with the following specifications:
Robot
- The maximum transnational speed of the robot is 0.5 m/s
- The maximum rotational speed equals 1.2 rad/s
- The corridor challenge has to be solved in 5 minutes
- The maze challenge has to be solved in 7 minutes
- Both challenges have a maximum of two trials
- The laser range finder (LRF) has a range of 270 degrees
- The wheel encoders have an unknown accuracy
- The robot must not be idle for more than 30 seconds
Maze
- The corners will be approximately 90 degrees
- The wall distance is 0.5-1.5 meter
- There is only 1 door in the maze
- The door starts opening in 2 seconds
- The door opens if the robot is within 1.3 meter of the door
- The door is open in 5 seconds
- The number of rings must not be larger than the number of potential doors
- The maze may contain loops
- The maze can contain dead ends
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