Mobile Robot Control 2024: Difference between revisions
Tag: 2017 source edit |
Tag: 2017 source edit |
||
Line 160: | Line 160: | ||
|[https://gitlab.tue.nl/mobile-robot-control/mrc-2024/Ultron visit GitLab] | |[https://gitlab.tue.nl/mobile-robot-control/mrc-2024/Ultron visit GitLab] | ||
|[[Mobile Robot Control 2024 Ultron |visit wiki]] | |[[Mobile Robot Control 2024 Ultron |visit wiki]] | ||
| | |||
|- | |||
|Optimus Prime | |||
|[https://gitlab.tue.nl/mobile-robot-control/mrc-2024/Optimus-Prime visit GitLab] | |||
|[[Mobile Robot Control 2024 Optimus Prime |visit wiki]] | |||
| | |||
|- | |||
|Kitt | |||
|[https://gitlab.tue.nl/mobile-robot-control/mrc-2024/Kitt visit GitLab] | |||
|[[Mobile Robot Control 2024 Kitt |visit wiki]] | |||
| | | | ||
|} | |} |
Revision as of 10:44, 11 April 2024
'Hero the Toyota HSR'
Introduction
This course is about software design and how to apply this in the context of autonomous robots. The accompanying assignment is about applying this knowledge to a real-life robotics task.
Course Schedule and Lecture Slides
Lectures will typically take place on the Wednesdays between 15:30-17:15. Guided self-study will take place on Fridays between 10:45 and 12:30. The course schedule is as follows:
Date | ||
---|---|---|
Wednesday April 24 | Lecture: Introduction to mobile robot control | |
Friday April 26 | Lecture: Best practices for C++ and Git
Guided selfstudy |
exercises week 1 |
Wednesday May 1 | Lecture: Local Navigation | |
Friday May 3 | Guided selfstudy | |
Wednesday May 8 | Lecture: Global Navigation | |
Friday May 15 | Ascension day | |
Wednesday May 15 | Guided selfstudy | |
Friday May 17 | Lecture: Localization | |
Wednesday May 22 | Guided selfstudy | |
Friday May 24 | Guided selfstudy | |
Wednesday May 29 | Lecture: System architecture | |
Friday May 31 | Help sessions | |
Friday May 31 | Deadline intermediate peer reviews | |
Wednesday June 5 | Presentation of designs by the groups | |
Friday June 7 | Help sessions | |
Friday June 7 | Deadline exercises | |
Wednesday June 14 | Guest lectures: "Safe navigation in a hospital environment" and "Autonomous parking of trucks" | |
Friday June 16 | Help sessions | |
Friday June 21 | Final Challenge | |
Friday June 28 | Deadline: Wiki Pages + Peer review |
Getting Started
To get started, you can follow the installation instructions found in the exercises for week 1. You can already do this before the first lecture.
For students who are not comfortable with c++ we highly recommend taking a look at this tutorial: https://cplusplus.com/doc/tutorial/
Restaurant Competition
Challenge Description
The figure on the right shows a 2D representation of a possible Restaurant setup, as an example. The objective is for Hero to "deliver" orders from the kitchen to a few tables. Which tables must be reached and in what order will be defined by the judges just before the challenge starts. The restaurant will contain a number of unknown static and dynamic objects (boxes, human actors walking)
The delivery of an order is defined as follows
- Drive up to the table.
- Position near the table, facing towards the table. The robot should be close enough for a customer to comfortably take their order from the tray. The exact part of the table that the robot stands next to does not matter.
- Give a clear sound signal, signalling Hero has arrived at table A (io.speak("I arrived at table four")).
- Repeat until all the tables are visited in the correct order (your robot does not need to return to the starting point)
Environment Specifications
- All walls in the restaurant will be approximately straight. No weird curving walls.
- The tables can be regarded to be solid objects that will show up as rectangles in the LiDAR measurements (So you won't have to detect the table's legs).
- The doors inside the restaurant will be openings in the walls of about 0.5-1m that may be closed or open. Doors can be opened by standing in front of one and having the robot ask for it to be opened.
- There may be multiple routes to a given goal.
- A number of dynamic objects will be present in the form of human actors. Additionally, a number of static objects will be placed throughout the restaurant (including possible chairs next to the tables!). The position does not have to be parallel to the walls.
- Chairs are Not guaranteed to show up as squares in your LiDAR measurements (you might only see the legs!).
- These extra objects will not be present on the map that you're provided ahead of time.
Challenge Conditions
- Hero will start in the start area, defined by a rectangle of approximately 1 by 1 meters. The orientation of Hero is arbitrary (i.e., not known to your software).
- The list of tables to be visited will be provided right before the challenge starts as a list of integers (0 identifies the first table in the array).
- After starting the software, Hero has to drive to the first table to deliver the order.
- If Hero found the correct table and signalled his arrival, he has to drive to the next tables to deliver the orders.
- The task is completed after Hero visited all tables on the list.
- Bonus points are given to the groups that can detect the static and dynamic objects and present them in the world model. How this is presented is left to the groups.
- Within the restaurant start area, we will make sure that some visible features (i.e. lines, corners) remain visible.
- An actual map of the restaurant will be provided to the teams one week before the final challenge, this will encompass a vector map and a gridmap (an example is provided at the bottom of this section).
- Any outside sensing systems, such as the Opti-track, that might have been available during testing will not be available during the final challenge.
Challenge Rules
- The list of tables to visit has to be supplied to the executable when starting the challenge, in the following format (for tables in the order: 2 -> 4 -> 3):
./hero_do_your_thing 2 4 3
- Do not touch the walls or objects! Slightly touching is allowed, however, bumping (i.e., driving head-on into a wall) is not allowed! If Hero hits the wall, we decide whether it counts as bumping.
- Every team has two trials (= max one restart). A trial ends if:
- Hero bumps into: the wall, a static or a dynamic object.
- Hero has not moved or has not made sensible movements (as judged by the tutors) for 30 seconds
- The total time limit of 10 minutes per group is reached
- The group requests a restart (on the first trial)
- restart means:
- Hero restarts at the defined start position
- The trail time (= the time graded) is reset, but
- the total time keeps running
- There will be no second attempt if first attempt was successful
- Every situation that might occur, that is not covered in this document will be evaluated on the spot. If this happens, the judges have the final word.
Robot Software
- Make sure your software is easy to set-up, i.e:
- Your software can be updated with one easy command, e.g. 'git pull'
- Your software can be compiled using 'cmake' and 'make'
- It is allowed to use multiple executables.
- If your set-up deviates from this method, let your tutor know 1 week before the challenge!
- The software of all groups will be updated on the robot the morning before the challenge starts
- This way, teams starting the challenge have as much time as teams that do the challenge at the end, compiling in between trials is not allowed.
Interview
During the final challenge the tutors will interview one person of your group to explain your robots behaviour.
Example map format and code
- We provide a simple example of a room with two tables and the code to read the map into your own C++ code.
- For this simple example, a simulator map is also provided. (Note: a simulator map will not be provided for the final challenge).
- We used the 20cm thickness blocks for your convenience
- Remember to add unknown objects to your simulator and test environments and/or create other challenging maps and test scenarios!
You can find an example map (JSON) and the code to get you started here: File:Mrc map format 2021.zip
An example map (PNG) for the restaurant challenge with more tables is provided here: File:ExampleRestaurantMap.png.
The corresponding data that you could use in a JSON-file is provided here (click 'Expand'):
{ "tables":[ [ [29, 35], [35, 34], [34, 28], [28, 29]], [ [45, 47], [47, 46], [46, 44], [44, 45]], [ [33, 32], [32, 21], [21, 22], [22, 33]], [ [48, 49], [49, 59], [59, 58], [58, 48]], [ [26, 24], [24, 25], [25, 27], [27, 26]], [ [42, 36], [36, 37], [37, 43], [43, 42]], [ [50, 51], [51, 62], [62, 61], [61, 50]] ], "walls":[ [0, 1], [1, 8], [8, 2], [2, 0], [2, 3], [3, 55], [55, 54], [54, 2], [7, 8], [8, 64], [64, 63], [63, 7], [54, 56], [56, 66], [66, 65], [65, 54], [57, 60], [60, 68], [68, 67], [67, 57], [61, 64], [64, 70], [70, 69], [69, 61], [13, 14], [14, 19], [19, 18], [18, 13], [15, 16], [16, 23], [23, 20], [20, 15], [11, 12], [12, 31], [31, 30], [30, 11], [6, 10], [10, 17], [17, 9], [9, 6], [38, 40], [40, 41], [41, 39], [39, 38] ], "doors":[ [ [4, 5], [5, 12], [12, 11], [11, 4]], [ [30, 31], [31, 39], [39, 38], [38, 30]] ], "start_area":[ [ [52, 53], [53, 67], [67, 66], [66, 52]] ], "points":[ {"x": 0.0, "y": 5.0, "_comment": 0 }, {"x": 6.0, "y": 5.0, "_comment": 1 }, {"x": 0.0, "y": 4.8, "_comment": 2 }, {"x": 0.2, "y": 4.8, "_comment": 3 }, {"x": 3.7, "y": 4.8, "_comment": 4 }, {"x": 3.9, "y": 4.8, "_comment": 5 }, {"x": 5.1, "y": 4.8, "_comment": 6 }, {"x": 5.8, "y": 4.8, "_comment": 7 }, {"x": 6.0, "y": 4.8, "_comment": 8 }, {"x": 4.8, "y": 4.5, "_comment": 9 }, {"x": 5.8, "y": 4.1, "_comment": 10 }, {"x": 3.7, "y": 4.0, "_comment": 11 }, {"x": 3.9, "y": 4.0, "_comment": 12 }, {"x": 0.2, "y": 3.8, "_comment": 13 }, {"x": 1.5, "y": 3.8, "_comment": 14 }, {"x": 2.3, "y": 3.8, "_comment": 15 }, {"x": 3.7, "y": 3.8, "_comment": 16 }, {"x": 5.5, "y": 3.8, "_comment": 17 }, {"x": 0.2, "y": 3.6, "_comment": 18 }, {"x": 1.5, "y": 3.6, "_comment": 19 }, {"x": 2.3, "y": 3.6, "_comment": 20 }, {"x": 2.4, "y": 3.6, "_comment": 21 }, {"x": 2.9, "y": 3.6, "_comment": 22 }, {"x": 3.7, "y": 3.6, "_comment": 23 }, {"x": 4.8, "y": 3.6, "_comment": 24 }, {"x": 5.8, "y": 3.6, "_comment": 25 }, {"x": 4.8, "y": 3.1, "_comment": 26 }, {"x": 5.8, "y": 3.1, "_comment": 27 }, {"x": 0.2, "y": 3.0, "_comment": 28 }, {"x": 1.2, "y": 3.0, "_comment": 29 }, {"x": 3.7, "y": 3.0, "_comment": 30 }, {"x": 3.9, "y": 3.0, "_comment": 31 }, {"x": 2.4, "y": 2.6, "_comment": 32 }, {"x": 2.9, "y": 2.6, "_comment": 33 }, {"x": 0.2, "y": 2.5, "_comment": 34 }, {"x": 1.2, "y": 2.5, "_comment": 35 }, {"x": 4.8, "y": 2.3, "_comment": 36 }, {"x": 5.8, "y": 2.3, "_comment": 37 }, {"x": 3.7, "y": 2.2, "_comment": 38 }, {"x": 3.9, "y": 2.2, "_comment": 39 }, {"x": 3.7, "y": 1.8, "_comment": 40 }, {"x": 3.9, "y": 1.8, "_comment": 41 }, {"x": 4.8, "y": 1.8, "_comment": 42 }, {"x": 5.8, "y": 1.8, "_comment": 43 }, {"x": 0.2, "y": 1.7, "_comment": 44 }, {"x": 1.2, "y": 1.7, "_comment": 45 }, {"x": 0.2, "y": 1.2, "_comment": 46 }, {"x": 1.2, "y": 1.2, "_comment": 47 }, {"x": 2.4, "y": 1.2, "_comment": 48 }, {"x": 2.9, "y": 1.2, "_comment": 49 }, {"x": 4.6, "y": 1.2, "_comment": 50 }, {"x": 5.1, "y": 1.2, "_comment": 51 }, {"x": 1.2, "y": 1.0, "_comment": 52 }, {"x": 2.2, "y": 1.0, "_comment": 53 }, {"x": 0.0, "y": 0.2, "_comment": 54 }, {"x": 0.2, "y": 0.2, "_comment": 55 }, {"x": 1.2, "y": 0.2, "_comment": 56 }, {"x": 2.2, "y": 0.2, "_comment": 57 }, {"x": 2.4, "y": 0.2, "_comment": 58 }, {"x": 2.9, "y": 0.2, "_comment": 59 }, {"x": 3.6, "y": 0.2, "_comment": 60 }, {"x": 4.6, "y": 0.2, "_comment": 61 }, {"x": 5.1, "y": 0.2, "_comment": 62 }, {"x": 5.8, "y": 0.2, "_comment": 63 }, {"x": 6.0, "y": 0.2, "_comment": 64 }, {"x": 0.0, "y": 0.0, "_comment": 65 }, {"x": 1.2, "y": 0.0, "_comment": 66 }, {"x": 2.2, "y": 0.0, "_comment": 67 }, {"x": 3.6, "y": 0.0, "_comment": 68 }, {"x": 4.6, "y": 0.0, "_comment": 69 }, {"x": 6.0, "y": 0.0, "_comment": 70 } ] }
You can use the following settings (resolution etc.) in your YAML-file:
image: ExampleRestaurantMap.png #include the (relative) path to where you put the PNG-file resolution: 0.0125 origin: [0.0, 0.0, 0.0] occupied_thresh: 0.9 free_thresh: 0.1 negate: 0
A distorted version of this map, with slightly displaced walls and tables and some added obstacles, is provided here: File:ExampleRestaurantMapDistorted.png.
Map For The Final Challenge
The map for the final challenge will be published here in the week leading up to the final challenge. Clutter will be added (both static and moving) on the day of the challenge, adhering to the rules specified under "Restaurant Challenge".
Group Wiki Pages
During the course you will design your own robotic system under the guidance of a tutor. The tutors are there to guide the process, Not to give answers to the exercises.
As part of your final grade we ask you to report on your progress using the wiki pages below.
Please record on the wiki your answers to the exercises as well as your developments for the final challenge.
Group name | GitLab page | Wiki page | Tutor |
---|---|---|---|
Wall-E | visit GitLab | visit wiki | |
HAL-9000 | visit GitLab | visit wiki | |
R2-D2 | visit GitLab | visit wiki | |
Rosey | visit GitLab | visit wiki | |
The Iron Giant | visit GitLab | visit wiki | |
Ultron | visit GitLab | visit wiki | |
Optimus Prime | visit GitLab | visit wiki | |
Kitt | visit GitLab | visit wiki |
With your wiki page you will convey your approach and your lessons-learned to ‘the outside world’; the tutors and the next generation of MRC students. There are two ways to do this: 1) readable code with comments and 2) a detailed description of your system on the wiki.
We give some guidelines and topics that we will be looking for, but encourage you to be creative: what separates your group from the others?
A main point of interest for the final evaluation will be: the justification behind your design choices and a reflection on them. why did you choose the techniques that you did, what test did you perform to validate them, were the results as expected, and did you change anything on the basis of these results?
Other things that the tutors will look at:
Exercises
- Can we see that you succesfully completed the exercises from your wiki page.
Component selection Restaurant challenge
- Is the choice of components motivated by the challenge?
- Are the components adapted to the requirements of final challenge?
- Does the wiki show an understanding of the algorithms in the component?
Experimental validation of the components
- Are the components tested individually?
- Are the experiments performed a suitable approximation of the conditions of the final challenge?
- Are the conclusions drawn supported by the results of the experiments?
System design for the final challenge
- Is the design presented complete?
- Is the design communicated clearly?
- Are design choices motivated by the final challenge?
Experimental validation of system design
- Are the experiments performed a suitable approximation of the final challenge?
- Are the conclusions drawn supported by the results of the experiments?
Evaluation Restaurant challenge
- Is the behaviour during the final challenge explained?
- Is this behaviour linked back to the designed system?
- If applicable, is an adjustment to the design proposed?
Peer review
At the end of the project we would like each group to hand in a peer review. This should reflect how each group member contributed to the final project. We expect each group member to contribute equally in the technical aspects of the project.
Please consider your peers contributions in the form of:
- Technical expertise
- contributions to System design
- Implementation in software
- Documentation of the project
- Communication during the project
Each of these is of roughly equal importance.
We would like to ask the group to come up with a grade for each member ranging from -1.0 to +1.0 where the sum of all grades is 0.0. Your final grade will be calculated as group_grade + peer_review_grade. The range of -1.0 to +1.0 should be sufficient for most groups where all members contribute equally. If you feel this might not be the case for your group please contact your tutor sooner rather than later.
Practical sessions
- Testing takes place on the RoboCup field in Impuls.
- Three robots will be available for testing, you will share the field with three groups
- Be sure you have your software on git before coming to the test session so that you only have to git clone/git pull to get your code on the robot!
- Please charge the robot whenever possible so there is no down time due to empty batteries.
To submit for a timeslot you have to be logged in. Through the 'edit'-button for Practical sessions, you can select a timeslot by typing your group name behind the desired timeslot.
- You may only reserve 2 test slots per week
- Submissions are last checked the day before at 22:00.
Week #
For week # each group can choose 2 time slots.
Time | Group | |
---|---|---|
[time] | free | free |
[time] | free | free |
[time] | free | free |
[time] | free | free |
[time] | free | free |
[time] | free | free |
[time] | free | free |
Contact Details
This year's staff consists of the following TU/e employees:
- Peter van Dooren (p dot v dot dooren at tue dot nl)
- Koen de Vos
- Aron Aertssen
- Ruben Beumer
- Gijs van Rhijn
- Gijs van den Brandt
- Rudolf Huisman
- Robert de Bruijne
- Jordy Senden
- René van de Molengraft
- Elena Torta