Embedded Motion Control 2019 Group 2
Group members
- 1. Bob Clephas | 1271431
- 2. Tom van de laar | 1265938
- 3. Job Meijer | 1268155
- 4. Marcel van Wensveen | 1253085
- 5. Anish Kumar Govada | 1348701
Design document
Initial design
To complete the two assignments for the course “Embedded motion control” specific software must be written. In this design document the global architecture of the software is explained, and the given constraints and hardware is listed. This document is a first draft and will be updated during the project. The first version can be found here.
Requirements and specifications
The requirements and related specifications are listed in the following table. The listed specifications are required for the final assignment, the underlined specifications are needed for the escape room challenge.
Requirements and their specifications
Accomplish predefined high-level tasks:
1. Find the exit (Back wheels over the finish line).
2. Reach a predefined cabinet.
Knowledge of the environment:
1. Location of walls (via corner points).
2. Location of the doors (via corner points).
3. Location of the cabinets (location: TBD).
4. At what level – 2D (Top view).
5. Accuracy (< 0.1 m resolution).*
6. Shapes (axis aligned Lines).
Knowing where the robot is in the environment:
1. Level (2D).
2. XY precision (<0.1 m).* 3. Orientation precision (<10 degree).*
Being able to move:
1. 0.5 [m/s] translational speed / 1.2 [rad/sec].
2. Maximum acceleration / braking TBD after first experiment session.*
3. Path following (<0.1m).*
Do not bump into the wall:
1. How far should it stay of the wall (>0.1m).
Do not stand still for longer than 30 sec:
1. It is not allowed to stand still for longer than 30 seconds.
Finish as fast as possible:
1. Within 5 minutes.
Coding language:
1. Only allowed to write code in C++ coding language.
2. GIT version control must be used.
(* : Initial guess, exact specifications are determined after first experiment)
(Italic specifications are not needed for the escape room challenge)
Components and functions
The components and their functions are split in software components and hardware components.
Software components and their general functionalities
World model:
- Storing all the relevant data (Map / tasks / position).
- Data communication between the other components (All data goes through the world model)
Perceptor:
- Reading sensor data and creating a local map.
- Locate the robot on this local map.
- Align global map with local map.
Task manager:
- Dividing upcoming tasks to other modules when current task is finished.
- Interrupt a task if needed (safety / Human input).
Path planner:
- Create a path from the combined map, current position and the desired position
Drive controller:
- Actuates the robot such that is follows the planned path (keep speed an acceleration in mind)
Hardware components and their general functionalities
PICO Robotic platform:
- Jazz telepresence robot: General framework with all the hardware. This framework will allow to execute the assignments
Sensors:
- Laser range finder: scan environment and detect objects.
- wheel encoders: determine the traveled distance by the wheels.
- 170 deg wide angle camera: can be used for vision system (object detection for example).
Actuators:
- Holonomic base (omni-wheels): allows the robot to move on the ground.
- Pan-tilt unit for head: can be used to move the head with the display and camera.
Computer:
- Intel I7 processor: Perform computations.
- OS: Ubuntu 16.04 (64-bit): Software that allows execution of programs.
- ROS with own software layer: Allows to easily make connections between software.
Environment
The environments for both assignments will meet the following specifications:
Escape room challenge
- Rectangular room, unknown dimensions. One opening with a corridor.
- Starting point and orientation is random, but equal for all groups.
- Opening will be perpendicular to the room.
- Far end of the corridor will be open.
- Wall will not be perfectly straight, walls of the corridor will not be perfectly parallel.
- Finish line is at least 3 meters in the corridor, walls of the corridor will be a little bit longer.
Final challenge
- Walls will be perpendicular to each other.
- Dynamic elements will be in the area.
- Not all objects will have the same orientation.
- Multiple rooms with doors.
Interface
The overall software is split in several building blocks:
Escape Room Challenge
Our strategy for the escape room challenge was to use the software structure for the hospital challenge as much as possible. Therefore, the room is scanned from its initial position. From this location a local map of the room is created by the perceptor. Including, convex or concave corner points, doors and possible doors (if it is not fully certain the door is real). Based on this local map the task manager gives commands to the drive controller and path planner to position in front of the door. Once in front of the the possible door and verified as a real door the path planner sends the next position to the world model. Which is the end of the finish line in this case, which is detected by two lose ends of the walls. Also the robot is able to detect if there are objects in front of the robot to eventually avoid them.
Simulation and testing:
Multiple possible maps where created and tested. In most of the cases the robot was able to escape the room. However, in some cases such as the room in the escape room challenge the robot could not escape. The cases were analyzed but there was enough time to implement these cases. Furthermore, the software was only partly tested with the real environment at the time of the escape room challenge. Each separate function worked, such as driving to destinations, making a local map with walls, doors and corner points, driving trough a hallway and avoiding obstacles.
What went good during the escape room challenge:
The robot was made robust, it could detect the walls even though a few walls were placed under a small angle and not straight next to each other. Furthermore, the graphical feedback in from of a local map was implemented on the “face” of the Pico. The Pico even drove to a possible door when later realizing this was not a door.
Improvements for the escape room challenge:
Doors can only be detected if it consists of convex corners, or two loose ends facing each other. In the challenge it was therefore not able to detect a possible door. The loose ends were not facing each other as can be seen in the gif below. Furthermore, there was not back up strategy when no doors where found, other then scanning the map again. Pico should have re-positioned itself somewhere else in the room or the pico could have followed a wall. However, we are not intending to use a wall follower in the hospital challenge. Therefore, this does not correspond with our chosen strategy. Another point that can be improved is creating the walls. For now walls can only be detected with a minimal number of laser points. Therefore, in the challenge it was not able to detect the small wall next to the corridor straight away. This was done to create a robust map but therefore also excluded some essential parts of the map.
In the simulation environment the map is recreated including the roughly placed walls. As expected in this simulation of the escaperoom the pico did not succeed to find the exit, the reasons are explained above.
Block descriptions
Each block as shown in the overall Interface block scheme is described in full detail below.
Task manager:
The task manager functions as a finite state machine which switches between different tasks/states. It is used to send commands to specific blocks to perform a certain task based on the status sent in by that block. It communicates with the other blocks via the World model.
INITIALIZATION:
The path planner is given a command “Drive_to_door” while the drive controller and the preceptor are given a command “Execute” as a part of the initialization process.
EXECUTION:
The high-level tasks “Drive_to_door”, “Drive_to_exit”, “Execute”, “Idle” and “Disable” were given to appropriate blocks as shown below:
KEY:
Perceptor:
The perceptor receives all of the incoming data from the pico robot and converts the data to useful data for the worldmodel. The incoming data exists of odometry data obtained by the wheel encoders of the pico robot. The laserdata obtained by the laser scanners. A Json file containing the global map and location of the cabinets, this file is provided a week before the hospital challenge. Moreover, the output of the perceptor to the world model consists of the global map, a local map, a combined map, the current/zero position and a close proximity region. The incoming data is handled within the perceptor by the following functions. A detailed description on what each function does in the preceptor and more information about the data flow can be found here.
The inputs and outputs of the perceptor are shown in the following figure:
The data used in the perceptor:
Path planner:
Drive controller
The drive Controller ensures that the pico robot drives to the desired location. It calculate the distance and direction to the desired location, relative to the current location. It checks if this direction is free of obstacles, if not it calculates an alternative direction that brings the pico robot closer to the desired destination. Finally it uses three PI controllers, one for each axis (rotational, X and Y) to calculate the desired speed for each axis and this is send to the pico-robot with the build-in function.
The inputs and outputs of the Drive Controller are as follows:
The full details of the Drive Controller, including a flowchart and function descriptions can be found in the Drive Controller functionality description document found here.