Embedded Motion Control 2017 Group 5

From Control Systems Technology Group
Revision as of 09:06, 29 May 2017 by S117413 (talk | contribs)
Jump to navigation Jump to search

System Architecture

This section describes the development of the system architecture. First, the system context is introduced, whereafter the translation from the established requirements to functions the system should perform is covered. Finally, these functions are assigned to separate subsystems and the information flow between these subsystems is specified.

System Context
The beginning of the development of the complex system that is the PICO controller starts by considering it as a black box: Something goes in and something else comes out. The system will gather information from the wheel encoders and the Laser Range Finder (LRF) and send actuation commands to the holonomic base accordingly. A system context diagram depicting this flow of information is shown below:

SystemContext.jpg


Functionality
From the requirements list several functionalities can be extracted, which are arranged using the Task-Skill-Motion hierarchy. In this hierarchy one main task, the most abstract and all-embracing functionality, is specified. In this case the main task is to exit the maze. To perform this task a combination of several subordinate functionalities, the skills, is necessary. Finally, the motions are one level deeper than the skills and contain basic functionalities. The relationships between functionalities can be classified as "include" or "extend" types, which complete the hierarchy as shown below.

Functionality.jpg

An include relationship indicates that the functionality at the arrow tail is a necessary part of the arrow head function, while an extend relationship means that the arrow tail functionality can be a follow-up action of the one on the arrow head.


Subsystems
The previously introduced functionalities are grouped together to create the subsystems WorldMap, ActionManager and MovementController. Every subsystem will be responsible for executing any of these functionalities. The figure below shows that the main system is composed of these three subsystems and the functionalities they are mapped to:

Architecture.jpg

Initial Design

The Initial Design document can be found here: Initial_Design_Group5.

Maze-solving Algorithms

Wall follower
This algorithm is very simple to implement since only one rule applies: Follow the wall on either your left or right side (depending on the setting). This wall will be tracked until eventually, an exit is found. The algorithm is guaranteed to work when the robot starts at the entrance of a maze. However, if PICO starts at an arbitrary position it might get stuck in a loop, keeping track of the walls of an ‘island’. Since the case description states that the robot will be start from an arbitrary position and that the maze will contain a loop, this algorithm is risky to use and might not be able to guide the robot to the exit.

Pledge algorithm
The Pledge algorithm is very similar to the wall follower, but contains an upgrade to enable the robot to break free from isolated islands. The robot is given a preference direction (north, south, east or west) and follows this heading until it bumps into a wall. Then, an arbitrary (left or right) wall follower starts and keeps track of the orientation of the robot. This wall follower stops when the robot is heading towards the preference direction again and the orientation is zero degrees. Note that for this case, zero degrees is not equal to 360 degrees. Special care has to be taken when the maze is not made up of straight-angled corners, which is luckily not the case in this specific application. The Pledge algorithm is still fairly simple and guaranteed to find the exit of the maze.

Trémaux algorithm
The Trémaux algorithm is a more efficient, but also more complex algorithm. This algorithm keeps track of where PICO has already been by marking paths between junctions. When a junction is detected, a decision is made based on the markings that are already present on the other paths of the junction. The increased efficiency of the algorithm imposes more dependency on the detection of maze elements and maintenance of a world map.

Meetings Overview

Brief summaries on the contents of team meetings are available here: [1]

Members Group 5

Name Student ID Email
Torben Beernaert 0778690 t.f.beernaert@student.tue.nl
Rodrigo Estrella Treviño 1035228 r.estrella.trevino@student.tue.nl
Kagan Incetan 1037760 k.incetan@student.tue.nl
Sjoerd Knippenberg 0738104 s.c.m.knippenberg@student.tue.nl
Angel Molina Acosta 1036456 a.molina.acosta@student.tue.nl
Bart Vercoulen 0747283 b.c.g.vercoulen@student.tue.nl
Wouter Houtman - w.houtman@tue.nl