Embedded Motion Control 2019 Group 3

Group members

Collin Bouwens		1392794
Mike Mostard		1387332
Kevin Jebbink		0817997
Yves Elmensdorp		1393944
Job van der Velde		0855969

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.

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