Real-Time Software Design: Quadcopter Control

ELE3307 Real-Time Systems Semester 2, 2019
Page 1 of 12
Assignment 1
Real-Time Software Design: Quadcopter Control
Date Due : Tuesday 27th August 2019
Marks: 200 (20% of total assessment marks)
Penalty for Late Submission: 5% per day late
Outline
In this assignment, you will design, implement, test and document a C program to control a simple
quadcopter/drone to be used for aerial photography. The assignment does not involve quadcopter
hardware. Instead, the operation of the quadcopter is simulated by a POSIX compliant program
provided as a Cygwin executable which your controller program will interface to. You will need to
understand the basics of quadcopter operation, therefore a brief explanation and links to external
resources are provided in this assignment specification.
The assignment is divided into two parts:
 Part A (140 marks) involves manual control using the keyboard
 Part B (60 marks) involves autonomous control based upon waypoints defined in a file
Both parts must be implemented in the same C program per the requirements in this specification.
You must submit the following two items by the due date:
1) A text readable and non-compressed/non-zipped Word or PDF report documenting your system
design, implementation and testing. The report must include the following concise information:

System design – A state based diagram for Part A (manual) operation
– A state based diagram for Part B (autonomous) operation
– A brief explanation of significant design choices for Part A (manual)
AND Part B (autonomous) (maximum 2 pages)
Testing results – The test cases you executed for Part A (manual) AND Part B
(autonomous) and the associated results
Program listing – The commented C source code in an appendix

2) A zip file of the directory containing your Code::Blocks project and C source/header files. This
must preserve the Code::Blocks project directory structure so that the project can be imported into
Code::Blocks without manual tweaking.
ELE3307 Real-Time Systems Semester 2, 2019
Page 2 of 12
Introduction to Quadcopter Operation
A quadcopter uses four motors/propellers to achieve stable flight, two of which rotate clockwise
(cw) and the other two of which rotate anti-clockwise or counter-clockwise (ccw). The motors are
arranged such that the clockwise motors are diagonally offset from each other, as are the counter
clockwise motors. In spite of this symmetrical layout, a quadcopter has a designated front and
rear. In this assignment, the front left motor rotates clockwise (as seen from above) and this
determines the direction of rotation of the three other motors. These aspects are illustrated in the
following diagram.
The operations of the quadcopter are as follows.
Hover
All four motors rotate at the same angular speed such that the quadcopter hovers at a constant
height. The faster the motors rotate, the higher the altitude. This operation is also the basis of
ascending and descending without moving forward, backward, left or right and without rotating
the quadcopter as a whole. The above diagram depicts the hover operation where all four motors
are operating at the same angular speed (since the rotation arrows being of the same thickness).
Pitch Forward/Backward
To pitch forward, the angular speed of the two rear motors is increased and the angular speed of
the two front motors is decreased such that the quadcopter tilts and moves forward but maintains
the same height. This is illustrated in the following diagram.
ELE3307 Real-Time Systems Semester 2, 2019
Page 3 of 12
To pitch backward, the angular speed of the two front motors is increased and the angular speed
of the two rear motors is decreased such that the quadcopter tilts and moves backward but
maintains the same height.
Roll Left/Right
For a quadcopter, rolling is very similar to pitching, the only difference is that the quadcopter
moves in a different direction.
To roll left, the angular speed of the two right motors is increased and the angular speed of the
two left motors is decreased such that the quadcopter tilts and moves to the left but maintains the
same height. This is illustrated in the following diagram.
To roll right, the angular speed of the two left motors is increased and the angular speed of the
two right motors is decreased such that the quadcopter tilts and moves to the right but maintains
the same height.
Yaw Clockwise/Counter-clockwise
If you imagine looking down at the quadcopter from above, yawing is the operation of rotating the
quadcopter about its centre in a horizontal plane without moving forward, backward, left or right
and while maintaining the same height. You can think of it is as pointing the quadcopter in the
correct direction before a subsequent pitch or roll.
To yaw clockwise, the angular speed of the two clockwise spinning motors is decreased and the
angular speed of the two counter-clockwise spinning motors is increased. This is illustrated in the
following diagram.
ELE3307 Real-Time Systems Semester 2, 2019
Page 4 of 12
To yaw counter-clockwise, the angular speed of the two clockwise spinning motors is increased
and the angular speed of the two counter-clockwise spinning motors is decreased.
The following external resources may be of further assistance:
https://youtu.be/DNc8o9CZLHU
https://www.wired.com/2017/05/the-physics-of-drones/
System Specification
The quadcopter has a simple design as follows:
 A single designated flying height of 50m is supported.
 The front left motor rotates clockwise as seen from above.
 Each of the four motors can be operated at one of four ‘speeds’:
