Assignment 2: Threading, Synchronisation and Data Integrity

General Information

Intent: Skills in utilising, classes, abstraction, data structures, threading, data synchronisation and documentation will be assessed.

Individual Task

Weight: As per subject outline

Task: Write a program in C++ using object-oriented paradigms that controls Mechatronic platforms with a number of threads. Ensure data integrity between threads and enable relating data between them via suitable data structure that enables time synchronisation and subsequently interpolation of data for task at hand. Supply appropriate autogenerated documentation utilising inline source mark-up.

Rationale: In a Mechatronics System, several platforms can be coordinated to complete a series of tasks. Decisions need to be made based correctly in near real-time. Threading and synchronisation are ways to ensure the system performs as intended, with guarantees on the responsiveness of the system to incoming task changes, processing constraints and system behaviour.  

Your task is to (a) create a number of threads that can coordinate platform in reaching a series of goals (b) implement a graph, and search the graph for optimal paths, incorporating information about the platform motion into the graph (c) create a separate thread(s) to process the goals provided and ensures simultaneous execution of reaching goals (mission) between platforms.

Due: As per subject outline

Specifics

This document to be read in conjunction with 2024a_a2_skeleton code available in your git repositories. The assignment uses a physics simulator called gazebo. Students are provided access to the simulator via pfms-support, they need to update to the latest version of all support files following the UPGRADE instructions on pfms-support.  

Students are provided skeleton code in a2_skeleton folder that they need to use and develop from. There are two

Interface Classes MissionInterface and ControllerInterface that stipulate the functionality of the Mission or Controller/Ackerman/Quadcopter class. The Controller class is the base class for Ackerman/Quadcopter. On the level of controlling the individual platforms, we build from assignment 1, while mission has different functionality.

There are two platforms that are used to accomplish a mission, a quadcopter (drone) and Audi R8 (vehicle with

Ackerman steering), further details on platforms are in Platform Audi R8: Ackerman and Platform Drone: Quadcopter.

The task for the platforms is to go through a series of goals they are provided and therefore act as if they are patrolling a space.  

There are three modes of the assignment, where mission coordinates simultaneously both platforms to accomplish following modes: BASIC / ADVANCED / SUPER mode.  Students should attempt ADVANCED MODE (which unlocks D/HD for execution) ONLY if they have completed the BASIC MODE.  SUPER mode is for bonus points above the 100 for this assignment. Functionally each mode is described below:

• BASIC MODE – mission receives platforms go through a series of goals supplied (no optimal path selection)
• ADVANCED MODE – mission determines an optimal path selection for each platform (minimal total distance travelled visiting goals). Once mission determines the paths it coordinates the platforms through these goals.
• SUPER MODE – mission uses Quadcopter to survey a possible path selection for Ackerman to go through a field with obstacles from bottom left corner to top right corner. It sends quadcopter to determine the locations of obstacles (cuboid of known dimensions 7x7x4.5 - WxDxH). Then needs to produce goals for the Ackerman to travel through maze. Refer to our Mission tests for a good strategy to supply paths.

In building a complete solution you will make two libraries, are provided unit tests and have a main that demonstrated the use of the libraries.  

To start the simulation, run: ros2 launch gazebo_tf a2.launch.py

An example main has been provided where it run as follows

• Read two files with goals (Points in 3d : x,y,z), one for Ackerman, the other for Quadcopter. o The files are supplied as parameters on command line (example provided)
• Create an Ackerman
• Create an Quadcopter
• Create Mission (passing the platforms)
• Pass the objective (BASIC, ADVANCED, SUPER) to mission
• Provide the goals to Mission and platform type for the goals in setGoals (function should be called twice, once for each pair: goals and platform)
• Call run in Mission which executes the mission o run should be non-blocking

o the execution reachGoal inside each platform should also be non-blocking

• Every 200ms call status in Mission, to check on progress (will return percentage of completion as distance travelled vs total distance needed)
• Terminate when mission is complete

All marks for execution will be derived from unit tests, the main is an example for your own development and the behaviour of what occurs if you run the executable built from the main should be described in index.dox

Platform Audi R8: Ackerman  

The Audi R8 is a vehicle that has Ackerman Steering, for a video introduction on how to use the Ackerman steering model please see an excellent video by Jonathan Sprinkle.  in essence, for control the vehicle can be approximated with a single tyre at front and back (known as bicycle model -geometric vehicle model), the wheel base T and distance between front/back wheel L.  δ and the radius of turn R are related. We assume only geometry plays part and no dynamics (no drifting on track).  

