Embedded Motion Control 2018 Group 5: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 140: Line 140:
[[File:Interface Diagram.png|center|thumb|700px]]
[[File:Interface Diagram.png|center|thumb|700px]]
=Escape room Challenge=
=Escape room Challenge=
The first challenge that was done was the Escape room Challenge. PICO was placed on an arbitrary location in a rectangular room from which it had to escape through a corridor. This had to be done as fast as possible.
==ideas==
==ideas==
==Wall follower==
==Wall follower==
explain interpretation
In order to complete this challenge, a so-called Wall follower algorithm was built and implemented. The steps that the algorithm makes in order to complete the challenge are as follows:
===Improvements===
 
* Drive to the right until a wall is detected at the right side,
* Follow this wall by driving forward until a wall is detected,
* If the distance to the right wall becomes larger than a predefined threshold, compensate by driving sideways to the wall,
* When a corner is detected ahead, rotate 90 degrees to the left and align to the wall perpendicular to the previous wall,
* If the corridor is detected by an increase in distance measured at the wall side (defined by a certain threshold), PICO will drive another 25 cm forward and then rotate 90 degrees to the right,
* PICO will drive forward and then align to the right wall again, allowing it to exit the room.
 
For detection, PICO uses sensor-data of the sensors located perpendicular to its forward driving direction. These sensors are used to find the distance to walls at its left and right side, defined as ''LeftDistance'' and ''RightDistance'' respectively. The sensor that is aligned with the forward driving position is used to find the distance to to a wall that is in the forward driving direction, defined as ''ForwardDistance''. The detection of a corner as described in step 5 is done by looking at ''ForwardDistance'' and ''RightDistance''. When both of these distances become lower than a predefined threshold, a corner must be present at the right side, and therefore, PICO should rotate to the left. By using this algorithm, PICO is able to find the corridor of the room and escape the room.
 
=== Testing ===  
The testing sessions with PICO were used for testing the algorithm and fine tuning some parameters in the model, such as velocities, rotational velocities and required minimal distances to walls. During the testing, it was found that there is a large difference between the simulation and reality. First, it was concluded that the odometry of PICO should not be trusted too much for localization and moving around. This could be noticed at the 90 degrees rotation that was used. The actual rotation PICO made had a noticeable offset. A possible solution to this problem was using the wall at the side to determine if PICO is aligned with the wall by using additional sensor data. This solution was implemented and tested in the simulation. In the simulation, the solution worked quite well for making the corners, but it also caused some unexplainable and unwanted behaviour. Due to a lack of time, no solution to this problem could be found and therefore, this was not implemented for the Escape room challenge. Another flaw that occurred during testing was that PICO did not always detect the wall at its right side in step 1, and because of this, PICO hit the wall. This did not happen in any of the simulations, and it remains unclear why this happened during testing. Despite these two problems, PICO was able to get out of the room once during testing.
 
=== The Challenge ===
During the challenge, the second problem that was discussed above obstructed PICO from finding the exit. PICO failed to detect the wall at its right side and drove into it. unfortunately, this happened at both trials. After evaluation of the Escape room challenge, it was concluded that a different approach was required for the Hospital Challenge. This means that from this point on, the Wall follower algorithm is abandoned and a new a plan for a new approach is made.   
 
===Conclusion===
A relatively simple algorithm was made for the Escape room challenge, which finds and then follows the wall at its right side until it detects the exit. Based on simulations, this algorithm was sufficient for completing the Escape room challenge. However, during testing, multiple differences were observed between the simulation and reality. It is learned that navigating using purely PICOs odometry is overall not a smart strategy, and therefore this strategy will no longer be used from this point. Hitting the wall due to a detection error was the reason the Escape room challenge ended premature for PICO, the exact cause of this error has not been found. This is however not an issue for the final challenge, because the next step is going back to the drawing table and come up with a new plan.


=Hospital Challenge=
=Hospital Challenge=

Revision as of 10:41, 1 June 2018

Group information

Name Student number E-mail
M.J.W. Verhagen 0810317 m dot j dot w dot verhagen at student dot tue dot nl
L.W. Feenstra 0847751 l dot w dot feenstra at student dot tue dot nl
A.J.J. Steinbusch 0903892 a dot j dot j dot steinbusch at student dot tue dot nl
J.T. Galen 0897620 j dot t dot v dot galen at student dot tue dot nl








Introduction