o MOTOR_OFF
o MOTOR_LOW
o MOTOR_MED
o MOTOR_HGH
 The controller only needs to specify the speed of each motor, the direction of rotation of
each motor is fixed and not controllable.
 The quadcopter will ascend to and hover at the flight height of 50m if the controller
specifies each of the four motors to operate at the MOTOR_MED speed simultaneously.
 The operations of pitching, rolling or yawing are only supported at the designated flight
height and can be realised if the controller sets two motors to operate at the
MOTOR_LOW speed and the other two motors to operate at the MOTOR_HGH speed
appropriately.
ELE3307 Real-Time Systems Semester 2, 2019
Page 5 of 12
 The quadcopter will descend to ground if the controller specifies each of the four motors to
operate at MOTOR_OFF. The quadcopter manages the descent by slowly ramping down
the motor speed so damage does not occur (in other words you do not have to worry about
this!).
 Simultaneous pitch, roll and/or yaw is not supported, only one of these operations can
occur at any one time. To travel to a specific location, hover the quadcopter at flight
height, then yaw so the quadcopter points in the direction required, then either pitch or roll
as appropriate.
 The controller is able to request the current Cartesian i.e. (x,y) coordinates of the
quadcopter, as well as the current yaw angle (i.e. angle of the direction of forward travel
relative to the x-axis) and the remaining battery charge.
 The quadcopter starts at (0,0) with a height of 0m and a yaw angle of zero degrees i.e. the
direction of forward travel initially points along the positive x-axis.
 The quadcopter battery is rechargeable and can be recharged by landing the quadcopter
within 0.5 units of (0,0).
 The following parameters are provided (these are not required for manual control, but they
may be needed for autonomous control):
o Flight speed when pitching or rolling is 1 horizontal unit per second (this is fixed
and not controllable)
o Yawing speed is 25 degrees per second (this is fixed and not controllable)
Part A (Manual Control) Design
The application to be designed must correctly control the quadcopter in response to user input from
the keyboard. You are required to design, develop and test a state driven implementation for the
quadcopter control to meet the following requirements:
1. Control the quadcopter based on the following key presses which can be obtained via a
utility function described later:

Key Action Required
‘h’ or ‘H’ Hover (also used to ascend to flying height)
‘d’ or ‘D’ Descend
‘f’ or ‘F’ Forward pitch
‘b’ or ‘B’ Backward pitch
‘l’ or ‘L’ Left roll
‘r’ or ‘R’ Right roll
‘c’ or ‘C’ Clockwise yaw
‘a’ or ‘A’ Anticlockwise/Counterclockwise yaw
‘p’ or ‘P’ Photo request
‘q’ or ‘Q’ Quit simulation

ELE3307 Real-Time Systems Semester 2, 2019
Page 6 of 12
2. Ensure the quadcopter is controlled according to the following restrictions:
 Pitching, rolling and yawing shall only occur at the designated flying height (i.e.
pitching, rolling and yawing related key presses shall otherwise be ignored).
 If the quadcopter is pitching, rolling or yawing, it shall continue to do so until the user
presses ‘h’ or ‘H’ to stop the quadcopter and initiate hovering (i.e. pitching, rolling,
yawing and descending related key presses shall be ignored while the quadcopter is in
motion).
 If the quadcopter is hovering at the designated flying height, pressing ‘p’ or ‘P’ shall
set a 4 second timer to stabilize the quadcopter and allow the camera to focus prior to
the actual photo being taken when the timer expires. Pressing ‘p’ or ‘P’ under any
other circumstance shall have no effect.
 There are no restrictions on valid (x,y) coordinates.
3. Print at least the following information to the terminal window on a regular basis (e.g. 2
times per second), but not so fast that the output is unreadable in real time:
 simulation time
 (x,y) co-ordinates
 height
 yaw angle in degrees
 remaining battery percentage
 current state according to your state machine
