Embedded Motion Control 2015 Group 7: Difference between revisions
| Line 215: | Line 215: | ||
<p>The group is divided into a "detection" group, "movement" group and a "world map" group (usefull in a later stage of the project). The primary ideas and implementations will be discussed in a similar structure.</p> | <p>The group is divided into a "detection" group, "movement" group and a "world map" group (usefull in a later stage of the project). The primary ideas and implementations will be discussed in a similar structure.</p> | ||
== | ==Movement== | ||
'''To be updated later on''': Point-to-point movement, potential field, cornering, obstacle avoidance. | '''To be updated later on''': Point-to-point movement, potential field, cornering, obstacle avoidance. | ||
== | ==Detection== | ||
'''To be updated later on''': Edge detection, gap detection, relative coordinates, dead end detection. | '''To be updated later on''': Edge detection, gap detection, relative coordinates, dead end detection. | ||
== | ==World Map== | ||
'''To be updated later on''':Solving SLAM with use of G-mapping (ROS). | '''To be updated later on''':Solving SLAM with use of G-mapping (ROS). | ||
Revision as of 18:53, 11 May 2015
About the group
| Name | Student id | ||
|---|---|---|---|
| Student 1 | Camiel Beckers | 0766317 | c.j.j.beckers@student.tue.nl |
| Student 2 | Brandon Caasenbrood | 0772479 | b.j.caasenbrood@student.tue.nl |
| Student 3 | Chaoyu Chen | 0752396 | c.chen.1@student.tue.nl |
| Student 4 | Falco Creemers | 0773413 | f.m.g.creemers@student.tue.nl |
| Student 5 | Diem van Dongen | 0782044 | d.v.dongen@student.tue.nl |
| Student 6 | Mathijs van Dongen | 0768644 | m.c.p.v.dongen@student.tue.nl |
| Student 7 | Bram van de Schoot | 0739157 | b.a.c.v.d.schoot@student.tue.nl |
| Student 8 | Rik van der Struijk | 0739222 | r.j.m.v.d.struijk@student.tue.nl |
| Student 9 | Ward Wiechert | 0775592 | w.j.a.c.wiechert@student.tue.nl |
Updates Log
28-04: Updated the page with planning and initial design.
29-04: Updated page with initial design PDf (not yet "wikistyle")
07-05: Small changes in wiki page
09-05: Changes in design (incl. composition pattern, removed components&specifications), primary ideas and evaluating first experiment
11-05: Changes in design (incl. composition pattern), primary ideas and evaluating first experiment
Planning
Week 1: 20 April - 26 April
- Introduction
- Brainstorming initial design
- 27-04 12:00: Deadline initial design
Week 2: 27 April - 3 May
- Download and Install Ubuntu
- Start and Finish C/C++ tutorials
- Additional Brainstorming Design
Week 3: 4 May - 10 May
- Evaluating initial design
- Composition pattern
- Initial Presentation
- 6 May: First presentation design
- implement point-to-point movement
- 8 May: First experiment with Pico
- Implement edge detection, collision avoidance
- Initial Git structure
Week 4: 11 May - 17 May
- Implement edge detection
- Implement obstacle avoidance
- Finish initial software for Pico, with primary functions for corridor competition
- 12 May: Second experiment Pico, check software and robustness
- 13 May: Corridor Competition
Introduction
The goal of the "A-MAZE-ING PICO" challenge is to design and implement a robotic software system that will let robots Pico or Taco autonomously solve a maze in the robotics lab. Software must be designed to complete this goal.
<img src="http://cstwiki.wtb.tue.nl/images/thumb/Gostai-Jazz-500x500.jpg/350px-Gostai-Jazz-500x500.jpg" alt="Robots Pico and Taco">
Design
Proper software design requires the following points to be taken in account: requirements, functions, components, specifications, and interfaces. A top-down structure can be applied to discuss the following initial points.
Requirements
Requirements specify and restrict the possible ways to reach a certain goal. In order for the robot to autonomously navigate trough a maze, and being able to solve this maze the following requirements are determined with respect to the software of the robot. It is desired that the software meets the following requirements:
- Move from A to B
- No collisions
- Detection
- Compatibility with both robots
- Fully autonomous
Functions
To satisfy the said requirements, one or multiple functions are designed and assigned to the requirements. Figure 1.1 describes which functions are considered necessary to meet a specific requirement.
[Image will follow soon]
The function ’Build world model’ describes the visualisation of the environment of the robot. ’Path memory’ corresponds with memorizing the travelled path of the robot. ’Sensor calibration’ can be applied to ensure similar settings of both robots, so that the software can be applied for both.
Interface
The interface describes the communication between the specified contexts and functions necessarry to perform the task. The contexts and functions are represented by blocks in Figure 1.3 and correspond with the requirements, functions, components and specifications previously discussed.
The robot context describes the abilities the robots Pico and Taco have in common, which in this case is purely hardware. The environment context describes the means of the robot to visualize the surroundings, which is done via the required world model. The task context describes the control necessary for the robot to deal with certain situations (such as a corner, intersection or a dead end). The skill context contains the functions which are considered necessary to realise the task.
[Image will follow soon]
Note that the block ’decision making’ is considered as feedback control, it acts based on the situation recognized by the robot. However ’Strategic Algorithm’ corresponds with feedforward control, based on the algorithm certain future decisions for instance can be ruled out or given a higher priority.
To further discuss the interface of Figure 1.3, the following example can be considered in which the robot approaches a T-junction: The robot will navigate trough a corridor, in which information from both the lasers as the kinect can be applied to avoid collision with the walls. At the end of the corridor, the robot will approach a T-junction. With use of the data gathered from the lasers and the kinect, the robot will be able to recognize this T-junction. The strategic algorithm will determine the best decision in this situation based on the lowest cost. The decision will be made which controls the hardware of the robot to perform the correct action. The T-junction is considered a ’decision location’, which will be saved in the case the robot is not capable of solving the maze with the initial decision at this location. During the movement of the robot, the walls are mapped to visualise the surroundings.
Composition Pattern
To be updated later on: figure, toelichting (presentation)
Initial software, testing and Corridor competition
The first steps of actually coding the software is based on the requirements necessary for the corridor competition. In order to pass the corridor assignment succesfully, PICO should be capable of:
- Move from point A to point B
- Avoid collisions with walls/obstacles
- Detect edge corners in corridor
- Taking corners (with relative coordinates of detected edge)
- Detect end of test
The group is divided into a "detection" group, "movement" group and a "world map" group (usefull in a later stage of the project). The primary ideas and implementations will be discussed in a similar structure.
Movement
To be updated later on: Point-to-point movement, potential field, cornering, obstacle avoidance.
Detection
To be updated later on: Edge detection, gap detection, relative coordinates, dead end detection.
World Map
To be updated later on:Solving SLAM with use of G-mapping (ROS).