This project is part of the course Embedded Motion Control in which software is developed and applied to autonomously control a robot in real-life. The project consists of two challenges: the Escape Room challenge and the Hospital challenge. The Escape Room challenge will be an intermediate challenge that serves as preparation for the final challenge which is the Hospital challenge. In both challenges a robot has to fulfill its task autonomously. To begin with, an initial design is made in which the requirements and specifications of the two challenges are touched upon, functions that the software will be divided in, the components of the robot that will be used with their specifications and the interfaces that will be used.

Initial Design

In this section, the initial design is discussed. A list of requirements, functions, components and specifications is made. These lists are presented here. In the end, the communication of the functions among each other is visualized using an interface, which clarifies the structure of the software that will be implemented.

File:InitialDesign.pdf

Requirements

There are two competitions in which PICO will be active. Therefore, the requirements are split up in general requirements, which are of importance for both competitions, requirements considering the Escape room challenge and requirements that concern the Hospital challenge.

General requirements that hold for both challenges are:

  • PICO must move autonomously.
  • PICO is not allowed to bump into walls.
  • PICO gets two opportunities to perform the entire task.
  • PICO cannot stand still for a period longer than 30 seconds.
  • The total time limit for PICO to accomplish its tasks is 5 minutes.
  • The challenges must be finished as quickly as possible.
  • PICO should have a minimal distance from the wall of 25 cm from its center point.
  • The software must be easy to set-up.

Additional requirements concerning the Escape Room challenge are:

  • Finding the corridor.

Additional requirements concerning the Hospital challenge are:

  • PICO has to explore the rooms and build a map.
  • PICO has to be able to park backwards to the wall behind the starting position.
  • PICO must be able to recognize a change in the map and by means of that find an object in one of the rooms.
  • PICO must stop and stand still close to the object after finding it.

Functions

Here, the functions that will be implemented in the software of PICO are presented. The functions are split up in different categories, namely Task, Skill, Action and World model.

Task: Contains the main goal that the robot needs to fulfill. For the first challenge this is escaping the room. For the second challenge this is mapping the hospital, parking backwards and subsequently finding an object.

  • Escape a room
  • Mapping
  • Park backwards
  • Find object


Skill: For each task certain skills are needed. When PICO is escaping the room or mapping the hospital it will have to make decisions where to go next. It can choose different directions and/or rotations. While driving around in the room or hospital PICO has to recognize exits, walls, corners and the object that needs to be found while avoiding hitting any walls or the object. PICO also has to be able to know where it is while driving through the hospital and plan a certain path to find the object.

  • Decision making
    • Go left
    • Go right
    • Go straight ahead
    • Go backwards
    • Rotate
  • Object avoidance
  • Path planning
  • Object recognition
    • Detect exit
    • Detect wall
    • Detect corner
    • Detect object
  • Localisation


Action: To every skill certain actions correspond such as measurements, movements or shutting down.

  • Measurement:
    • Read encoder
    • Read LRF
  • Move:
    • Stop
    • Translate:
      • Left, Right, Back, Straight ahead or x and y direction
    • Rotate:
      • Direction and angle or +/- 90/180/360 degrees
  • Shut down


World model: Contains the map of the environment, the starting position of the robot, the current position of the robot and a function that can obtain this information from other models and can send this information to other models.

  • Initial position
  • Current position
  • Position of the walls, exits and corridors
  • Communicates with functions in other models

Components

The robot that will be used in this project is PICO which is a telepresence robot from Aldebaran. PICO moves on omni-wheels so that it can move in all directions and it can rotate along the z-axis. It contains a Laser Range Finder (LRF) to detect the walls and objects. Also, PICO is provided with wheel encoders to estimate the change in distance from its starting position.

PICO runs on an Intel i7 on Ubuntu 16.04. A software layer has been created onto the Robot Operating System to simplify its use. The software of this project will be programmed in C++.

Specifications

A list of specifications is made regarding PICO and the environment in which PICO will be active. First, the specifications regarding PICO are shown, followed by the specifications that concern the Escape Room challenge and the hospital challenge.

Specifications of PICO:

  • The maximum translational speed is 0.5 m/s.
  • The maximum rotational speed is 1.2 rad/s.
  • PICO is approximately 40 cm wide.
  • Laser Range Finder has a range of -135 to 135 degrees with 1081 data points.