All of these variables apart from the last (i.e. the state) are available from utility functions
described later, so the controller does not need to keep track of them separately.
Part B (Autonomous Control) Design
The application to be designed must correctly control the quadcopter to autonomously visit and take
a photo at up to 20 waypoints, the (x,y) co-ordinates of which are contained in a file named
“waypoints.txt”. A file reading utility function (described later) is provided for you to obtain the
waypoints. Sample waypoint files are also provided (note that your program may be tested with
waypoint files other than those provided). You are required to design, develop and test a state
driven implementation for the quadcopter autonomous control to meet the following requirements:
1. The controller shall operate in autonomous control mode if the file “waypoints.txt” is
present in the current working directory, otherwise it shall operate in manual control mode
per the part A requirements. Note: the simulator is agnostic to whether the controller
operates in manual or autonomous control mode.
2. The controller may re-order the list of waypoints to reduce the flying time. Some Part B
marks are awarded for performance, so you may consider this and other optimisations for
the performance marks. In this application, an intuitive approach to optimisation will work
quite well, so you do not necessarily need to perform much research. Print the visiting
order of waypoints (using index 0 for the 1st waypoint in the file, index 1 for the 2nd
waypoint in the file and so on) when the controller first starts.
ELE3307 Real-Time Systems Semester 2, 2019
Page 7 of 12
3. The controller shall ensure the quadcopter visits each waypoint. When visiting a waypoint,
the quadcopter shall hover within 0.5 units of the waypoint, set the 4 second stabilization
timer and then automatically take the photo when the timer expires. Note: there are sources
of error e.g. the values of (x,y) and yaw angle obtained via function calls from the
simulator may be slightly stale due to the way the simulator works, which affects the
accuracy of navigation. However, the 0.5 unit margin is quite generous. From one
waypoint, you should be able to set the yaw angle and pitch/roll to the next waypoint in a
single straight line so as to be within the margin.
4. The quadcopter controller shall not allow the battery to become completely discharged
during the mission; this may mean returning to the origin to recharge part way through the
mission. The battery discharge characteristics are not provided and it cannot be assumed
that battery discharge is a linear function of time since different operations such as yawing
and pitching consume different amounts of energy. Hint: track the total distance travelled
since the last recharge, and with knowledge of the current remaining battery percentage,
you can predict whether it will be possible to visit the next waypoint and return to the
origin for recharge from there.
4. Print at least the following information to the terminal window on a regular basis (e.g. 2
times per second), but not so fast that the output is unreadable in real time:
 simulation time
 (x,y) co-ordinates
 height
 yaw angle in degrees
 remaining battery percentage
 current state according to your state machine
5. In addition, whenever the quadcopter arrives at a waypoint or the origin, print a message to
indicate this, along with the (x,y) co-ordinates of the waypoint/origin, the (x,y) coordinates of the quadcopter and the magnitude of the positional error. Also print the total
number of waypoints that have been visited so far.
Implementation
You are required to implement a single state-based real time control program for Part A (manual
control) and Part B (autonomous control) using the C standard library and C POSIX library to
execute on a Windows compatible PC with a Cygwin environment. Stated-based operation is
required, NOT input based.
You will be provided with the following in addition to this specification:
 ‘DroneSim.exe’, a separate Cygwin executable which you run at the same time as your
control program. This program will simulate the movement of the drone, track its position,
height, yaw angle and remaining battery percentage based upon the commands you give.
 A header file ‘droneControl.h’ containing some macros and declarations.
 A source file ‘droneControlInterface.c’ which provides a set of subroutines that interface
with the drone simulation program and obviate the need for you to understand some of the
ELE3307 Real-Time Systems Semester 2, 2019
Page 8 of 12
finer details of the interface at this point in time. A summary of the function of each
subroutine is provided below.
 A source file ‘droneControl.c’ which provides a template for a solution and makes use of
