Embedded Motion Control 2019 Group 3
Group members
| Collin Bouwens | 1392794 | |
| Yves Elmensdorp | 1393944 | |
| Kevin Jebbink | 0817997 | |
| Mike Mostard | 1387332 | |
| Job van der Velde | 0855969 |
Planning
This table is awful and needs to be redone. Suggestions?
| Week 2 | Week 3 | Week 4 | Week 5 | Week 6 | Week 7 | Week 8 |
|---|---|---|---|---|---|---|
| Wed. 1 May: initial meeting: getting to know the requirements of the design document. | Mon. 6 May: design document handed in by 17:00. Responsibility: Collin and Mike. | Wed. 15 May: escape room competition. | Wed. 5 June: final design presentation. | Wed. 12 June: final competition. | ||
| Tue. 7 May: first tests with the robot. Measurement plan and test code is to be made by Kevin and Job. | ||||||
| Wed. 8 May: meeting: discussing the design document and the initial tests, as well as the software design made by Yves.
Presentation of the initial design by Kevin (?) during the lecture. |
Design document
asdasd
Requirements
asdasd
Functions
asdasd
Components
asdasd
Specifications
asdasd
Interfaces
asdasd
Test Plan
For next tuesday, when we have our first time available with the robot, we want to extract all information about the limitations of the sensors. We want to look at the functionality of all sensors and actuators, and see how precise these are and how much noise is present. For the lasersensor, we want to know the maximum and minimum range, as well as the minimum and maximum angle. It is interesting to
Meeting notes
Week 2 - 1 May
Every following meeting requires concrete goals in order for the process to make sense. An agenda is welcome, though it does not need to be as strict as the ones used in DBL projects. The main goal of this meeting is to get to know the expectations of the design document that needs to be handed in next monday, and which should be presented next wednesday. These and other milestones, as well as intermediate goals, are to be described in a week-based planning in this Wiki.
Design document
The focus of this document lies on the process of making the robot software succeed the escape room competition and the final competition. It requires a functional decomposition of both competitions. The design document should be written out in both the Wiki and a PDF document that is to be handed in on monday the 6th of May. This document is a mere snapshot of the actual design document, which grows and improves over time. That's what this Wiki is for. The rest of this section contains brainstormed ideas for each section of the design document.
Requirements:
- The entire software runs on one executable on the robot;
- The robot is to autonomously drive itself out of the escape room;
- The robot may not 'bump' into walls, where 'bumping' is judged by the tutors during the competition;
- The robot has five minutes to get out of the escape room;
- The robot may not stand still for more than 30 seconds.
Functions:
- Detecting walls;
- Moving;
- Processing the odometry data;
- Following walls;
- Detecting doorways (holes in the wall).
Components:
- The drivetrain;
- The laser rangefinder.
Specifications:
- Dimensions of the footprint of the robot, which is the widest part of the robot;
- Maximum speed: 0.5 m/s translation and 1.2 rad/s rotation.
Interfaces:
- Gitlab connection for pulling the latest software build;
- Ethernet connection to hook the robot up to a notebook to perform the above.
Measurement plan
The first two time slots next tuesday have been reserved for us in order to get to know the robot. Everyone who is able to attend is expected to attend. In order for the time to be used efficiently, code is to be written to perform tests that follows from a measurement plan. This plan involves testing the limits of the laser rangefinder, such as the maximum distance that the laser can detect, as well as the field of view and the noise level of the data.
Software design
The overall thinking process of the robot software needs to be determined in a software design. This involves a state chart diagram that depicts the global functioning of the robot during the escape room competition. This can be tested with code using the simulator of the robot with a map that resembles the escape room layout.