The steering wheel to wheel position is via a STEERING RATIO, the total number of turns (lock to lock) governs maximum steer angle. The distance between wheels is knows as wheel base (L).  

The control of the platform is via 3 values

Students can use audi library supplied via pipes which contains functionality per header file audi.h .

Platform Drone: Quadcopter

The quadcopter has four rotors that allow it to move in any direction, turn on spot, as well as go up/down. If the platform is not above ground, it will crash and stop running.  The control of the platform is via 4 control values

For the drone to start moving, it first needs to lift off the ground, which requires sending a specific command to TAKEOFF as demonstrated in a1_snippets/command_uav.cpp. You do not need to do any LANDING in this assignment.

The objective is to minimise total distance travelled, and therefore the total speed is not limited. If going fast, you do need to consider time to stop (inertia exists) which might make it be more difficult to control.  

All goals are on same height for this assignment. However, some rudimentary control of height Z for this assignment may be required as to not land on the group or clip car. Best to keep height at ~ 2.m (control up/down).

Mission Planning & Controller (Platform) Behaviour

BASIC mode 

The mission planning simply passes the goals as supplied to the platforms (Quadcopter AND Ackerman) for execution. When calling run (which is a non-blocking call - call to run should return instantaneously) the platforms perform execution simultaneously, going through the goals in separate threads of execution.  

The platforms compute the distance that needs to be travelled to reach all goals supplied (in the order provided) and have a status function that indicates if they are idle or running (IDLE – not active goals and RUNNING – travelling to goals).

If Mission status is requested, it returns the percentage of completed mission, which is percentage of distance travelled by both platforms compared to required total distance.  

As we estimate total distance travelled at the beginning, often as we move we are very far from the estimate. I suggest to update your estimate as you approach goals (thereby recalibrating your estimate) and reach 100 only when you complete the mission.

ADVANCED mode

The mission planning needs to determine the ordering the goals will be visited for each platform ensuring all goals are visited only once.  Thereafter on run it passes the goals as supplied to the Quadcopter AND Ackerman for execution. The behaviour of platforms and mission thereafter in control (going to the goals) is the same as in BASIC mode.

A graph search (travelling salesman problem) is the best way to handle computing the ordering, and this becomes a combinatorial search committing to a certain order of visiting goals. You will need to consider the Ackerman control (the steering), keeping it constant between goals enables simpler mission planning. On completing the ordering of goals, the mission passes the goals as supplied to the platforms (Quadcopter AND Ackerman) for execution. Function std::vector<std::pair<int, int>> getPlatformGoalAssociation(); shall  return the derived order and association and NEEDS to be used for testing.

For ADVANCED mode a total of 10 goals (5 were given to each platform and then combined).

SUPER mode

The mission planning needs to Quadcopter to survey a possible path selection for Ackerman to go through a field with obstacles from bottom left corner to top right corner. It sends quadcopter to determine the locations of obstacles (cuboid of known dimensions 7x7x4.5 - WxDxH). ). Then needs to produce goals for the Ackerman to travel through maze.  The obstacles are distributed as a lattice (3 rows and 5 columns), in testing it remains a lattice where the distance between rows and columns may change (between 0-5m). The starting position for Ackerman (x=-80, y=70) and end position (x=80, y=-70) whereas you can select starting position for Quadcopter (I would advise to keep it close to Ackerman).  

We advise to use the laser to determine obstacles, details of how to obtain laser readings were distributed in week 08 and are part of PfmsConnector.

You will need to unit test your strategy to determine obstacles `virtual std::vector<pfms::geometry_msgs::Point> getObstacles(void) = 0;`  And the strategy for goals (supply them to be tested). The Quadcopter needs to use the Laser attached to it, to determine the cuboid.

Thereafter on run it passes the goals as supplied to the Ackerman for execution. The behaviour of platforms and mission thereafter in control (going to the goals) is the same as in BASIC mode.

Library Testing

The testing will attempt to test the Controller Classes (Quadcopter and Ackerman) validating

• Reaching goals (directly via controller status)
• Reaching goals (via mission status)
• Mission for both controllers
• TSP for Ackerman
• TSP for Quadcopter

Unit testing has been enabled by default, they can be disabled via set(BUILD_TESTS OFF)If your tests are succeeding you should get all green in execution of tests.   

If you're attempting the SUPER section of the assignment, you will need to supply your own unit tests  as discussed in Misison Planning and Control.

Assessment Criteria Specifics

FAQ – Will be updated in Week 08