Assignment 1: Utilising Abstraction of Sensor Classes

03 Mar 2024 – Initial Release (Marking criteria to be finalised ; tests yet to be supplied)

Intent: Skills in utilising, classes, functions, pointers and utilising abstraction, encapsulation, inheritance,
polymorphism with appropriate documentation will be assessed.

Individual Task

Weight: 20%

Task: Write a program in C++ using object-oriented paradigms that embodies a range of platforms, utilising
abstraction, encapsulation, inheritance and polymorphism. Supply appropriate auto-generated documentation
utilising inline source mark-up.

Rationale: In a Mechatronics System we would use a class to represent a real-world object such as a robotic platform
(vehicle, drone). In large projects to facilitate testing it is common to develop a mock (fake) platform class that behaves
the same as the real platform. This allows for some system testing without the presence of all hardware.

Platform control of similar nature are often abstracted from a base platform (ie. moving a platform to reach a goal has
similar functionality, but depends on the platform kinematics/design). This allows treating a suite of platforms in an
abstract manner when navigating them to goals for a mission, the remaining of our processing code can be agnostic
to the platform type.

Due: As per Subject Outline

Contents
Contents ............................................................................................................................................................................ 1
Assignment Specifics ..................................................................................................................................................... 2
Code development ........................................................................................................................................................ 3
Assessment Criteria ...................................................................................................................................................... 4
Platform: Audi R8 (Akerman Steering).......................................................................................................................... 6
Platform Drone: Quadcopter ........................................................................................................................................ 7
Automated testing of code ........................................................................................................................................... 8
FAQ ................................................................................................................................................................................ 9
Assignment Specifics
The assignment uses a physics simulator called gazebo. Students are provided with the simulator; installation
instructions are in the README.md file under https://github.com/41012/pfms-support.