‘droneControl.h’ and ‘droneControlInterface.c’. Note this template provides the basic
program structure and shows how the software works. The example source code in
‘droneControl.c’ lifts the drone up to its designated flying height and then pitches it forward
to fly into the distance, never to be seen again; it does not respond to user input. You should
modify the source code in ‘droneControl.c’ to create your state machine control to satisfy
the requirements of this specification. You can change the name of the file if you wish.
It is compulsory to use the drone simulator executable provided and the control source/header files
provided. It is possible to code the whole solution only by updating ‘droneControl.c’, although you
may wish to add further source/header files for increased modularity.
Once you have compiled your controller project and wish to test it, the two programs (i.e.
DroneSim.exe and your controller program executable) need to be running at the same time in
separate windows. To facilitate this, first place the two executables in the same directory (they
must be in the same directory to share memory correctly when running), and then double click on
each to run it in its own command window. The order you start the two executables should not be
important. However, only the simulator window will accept keyboard input, so you must
ultimately select it as the active window.
VERY IMPORTANT – DO NOT click on any other windows while the simulator is running.
Keep the focus on the simulator window, otherwise keyboard input will not be accepted! You
should see text output in the first screen coming from the controller and text output from the
simulator in the second window.
Functions of subroutines contained in droneControlInterface.c
The first two subroutines control the connection to the drone simulator program.
void droneOpen(void);
Call this routine once at the top of your program to initialize the link to the drone simulator
program and reset the drone to its initial state: (x,y) = (0,0), height = 0.0 m, yaw angle =
0.0 radians, battery percentage = 100%, all four motors set to MOTOR_OFF.
void droneClose(void);
Call this routine once at the end of your program to close the link to the drone simulator
program.
The next subroutine sets the drone motors and is the interface to hover, descend, pitch, roll and
yaw operations.
int setDroneMotors(int motor_fl_cw, int motor_fr_ccw, int motor_bl_ccw, int
motor_br_cw);
Call this routine with MOTOR_OFF (0), MOTOR_LOW (1), MOTOR_MED (2), or
MOTOR_HGH (3) as an argument to set the speed of each of the front left, front right,
back left and back right motors respectively. Each motor can be set to a different motor
ELE3307 Real-Time Systems Semester 2, 2019
Page 9 of 12
speed, but the simulator only accepts certain combinations. The direction of rotation
(clockwise or counter-clockwise) is not explicitly specified by the caller, it is implicit, so
all values must be positive.
The function will return one of the following:
SET_MOTORS_SUCCESS (0)
SET_MOTORS_NOT_AT_FLIGHT_HEIGHT (-1): for pitching, rolling or yawing when
below flight height
SET_MOTORS_ILLEGAL_MOTOR_CONFIG (-2): illegal motor configuration for this
drone
The next few subroutines get information from the drone simulator.
double getSimTime(void);
Call this routine to get a double representing the current time from the simulator in
seconds since the simulation began; note this does not necessarily reflect real time.
double getX(void);
Call this routine to get a double representing the current x coordinate of the drone position.
double getY(void);
Call this routine to get a double representing the current y coordinate of the drone position.
double getHeight(void);
Call this routine to get a double representing the current height of the drone in metres.
double getYawAngleRadians(void);
Call this routine to get a double representing the current yaw angle in radians of the drone.
double getBatteryPercentage(void);
Call this routine to get a double representing the current remaining battery percentage of
the drone.
int getStatusFromDroneSimulation(void);
Call this routine to get the current status that the simulator is reporting.
The function will return one of the following:
STATUS_OK (0) – no exceptional conditions
STATUS_NOT_AT_FLIGHT_HEIGHT (1) – last requested drone operation is not
allowed at current height
STATUS_ILLEGAL_MOTOR_CONFIG (2) – last requested drone operation is illegal
STATUS_BATTERY_FULLY_DISCHARGED (3) – battery discharged and drone is dead
char getKey(void);
Call this routine to get the most recent key press by the user which has not already been
handled, (the function then resets the key to NO_KEY to prevent handling the same key
press more than once)
ELE3307 Real-Time Systems Semester 2, 2019
Page 10 of 12
The function returns the most recent key press by the user which has not already been
handled as a char, otherwise NO_KEY (0).
int isDroneSimulationQuitFlagOn(void);
Call this routine to determine whether the simulator is quitting after receiving a ‘q’ key
press.
The function will return one of the following:
OFF (0) – quit flag off
ON (1) – quit flag on
The next subroutine causes the drone to take a photo.
void takePhoto();
Call this routine to ask the simulator to take a photo.
The next subroutine causes the control program to sleep.
void sleepMilliseconds(long ms);
Call this routine to put the calling thread to sleep for a certain number of ms specified in
the argument.
The next subroutine determines whether a waypoints file is present for autonomous control mode
and if so reads the waypoints from it.
int getWaypoints(double *waypointXArray, double *waypointYArray, int
*numberOfWaypoints);
Call this routine to get the waypoints from the waypoints file “waypoints.txt” if it exists in
the current working directory, and populate waypoint X and Y coordinate arrays and a
number of waypoints variable which are passed as pointer arguments to the function.
The function will return one of the following:
WAYPOINTS_FILE_PRESENT_AND_READ (0)
WAYPOINTS_FILE_NOT_PRESENT (-1)
Important note:
Programs submitted must be the work of each individual student. Exchange of ideas on conceptual
issues between students is expected, but students must write their own programs and not share
code.
ELE3307 Real-Time Systems Semester 2, 2019
Page 11 of 12
Assessment 1 Rubric:
The rubric is presented on the following page. In addition to the rubric, there are also penalties for
not complying with this specification in certain areas as follows. These are at the discretion of the
examiner.

