Embedded Motion Control 2019 Group 3: Difference between revisions
Line 83: | Line 83: | ||
= Meeting notes = | = Meeting notes = | ||
== Week 2 - 1 May == | == Week 2 - 1 May == | ||
{ | {| role="presentation" class="wikitable mw-collapsible" | ||
| <strong>Lorem ipsum</strong> | |||
|- | |||
| | |||
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. | 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. | ||
Line 120: | Line 123: | ||
=== Software design === | === 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. | 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. | ||
|} |
Revision as of 13:56, 2 May 2019
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
Lorem ipsum |
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 documentThe 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:
Functions:
Components:
Specifications:
Interfaces:
Measurement planThe 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 designThe 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. |