Embedded Motion Control 2015 Group 1: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 116: Line 116:


=== Functions ===
=== Functions ===
Test
The functions of the system are classified according to three levels: high-level, mid-level, and low-level functionalities.
 
The high-level functionality incorporates the following three aspects:
\startitemize
\item Obtain relative position with respect to the global frame of reference in the maze.
\item Identification of the open or closed door.
\item Maze solving algorithm or strategy.
\stopitemize
 
The mid-level functionality consists of:
\startitemize
\item Straight corridor navigation.
\item Collision avoidance algorithm.
\item Intersection mapping.
\stopitemize
 
The low-level functionality contains:
\startitemize
\item The ability to read the laser and camera input.
\item Actuate the wheels according to the input.
\item System initialization for the working of the sensors and actuators.
\stopitemize


= Potential Field =
= Potential Field =

Revision as of 17:16, 17 May 2015

Embedded Motion Control (EMC) Group 1 is a multidisciplinar and multilingual project group working on the 'A-MAZE-ING PICO'. This wikipedia page consists of the weelky progress presented in the journal, the written report and some other practical and useful stuff.

The report focussus on the individual components of the software architecture, this includes basic idea description, mathematical analyses and possible software implementation.

Journal

The proces of developing a software architecuter and the implementation requires great coordination and collaboration. This journal will be updated to present and track the progress of the group. This journal includes weekly progress, countered problems and divided tasks.

Meetings

1. Thursday 23: 12:45 - 13:30 in OGO19

2. Wednesday 29: 10:15-11:00 in OGO17

3. Friday 1 May: ?-? in ?

Design Architecture

Design architecture group1.jpg

In this section, the initial idea of an embedded software design will be discussed. The main goal of the design is to make the Pico robot able to solve a maze. In this brief report, the requirements, functions, components specifications, and the interfaces of such a system will be discussed.

Requirements

The requirements of the system will be divided according to the FURPS model. The abbreviation of this model stands for Functionality, Usability, Reliability, Performance, and Supportability. Functionality in this case denotes the features and capabilities of the system. Usability includes the human factors, consistency, and aesthetics. Reliability stands for the failure frequency, accuracy, predictability, et cetera. Performance here means the efficiency, speed, response, i.e. measures of system performance. Finally, the supportability incorporates testability, maintainability, configurability, and so forth.

The main requirement of the system will be to navigate the maze. It must be completed according to the challenge specification, which forms the main functional aspect of the requirements.

Furthermore, the system design must be robust. The layout of the system must constitute all possible functions to account for the various system architecture, which enable the usability of that design. To achieve this, possible fault modes can be taken into account.

Also, the system design should pose a robust solution. This means the provided system solution must be robust enough to cope with the environmental uncertainties, so that the solution as a whole is reliable.

Next, the doors in the maze should be handled correctly. The behaviour of the door should be analysed to help differentiate the door from the wall. Firstly, the robot should be able to recognize a door from a wall and, secondly, cross the door.

Fifthly, the generated design should be tested for its reliability, and accordingly changes are required to be captured to improve the same.

Furthermore, The major functional requirement of the robot is the ability to solve the maze on its own.

Next, the given hardware (PICO robot) must be used for the maze challenge without any modification and additional components mounted on it.

Penultimately, the performance requirement of taking quick decision is one of the essential factors for the PICO robot for completing the challenge within 7 minutes.

And finally, the need for smart decision making is a crucial necessity due to the fact that the environment changes.

In the table below, the above requirements are summarized according to the FURPS structure.

Summary of requirements according to the FURPS model.
Requirement F U R P S
Navigate the maze x
Subsystem based design x
Adaptable to environment x
Door handling x
Testing and simulation x
Autonomous operation x
Use given hardware x
Fast decision making x
Smart decision making x

Functions

The functions of the system are classified according to three levels: high-level, mid-level, and low-level functionalities.

The high-level functionality incorporates the following three aspects: \startitemize \item Obtain relative position with respect to the global frame of reference in the maze. \item Identification of the open or closed door. \item Maze solving algorithm or strategy. \stopitemize

The mid-level functionality consists of: \startitemize \item Straight corridor navigation. \item Collision avoidance algorithm. \item Intersection mapping. \stopitemize

The low-level functionality contains: \startitemize \item The ability to read the laser and camera input. \item Actuate the wheels according to the input. \item System initialization for the working of the sensors and actuators. \stopitemize

Potential Field

Report-like explanation of the potential field: the working principle, the underlying mathematics and, the implementation.

Lower Level Skills

Explanation of the decision making algorithm and the low level skills used to drive the robot.

Corridor Challenge

Preparation of the Embedded Motion Control #Corridor Competition and the results shown in a short movie.

Appendix

The Appendix consists of the unrelevant parts of the report. This includes a list of the group members and some tips and tricks for programming.

Group members

Group 1 consists of the following members:

Name Student nr Email
Maurice Poot 0782270 m.m.poot@student.tue.nl
Timo Ravensbergen 0782767 t.ravensbergen@student.tue.nl
Bart Linssen 0786201 a.j.m.linssen@student.tue.nl
Rinus Hoogesteger 0757249 m.m.hoogesteger@student.tue.nl
Nitish Rao 0927795 n.rao@student.tue.nl
Aakash Amul 0923321 a.v.h.amul@student.tue.nl
Ignacio Vazquez 0871475 i.s.vazquez.rodarte@student.tue.nl

Qt from terminal

If Qt Creator is not run from the terminal, the programs inside cannot connect to the ROS master. To be able to run Qt Creator from the desktop without any problems, follow a similar procedure to the one that is used in the Customizing Ubuntu tutorial for the Terminator file:

Edit

~/.local/share/applications/QtProject-qtcreator.desktop

and change the third line to:

Exec=bash -i -c /home/rinus/qtcreator-3.3.2/bin/qtcreator

This will run QtCreator from a terminal even if the desktop icon is used.