Specifications concerning the Escape Room challenge are:

  • PICO has escaped the room when its entire rear wheel is across the finish line.
  • The shape of the room is rectangular and the dimensions of the room are to be revealed at the start of the challenge.
  • The start position of PICO will be at a random position in the room.
  • The orientation of the corridor will be approximately perpendicular to the wall and the wall on the far end of the corridor will be open.
  • The walls might not be perfectly straight, nor perfectly perpendicular and parallel to other walls.
  • The width of the corridor will be in-between 0.5 and 1.5 meters.
  • The finish line will be more than 3 meters into the corridor to give PICO some more time to align itself with the walls of the corridor.

Specifications concerning the Hospital challenge are:

  • PICO's starting position will be in the hallway.

Interfaces

Interface Diagram.png

Escape room Challenge

The first challenge that was done was the Escape room Challenge. PICO was placed on an arbitrary location in a rectangular room from which it had to escape through a corridor. This had to be done as fast as possible.

ideas

Wall follower

In order to complete this challenge, a so-called Wall follower algorithm was built and implemented. The steps that the algorithm makes in order to complete the challenge are as follows:

  • Drive to the right until a wall is detected at the right side,
  • Follow this wall by driving forward until a wall is detected,
  • If the distance to the right wall becomes larger than a predefined threshold, compensate by driving sideways to the wall,
  • When a corner is detected ahead, rotate 90 degrees to the left and align to the wall perpendicular to the previous wall,
  • If the corridor is detected by an increase in distance measured at the wall side (defined by a certain threshold), PICO will drive another 25 cm forward and then rotate 90 degrees to the right,
  • PICO will drive forward and then align to the right wall again, allowing it to exit the room.

For detection, PICO uses sensor-data of the sensors located perpendicular to its forward driving direction. These sensors are used to find the distance to walls at its left and right side, defined as LeftDistance and RightDistance respectively. The sensor that is aligned with the forward driving position is used to find the distance to to a wall that is in the forward driving direction, defined as ForwardDistance. The detection of a corner as described in step 5 is done by looking at ForwardDistance and RightDistance. When both of these distances become lower than a predefined threshold, a corner must be present at the right side, and therefore, PICO should rotate to the left. By using this algorithm, PICO is able to find the corridor of the room and escape the room.

Testing

The testing sessions with PICO were used for testing the algorithm and fine tuning some parameters in the model, such as velocities, rotational velocities and required minimal distances to walls. During the testing, it was found that there is a large difference between the simulation and reality. First, it was concluded that the odometry of PICO should not be trusted too much for localization and moving around. This could be noticed at the 90 degrees rotation that was used. The actual rotation PICO made had a noticeable offset. A possible solution to this problem was using the wall at the side to determine if PICO is aligned with the wall by using additional sensor data. This solution was implemented and tested in the simulation. In the simulation, the solution worked quite well for making the corners, but it also caused some unexplainable and unwanted behaviour. Due to a lack of time, no solution to this problem could be found and therefore, this was not implemented for the Escape room challenge. Another flaw that occurred during testing was that PICO did not always detect the wall at its right side in step 1, and because of this, PICO hit the wall. This did not happen in any of the simulations, and it remains unclear why this happened during testing. Despite these two problems, PICO was able to get out of the room once during testing.

The Challenge

During the challenge, the second problem that was discussed above obstructed PICO from finding the exit. PICO failed to detect the wall at its right side and drove into it. unfortunately, this happened at both trials. After evaluation of the Escape room challenge, it was concluded that a different approach was required for the Hospital Challenge. This means that from this point on, the Wall follower algorithm is abandoned and a new a plan for a new approach is made.

Conclusion

A relatively simple algorithm was made for the Escape room challenge, which finds and then follows the wall at its right side until it detects the exit. Based on simulations, this algorithm was sufficient for completing the Escape room challenge. However, during testing, multiple differences were observed between the simulation and reality. It is learned that navigating using purely PICOs odometry is overall not a smart strategy, and therefore this strategy will no longer be used from this point. Hitting the wall due to a detection error was the reason the Escape room challenge ended premature for PICO, the exact cause of this error has not been found. This is however not an issue for the final challenge, because the next step is going back to the drawing table and come up with a new plan.

Hospital Challenge

World mapping

SLAM

how computes(pathplanner)/ which libraries etc./ think about copyright/gridmap/

Define rooms

Localisation

Path planning

How computed/which libraries etc.

setpoints

how computed/ no bumping

Object detection

How defined/interpreted