Issue Penalty
The packaging of submitted files does not
meet the specified requirements (see page 1)
Up to 30 marks
When compiling the source files, there are
unresolved compiler warnings (e.g. variables
being used uninitialized) which can cause the
program to fail to work correctly on one
machine while working correctly on another.
Up to 30 marks
The provided source files (and in particular the
interface subroutines defined in
droneControlInterface.c) have not been used
Up to 50 marks

ELE3307 Real-Time Systems Semester 2, 2019
Page 12 of 12
ELE3307 Assignment 1 marking criteria
Each attribute below relates to a key element of the assignment, marked on a scale of 0 to 100%. Zero marks will be awarded for no attempt.

Attribute Novice Apprentice Practitioner Master Mark
Part A
functionality
The program completely fails to
respond to user input as specified
(including the cases of compile
time or runtime errors)
The program correctly responds to
some user inputs per the
specification
The program correctly responds to
most user inputs per the
specification
The program correctly responds to
all user inputs per the
specification
/ 50
State Diagram(s) Most details are incorrect or do not
represent actual program operation
Fairly well drawn state diagram,
could have been abstracted better,
some details (e.g. states,
transitions, labels) are incorrect or
missing
Well drawn state diagram, a small
number of details (e.g. states,
transitions, labels) are incorrect or
missing
Complete and correct state
diagrams, completely matches
actual program operation
/ 40
Other
Documentation
(e.g. test
plan/results)
Documentation is poorly written or
does not explain
design/implementation/testing
Documentation is limited or
explanation of
design/implementation/testing is
incomplete
Documentation is adequately
written and explains
design/implementation/testing.
Documentation is well written and
explains
design/implementation/testing
clearly.
/ 20
Program
Modularity
The program makes limited use of
interface routines and modularity.
The program makes some use of
interface routines and modularity.
The program makes adequate use
of interface routines and
modularity.
The program makes good use of
interface routines and modularity.
/ 10
Program
Implementation
The program is implemented with
limited use of accepted
programming
techniques/comments.
The program is implemented with
some use of accepted
programming
techniques/comments.
The program is implemented with
adequate use of accepted
programming
techniques/comments.
The program is implemented with
good use of accepted
programming
techniques/comments.
/ 20
Marker’s CommentsTOTAL MARK / 200
Part B
functionality
The drone always fails to complete
its mission successfully with non
trivial waypoint files
The drone sometimes fails to
complete its mission successfully,
possibly as a result of failing to
recharge in time
The drone usually succeeds in
completing its mission
successfully, but there are some
subtle bugs
The drone always succeeds in
completing its mission
successfully
/ 30
Part B
performance
(includes time to
calculate routes
as well as flying
time)
There is little or no optimisation to
reduce the mission time, or the
optimisation is incorrect
There is limited optimisation to
reduce the mission time, or the
optimisation is waypoint file
specific
The optimisation to reduce the
mission time performs well and is
comparable to the sample solution
Excellent level of optimisation,
superior to the sample solution for
most waypoint files
/ 30