Students are provided skeleton code in a1_skeleton folder in your repository (under 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 and Controller classes respectively. The Controller class is the base class for
Ackerman and SkidSteer.

There are two ground vehicle platforms that are used to accomplish missions, an Audi R8 (vehicle with Ackerman
steering) and a Husky (vehicle with Skid Steering). Dynamic constraints for the Audi R8 (Ackerman) are provided
below, it grips the road and travels predictably unless it is drifting (which low throttle will avoid). It is controlled by
steering, brake and throttle. The skid steer platform needs to skid to turn, it can turn on the spot roughly.

The goal of the assessment is simply to coordinate the platforms slowly (like a learner driver) and allowing to
compute estimates of time and distance to travel to goals (which ignore effects of acceleration and assume constant
velocity for travel). The Ackerman platform should be controlled via a constant steering angle (so it travels in arcs of
a circle) and fixedthrottle. The SkidSteer platform should be controlled via a constant turn rate (turns on the spot).
These constraints allow easier control, though for stopping I would suggest some P control to stop at goal.

You have been supplied a very simple main that accepts goals (locations in 2d with x,y) instantiates the platforms
and provides them to the Mission class. Calling runMission (of the Mission class) drives to goal(s) a platform at a
time (they do not move simultaneously – we will do this when we learn threading for assignment 2). Upon
completing the current mission new goals can be provided.

All goals are supplied in world coordinates (right handed coordinate system with X-forward, Y-left and therefore
positive angle from X to Y. The local coordinate frame of each platform is superimposed on the platforms in Fig 1,
red as X (forward) and Y (left). There is an a1_snippets folder in your repository (under skeleton folder) that has
example of sending commands and getting odometry from those platforms.

Figure 1 - (left) Ackerman (right) SkidSteer platform with coordinate system displayed
Code development
Create a Base Class Controller and a derived Classes Ackerman and SkidSteer.

The Controller will need to inherit (use as base class) the ControllerInterface (this is an abstract class) and
implement its virtual functions without changing the function declarations (signatures). The Controller is the base
class for Ackerman and SkidSteer. The Mission class inherit (use as base class) the MisssionInterface (this is an
abstract class) and implement its virtual functions without changing the function declarations (signatures).

Students need to determine and implement functions from ControllerInterface in Controller and/or
Ackerman/SkidSteer. These design choices are marked and examine your knowledge of Base/Derived classes.

The derived class from Controller Ackerman will need to

1. Inherit from Controller

2. Initialise all the required variables to enable use via default constructor

The derived class from Controller SkidSteer will need to

1. Inherit from Controller

2. Initialise all the required variables to enable use via default constructor

The Mission Class will need to

1. Inherit from MissionInterface

2. Implement all the functionality specified in MissionInterface

Your code will be unit tested and you have been supplied three tests (60% of unit tests).

• These tests are to be supplied by midnight Wed 6th March 2024

You can also use your main to test.

Assessment Criteria
Criteria Weight (%) Description / Evidence Further Breakdown
20 Use of special member functions for initialisation Use of special member functions for initialisation of classes
Classes exploit of classes such that they can be used with default such that they can be used with default settings. 20
abstraction settings. I/O to terminal only in Main 10
(encapsulation, Correct use of access specifiers 20
Correct use of access specifiers.
inheritance and
polymorphism) to Classes that should not be available for instantiation are aptly
Inheritance from base class, common data stored protected. 25
cover a range of
and generic functionality implemented solely in
sensors
base class (no duplication).

Classes that should not be available for Inheritance from base class, common data stored and generic
instantiation are aptly protected. functionality implemented solely in base class (no duplication). 25
Code execution 55 All code execution is assessed via Unit Tests. Unit TESTS TO BE ADVISED by midnight 06/02/204
tests created that guarantee performance of:

Documentation 10 ALL classes contain comments to understand ALL source files contain useful comments to allow understand 80
methods, members and inner working (ie border inner working (and description consistent with code)
case handling of fusion, method of fusing readings) In addition to previous point, contains index.dox cover file 20
which produces description of usage and anticipated output.
Modularity of 15 Appropriate use class declarations, definitions, Methods from ControllerInterface implemented (NO CHANGES
software default values and naming convention allowing for TO INTERFACE) 30
reuse.
Methods from MissionInterface implemented (NO CHANGES
TO INTERFACE) 30
Controller classes has inheritance in ways allowing
use of class in others contexts and expansion
(more Platforms can be added, rearranged).

No dependency on ordering of platforms, no “hard The Controller class could handle another platform (Ackerman
coded” values or assumptions of platform order in or SkidSteer).
mission class. 40
Platform: Audi R8 (Akerman Steering)
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), distance between front/back
wheel L (wheelbase). We assume only geometry plays part and no dynamics (no drifting on track).

L
δ

Figure 2 - The pure pursuit method to control Ackerman steering vehicle. From: Automatic Steering Methods for Autonomous, Jarrod M.
Snider, Feb 2009

The goal at (gx, gy) is the input. Variables related to the goal are ld (distance to goal) and heading difference α.
Relationship between angle of wheels δ and these variables is:

2 𝐿 sin(𝛼)
𝛿 = 𝑡𝑎𝑛−1 ( 𝑙𝑑
)

𝐿
δ governs the steering circle R through relationship tan(𝛿) = 𝑅

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

Property Values
brake 0 to MAX BRAKE TORQUE
throttle 0 to 1.0
steering - MAX STEER ANGLE to + MAX STEER ANGLE
Values to be used:

Property Values
STEERING RATIO 17.3
LOCK TO LOCK_REVS 3.2
MAX STEER ANGLE (M_PI * LOCK_TO_LOCK_REVS / STEERING_RATIO)
TRACK WIDTH 1.638 [m]
WHEELBASE 2.65 [m]
MAX BRAKE TORQUE 8000.0 [Nm]
DEFAULT_THROTTLE 0.1 = vehicle top speed 2.91m/s
Platform: Husky (Skid Steer)

The Husky is a skid steer platform, it turns by creating an opposing gripping force from the wheels (and therefore
needs to be able to skid to turn). It is controlled by supplying a liner velocity (forward x) and angular velocity (around
z axis)

The control of the platform is via 4 control values

Property Values
Turn on spot left / right Left positive (turn around z)

Move forward / backward Forward positive (move in x direction)

The maximum linear velocity is 1.0m/s and maximum angular velocity 1.0 rad/s2. When moving about, we advise to
control the vehicle going forward (and turn into then direction your driving).
Automated testing of code

We will provide a test stub in the test folder of a1_skeleton. The testing will attempt to test the Controller Classes
developed, as well as Mission. These tests will be used for Unit Test marking. To be completed by midnight 06 March
2024.

These ARE NOT THE ONLY tests we will be undertaking on your code, but they provide some indication of how your
code will be thoroughly evaluated. If your tests are succeeding you should get all green in execution of tests.

To compile and run testing students must have google testing framework (you have needed this for quizzes part A).
FAQ

Should I implement this function in Controller or Ackerman and SkidSteer?

Students need to decide whether to implement the function, whether in base class or derived class (whether it is
pure virtual in Controller, or virtual in Controller or fully implemented in SkidSteer/Ackerman). The base class
SHOULD not know anything about the derived classes, though it can store information or have common
functionality that is used in the derived classes.

Can we create additional functions and classes?

Certainly, yes, you can create own functions/classes and this is good practice. This is subject to following

• You cannot add functions to interface classes

• Only the functions in ControllerInterface are accessed by Mission
• Only the functions in MissionInterface are accessed by main (unit tests we have supplied show these two
things and marking criteria is also showing this)
• Additional classes can be added, as long as above constraints are applied (that is you cannot expect
someone using your code to have to create objects of or functions from this class. The class/functions
you add can only be accessed via the derived classes of the interface class. The existing classes and
functions can interact with them. (Check that our supplied unit tests have to pass).

Can I have additional constructors in the Classes supplied

You are REQUIRED to have a default constructor, which takes no values, and this constructor will need to initialise
the class to default values. If you do not have a default constructor none of the unit tests will pass (including
those supplied) and we will not be able to mark execution. You can have additional constructors for you own
code, but ONLY default constructors will be called for unit testing.

Can we assume the platforms (Ackerman or SkidSteer) are always aligned with X axis – have angle of zero when
starting.
No, you cannot assume this, the odometry provides the orientation of the platform with respect to the
world coordinate system.

My code keeps crashing waiting for Odometry

You should only open the PfmsConnector once, there is a special function in a Class that is called only once,
and therefore appropriate for this task.
shared_ptr are also tricky, if they go out of scope and do not allow deleting. You can use:

std::shared_ptr<PfmsConnector> pfmsConnectorPtr(new PfmsConnector ());

OR
PfmsConnector * pfmsConnectorPtr = new PfmsConnector ();

What is the difference between timeInMotion and timeToGoal

timeInMotion is the actual time the car has been moving since it started (ignoring stationary time). timeToGoal is
the estimated to time reach a goal (with the velocity values specified in this Assignment).
The tolerance for timeToGoal values is 0.5s while travel time (timeInMotion) will have a slightly larger tolerance.

If the user only has one platform (Akerman) does selecting objective, make sense
Agree, there is no need to select an objective if only one platform is used. Your mission could ignore the objective
then as it can not split them between platforms.