Embedded Motion Control 2019 Group 3

From Control Systems Technology Group
Jump to navigation Jump to search

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

The test plan describes the initial tests executed on the Pico robot to determine its functionality. The document also describes the initial setup required to couple the robot to a laptop.

Goal

The goal is to perform the initial setup of the robot and to determine the actual properties of the laser range finder, encoders and drive train. For the laser range finder, these properties consist of the range, angle, sensitivity and amount of noise. The most important property for the encoder is its accuracy.

The most important properties of the drivetrain are its accuracy, and its maximum translational and rotational acceleration for smooth movement.

Simulation results

The range of the laser range finder according to the simulation is 10cm to 10m, the angle is +114.6 to -114.6 degrees as measured from the front of the robot. This angle is measured in 1000 parts, per an amount of time that can be determined by the user.

Execution

Initial setup

The initial setup for connecting with the Pico robot is described on the following wiki page: [[1]]

Laser range finder

Two tests can be executed to determine the range, angle and accuracy of the laser range finder. First of all, the output values from the range finder can be saved in a file and compared to actual measured values. The second option is to program the robot drive backward slowly while facing a wall. The program should stop the robot as soon as it does not register the wall anymore. The same can be done while driving forward to determine the minimum range. To determine the angle the robot can be rotated.

Encoders

The values supplied by the encoders are automatically converted to distance in the x- and y-direction and a rotation a in radians. These can be compared to measured values in order to determine the accuracy.

Drive train

The maximum acceleration of the robot can be determined by finding the amount of time it takes over which the maximum velocity of the robot is achieved in a smooth manner. The maximum translational velocity of the robot is set to 0.5 m/s and the maximum rotational velocity to 1.2 rad/s.


Results

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.

Tasks

Collin and Mike: write the design document and make it available to the group members by saturday.

Kevin and Job: write a test plan with test code for the experiment session next tuesday.

Yves: draft an initial global software design and make a test map of the escape room for the simulation software.