Embedded Motion Control 2019 Group 9: Difference between revisions

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


The composition of group 9 has changed twice. At first, George Maleas decided to quit the course at the 13th of May, two days before the escape room competition. At second, Merijn Floren also quit the course on the 3rd of June. <<REASONS WHY THEY QUIT, IS ALREADY ASKED TO THEM>>. The code for the final challenge was written by Janick Janssen, Merijn Veerbeek and Nicole Huizing.
The composition of group 9 has changed twice. At first, George Maleas decided to quit the course at the 13th of May, two days before the escape room competition. At second, Merijn Floren also quit the course on the 3rd of June. <<REASONS WHY THEY QUIT, IS ALREADY ASKED TO THEM>>. The code for the final challenge was written by Janick Janssen, Merijn Veerbeek and Nicole Huizing.
= Code architecture =
The code architecture can be visualized as in the following picture:
[[File:code_architecture.jpeg|center|thumb|350px]]
And the pseudocode is structured as follows:
* World model (Merijn V)
The world model contains all information about the world. It stores all useful variables.
All functions for updating a variable or obtaining a variable value are coded in this part.
''Pseudocode:''
void getDistance():
    return DISTANCE_VALUE
double updateDistance( newvalue ):
    DISTANCE_VALUE = newvalue
* Perception (George)
Obtains sensor data and translates the data to useful data that the robot can use.
For example, it obtains the sensor data from the LRF and calculates the value of the distance. It updates this value in the worldmodel. (It will use a function like worldmodel.updateDistance( NEWDISTANCE ).
The perception part is the owner of the data variables stored in the world model. ONLY the perception module can update these variables. All other modules can only read these values for their required tasks.
Input: None
Output: Sensor data
''Pseudocode:''
While true:
    Worldmodel.updateDistance( Data_From_LFR )
* Monitoring (George)
The monitoring module uses sensor data and does calculations with it. For example it determines if the robot is close to a wall or when the robot has turned 90 degrees. It will uses function like worldmodel.getVariable() to obtain the data and worldmodel.updateVariable(newvalue) to communicate with the worldmodel.
The monitoring model is the owner of all of its output data and is the only part that can change these values. All other modules can only read the values produces by these module from the world model.
Input: Sensor data variable (from worldmodel. Worldmodel gets them from perception module)
Output: Processed data
''Pseudocode:''
While true:
    Angle = worldmodel.getAngle()
    If angle > 90:
        Worldmodel.setTurn90(true);
    Distance = worldmodel.getDistance()
    If distance < threshold:
        Worldmodel.setCollisionDistance(true);
* Planning (Merijn V & Janick)
This part determines what the motor should do. It determines what actions should be done based on the variables In the world model. This module is a FSM.
This module produces control actions for the motor controllers.
Input: Sensor data and (mostly) data from the monitoring module.
Output: Control actions (states in which the motor should be)
The planning module is the owner of the data it puts out.
''Pseudocode:''
typedef enum
{
    turning = 1,
    forward,
    backward,
} state; // This part will be in a header file
// Maybe the state of the planning module doesn’t need to be in the worldmodel
While true:
    Switch(worldmodel.getPlanningState())
    case turning:
        if worldmodel.getTurn90(): // has the robot turned 90 degrees
            worldmodel.updateMotorState( MOVEFORWARD )
            worldmodel. updatePlanningState ( forward )
    case forward:
        if WHATEVERCONDITION:
            worldmodel.updateMotorState( SOMETHING)
            worldmodel.updatePlanningState( something)
* Controller (Nicole)
This part controls activates the actuators. It should do the action determined by the planning module.
Input: Motor state
Output: None (optionally its current state, but I don’t think this is necessary)
''Pseudocode:''
While true:
    Switch(worldmodel.getMotorState())
    Case MOVEFORWARD:
        Pico_drive.moveForward(Speed)
    Case MOVEBACKWARD:
        Pico_drive.moveBackWard(Speed)
    Case TURNING:
        Pico_drive.turn(rotatespeed)


= Initial Finite State Machine model =
= Initial Finite State Machine model =

Revision as of 14:44, 13 June 2019

Group members


Nicole Huizing | 0859610
Janick Janssen | 0756364
Merijn Veerbeek | 0865670

Design Document

The Initial Design document can be found here: File:Initial Design Group9.pdf

The powerpoint presentation about the design is in this file: File:Presentation initial design.pdf

The powerpoint presentation about the final design can be found here: File:Presentation final design group9.pdf

Logbook

The composition of group 9 has changed twice. At first, George Maleas decided to quit the course at the 13th of May, two days before the escape room competition. At second, Merijn Floren also quit the course on the 3rd of June. <<REASONS WHY THEY QUIT, IS ALREADY ASKED TO THEM>>. The code for the final challenge was written by Janick Janssen, Merijn Veerbeek and Nicole Huizing.

Initial Finite State Machine model

The system will make use of a Finite State Machine model. The will take up the task of the executing the plan of the robot and determines the high-level control.

Link to Wikipedia:Finite-state machine.

An image will be added when image is ready.

Retrieved from "https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2019_Group_9&oldid=77123"