While studying and working a Labman, I designed, built and developed a Quad Rotor including the frame, electronics and flight control software as I thought it would be an interesting challenge and learning exercise. The software is written in C++ and runs on an on-board micro-controller called an mBed. I used the Quad Rotor in my University dissertation, developing semi-autonomous features such as an altitude controlled mode that enables the Quad Rotor to maintain an altitude, follow the contours of the ground and land automatically if the Quad Rotor loses connection with the operator remote.
I also developed an accompanying Base Station application to receive wireless telemetry data and control the Quad Rotor. This is written in C# using the WPF charting toolkit to display real time data.
The various parts of this project are covered in more detail below.
The Flight Controller electronics consist of a single circuit board containing all the necessary components and peripheral connections to input/output devices. The inputs to the electronics are shown in green, the Flight Controller software, running on an mBed, is shown in red and the outputs are shown in blue. Whilst designing the electronics prototypes a few points were considered. The most important consideration was sensor accuracy as the Quad Rotor is not able to maintain stability unless the attitude and altitude data are reliable. Another consideration was to ensure that all the components could be powered by the 5V DC supply from the battery and that the micro-processor chosen was sufficiently powerful to run the flight control algorithms at 500Hz.
The Flight Controller software runs on an mBed micro-processor contained in the Flight Controller electronics. It takes inputs from the sensors, remote control and Base Station application and uses this data to control the speed of the 4 propellers independently. This enables the Flight Controller to control the Quad Rotor and maintain stability during flight.
The Flight Controller consists of a main class and seven more encapsulated classes which handle the various tasks necessary to maintain stable flight. To enable the classes to communicate with each other dependency injection was used (shown with a dashed line). This is where each dependency class is instantiated before the dependant class and the dependency classes are passed by reference to the dependant class constructor. The dependency classes are passed by reference to ensure that the same object is used by all the dependant classes.
The Flight Controller implements a finite global state machine which makes sure that all the other components of the Flight Controller can only run valid actions in the current context of the system. For example the state machine would not allow the motors to spin until the Flight Controller has been initialised, the remote control has been connected and the armed flag has been set to true.
The state machine contains 6 mutually exclusive states. Green denotes on the ground, orange denotes on the ground but armed, blue denotes flying and red denotes error.
- Pre Flight: the Flight Controller starts up and immediately enters the pre flight state. Initialisation and sensor calibration is only possible in this state.
- Standby: in this state the Flight Controller has been initialised and the remote control connected.
- Ground Ready: in this state the Flight Controller has been armed and is ready for flight.
- Manual: in this state the Flight Controller is flying in manual mode.
- Stabilised: in this state the Flight Controller is flying in altitude hold mode.
- Error: in this state an error has occurred. The motors are disabled for safety
To get an accurate estimate of altitude, sensor fusion is used to combine the data from individual sensors such that the resulting data is more dependable than would be possible when these sensors were used individually. Information about each sensor such as its measurement history, specification and current measurement is used to decide how much the data it provides can be trusted. The sensors are divided into two categories, main data sensors and reference data sensors. Main data sensors provide absolute measurements which can be trusted. The Lidar distance sensor would fall under this category. Reference data sensors are used to evaluate the reliability of the main data sensors but they cannot be accurate on their own. The integrated velocity data from the accelerometer would fall under this category. This ensures that any error or deviation in one sensor’s readings can be corrected by another sensor’s readings
It was found that using the Lidar distance sensor on its own was not sufficient to estimate altitude because there is a 100ms delay between the altitude changing and the sensor updating. This caused substantial oscillation when holding altitude. The sensor fusion strategy uses a Kalman filter to combine the accelerometer data which reacts quickly but is not accurate and Lidar distance sensor readings which react slowly but are accurate, into one altitude estimate. This is done by using the accelerometer velocity to predict the altitude change and the Lidar distance sensor readings to provide an estimate. The Kalman filter was tuned to react quickly to the accelerometer readings and to trust the Lidar distance sensor readings more over a longer period of time. This resulted in an altitude estimate that reacted quickly to changes in altitude based on the accelerometer readings but was accurate over time due to the Lidar distance sensor readings. Finally the altitude estimate is used to calculate an estimate of velocity. This stops the accelerometer velocity integration errors from accumulating over time.
This chart demonstrates altitude mode in use and clearly shows the Quad Rotor altitude (light blue) oscillating around the target altitude (dark blue). The throttle (green) can be seen varying as the Flight Controller tries to maintain a constant altitude. This proves that the altitude mode strategy works fairly successfully although it would be improved if the oscillation was reduced. This could be achieved by improving the PID controller tuning and improving the altitude estimation to react more quickly to changes in altitude. The large peaks in altitude at the start of a new target altitude are due to the inertia of the Quad Rotor when it is changing altitude and this takes a little while to get under control. This could be reduced by including a model of inertia within the altitude mode algorithm to account for this.
Future work
This project can be extended in many different ways by upgrading the hardware or developing new Flight Controller or Base Station application features. The easiest hardware upgrade would be to integrate a GPS sensor to provide another altitude measurement. This would improve the altitude estimation accuracy and precision resulting in an improved altitude mode.
The altitude estimation could also be improved by developing an Extended Kalman filter to use in place of the Kalman filter. This is because an Extended Kalman filter is designed to work on a non-linear system whereas the Kalman filter is designed to work on a linear system. The Quad Rotor is this project is a non-linear system.
The autonomous features of the Flight Controller could be improved by implementing a position mode that uses a GPS sensor and Kalman filter to provide position. The position would be used along with commands from the Base Station application to enable the Quad Rotor to maintain a position and navigate between way points.
The complete project report can be read at http://joseph-roberts.co.uk/fyp.pdf