Embedded Motion Control 2018 Group 3: Difference between revisions
No edit summary |
|||
| Line 166: | Line 166: | ||
=Activity log= | =Activity log= | ||
In the week of may the 14th we have been focusing on two things. First, the presentation of wednesday was made and presented. We presented our initial design and included two gif's of our process so far. Besides that, the main focus was on programming towards the escape room challenge, since this challenge is already at may the 23th. To succeed in this challenge, we have divided the group in three smaller groups, where one group focuses on motion control, one on trajectory planning and one on mapping. At certain moments, some things were working on the simulator. These successes were tried on the real robot. Unfortunately, working on the simulator and working on the real robot are two seperate things (as can be expected). For example, in our code it was programmed that the robot could do the next action when the robot has turned exactly a quarter. Off course, this was never reached in the real test, which resulted in deadlock. | In the week of may the 14th we have been focusing on two things. First, the presentation of wednesday was made and presented. We presented our initial design and included two gif's of our process so far. Besides that, the main focus was on programming towards the escape room challenge, since this challenge is already at may the 23th. To succeed in this challenge, we have divided the group in three smaller groups, where one group focuses on motion control, one on trajectory planning and one on mapping. At certain moments, some things were working on the simulator. These successes were tried on the real robot. Unfortunately, working on the simulator and working on the real robot are two seperate things (as can be expected). For example, in our code it was programmed that the robot could do the next action when the robot has turned exactly a quarter. Off course, this was never reached in the real test, which resulted in deadlock. Another problem was that the simulator started at the same position, everytime you run it. However, while running a program on the real robot, its odometry would not reset. This meant the first time we run the program, it behaved as expected. The second time the same program was running, PICOs behaviour was way different. | ||
Revision as of 14:31, 18 May 2018
Group Members
| TU/e Number | Name | |
|---|---|---|
| 0848904 | Luc (L.L.M.) van den Aker | l.l.m.v.d.aker at student.tue.nl |
| 0852908 | Thomas (T.) Neilen | t.neilen at student.tue.nl |
| 0909434 | Jeroen (J.W.) van de Valk | j.w.v.d.valk at student.tue.nl |
| 0896947 | Nourdin (N.) Kaai | n.kaai at student.tue.nl |
| 0883056 | Peter (P.) van Dooren | p.v.dooren at student.tue.nl |
| 0861750 | Ties (T.J.) van Loon | t.j.v.loon at student.tue.nl |
Initial Design
Report as PDF:
Due to a misunderstanding, the report was not uploaded as a PDF yet. However, the full report was uploaded on this Wiki page (see below) before May 11th (17.00h), and now it is also uploaded as a PDF file (<1Mb). Our apologies for any inconvenience. The PDF of the report of the initial design can be found here: File:InitialDesign Group3.pdf
Requirements:
- PICO should make no collisions with any walls
- PICO cannot stand still for 30 seconds or longer
- For the escape room challenge, the robot should leave the room within 5 minutes
- For the hospital challenge, within 5 minutes, mapping, reverse parking and obtaining the object should be done
- Its surroundings should be made visible in a map
- PICO should be able to reach every position in the room
- PICO should be able to leave every room
- PICO should make distinction between the hall and rooms
- It should run autonomously, so in each challenge there should be no additional input
- To start your software, only one executable has to be called
- PICO should be able to recognize an object and stand still close to it
Functions:
- PICO should be able to drive in any direction
- PICO should be able to turn around
- It should be able to detect walls
- PICO has to know its own position within the mapped map
- PICO is able to construct a map
- It should be possible to create a trajectory to a room
- PICO should be able to recognize an object
Components:
- Sensors:
- Laser Range Finder (LRF)
- Wheel encoders (odometry)
- Actuator:
- Holonomic base (omni-wheels)
- Computer:
- Intel i7
- Ubuntu 16.04
Specifications:
- Translation maximum: 0.5 m/s
- Rotation maximum: 1.2 rad/s
- Range of Laser Range Finder is assumed to be bigger than maximum room dimension
- The field of view of the Laser Range Finder is from -2 rad to 2 rad, divided in pieces of 0.004004
- The Laser Range Finder can only measure at one height
Interfaces:
The interfaces of the initial design are shown in Figure 1:
As shown in Figure 1, a world model is the link between all other parts. The tasks represent the highest level, meaning the most global work PICO has to do. The skills are needed to complete these tasks and some motions together form a skill. The perception contains the sensors, the continuous data. Below an overview of the different parts are given:
World model:
- Compose map
- Object recognition
Tasks:
- Mapping of the environment
- Backward parking at the specified location
- Searching for the object
Skills:
- Planning a trajectory
- Collision avoidance
- Backward parking
- Navigate
- Positioning in front of an opening
- Compose maps
Motion:
- Translation
- Rotation
Perception:
- Odometry
- Laser Range Finder
- Control effort
Activity log
In the week of may the 14th we have been focusing on two things. First, the presentation of wednesday was made and presented. We presented our initial design and included two gif's of our process so far. Besides that, the main focus was on programming towards the escape room challenge, since this challenge is already at may the 23th. To succeed in this challenge, we have divided the group in three smaller groups, where one group focuses on motion control, one on trajectory planning and one on mapping. At certain moments, some things were working on the simulator. These successes were tried on the real robot. Unfortunately, working on the simulator and working on the real robot are two seperate things (as can be expected). For example, in our code it was programmed that the robot could do the next action when the robot has turned exactly a quarter. Off course, this was never reached in the real test, which resulted in deadlock. Another problem was that the simulator started at the same position, everytime you run it. However, while running a program on the real robot, its odometry would not reset. This meant the first time we run the program, it behaved as expected. The second time the same program was running, PICOs behaviour was way different.