This article is part four in a series, describing some of the inner workings of an autopilot system - even though the description is specific for this particular system, a lot of principles are generic and can be used to describe a variety of auto pilot systems.
Today we take a look at the overall system and some initial flight testing.
Current system overview
To give you a better insight into the inner workings of the autopilot, I’ll throw in a little blog diagram of some of the building blocks of this autopilot system.
More blocks are bound to be added as I expand the system.
Coms - Handles all internal communication between modules as well as external communication ie. user input.
Logging and speech (talkback is a nice way to get crucial info without looking at a screen) is also handled by coms.
Telemetry - Handles input from sensors, gps, user input etc. It also handles communication back to the craft (guidance commands etc.)
Watchdog - monitors the whole system and warns if any anomalies occur during flight.
Rangeguard - makes sure that the drone does not get too far or too high during the flight.
State machine - handles the overall logic of the autopilot
Vessel - The craft type specific part (copter, fixed wing etc.) and the library of maneuvers that the craft is able to perform.
User input is currently handled by an external auto sequencer (XAS), which is programmed to do a series of commands at specific times. The XAS waits for the state machine to perform a preflight check, and when everything is ready, the XAS issues an auto-takeoff command. Further down the development line, app and chat integrations will be made to control the autopilot.
Flight testing
So it’s time to take the system for a spin in a closed loop test, were the autopilot actually gets to control the drone and not just tell a human how it would like the drone to fly. The idea is to do some simple stuff that exercise most of the system.
Especially the state machine, the sensor/telemetry system and maneuver systems are of interest to the first test, so I decided to configure the statemachine for a simple 1 waypoint maneuver, where the drone take off automatically, navigates to the one waypoint and does and autoland afterwards.
Auto takeoff utilizes the gyro/accelerometer to sense when the flying wing is thrown, and will upon this, start the engine and begin to climb to approx. 10 meters altitude, after which it finishes the auto takeoff maneuver.
Waypoint navigation uses the GPS and magnetometer to determine heading and distance to the waypoint.
Auto land uses the altimeter and gyros to determine when to cut off the engine and when the craft is actually down.
Approximately 30 parameters are recorded and logged for offline evaluation (height, gyro/accel output etc.). All this data is analysed through charts etc., to determine the how's and why's of each test.
Safety
Because we now start to fly the system in a closed loop, where the autopilot actually gets to control engine and servos, we need a safety arrangement that makes sure that we can resume control if something goes fishy. The IMU residing on the drone has therefore been programmed to stop listening for autopilot commands if it receives a hard right input from a normal RC transmitter. Once it has received a hard right, it will no longer process any information from the autopilot and the drone (fixed wing) will be flying 100% by the input of the RC transmitter and will thus act like a normal RC controlled airplane.
Furthermore, a automated checkout procedure built into the state machine makes sure to measure radio connection quality, sensor flux, gps lock etc, before allowing the plane to leave the ground.
Lastly, the autopilot features speech of important parameters, warnings etc,. which is a great help, since you don't have to look at a screen while the plane is in the air.
Results
As mentioned, the main objectives are to exercise and analyse the backbone systems, such as the state machine, telemetry system and maneuvers that subscribe to data from sensors and use them during their operation.
Auto take off worked quite good, each throw was correctly detected and a suitable delay before turning the motor on was present, to allow the throwing hand to get out of the way. Once the height of 10 meters were achieved, the state machine switched to waypoint navigation. I noticed that the plane took some shallow turns, while climbing which suggests that a heading hold functionality would probably be a good thing. This could be implemented by detecting the heading of the launching throw, and then try to keep the plane on that path during the climb.
Auto land was dead simple, worked simply by setting throttle low, wait until being 2 meters above ground and then turn the engine off altogether. This seemed to work perfectly, although a heading hold would probably be beneficial here to.
The interesting part was the waypoint navigation. I thought it fun to try to do a very simple algorithm to determine if the plane should turn left, right or head straight to reach the waypoint. I kind of new from the start that it probably required a PID loop, but I wanted to see what would happen if I used a simple "if I'm left of the waypoint turn right with a fixed value" kind of logic.
The chart below shows the almost endless circles the plane took to finally reach the waypoint. It seemed like a lot of overshooting took place and the plane generally flew eagle style, with a lot of huge turns, slowly getting nearer the waypoint - The journey took 32 seconds - not good :-)
The above graphic just shows why PID control was invented. In short, a PID controller regulates a system to achieve an optimum counting in past deviations, current deviation and future predicted deviations. So instead of the simple compare based logic, the waypoint navigation was "upgraded" with a PID loop that took the current heading and desired heading as input and outputted a correction to the roll of the plane. After some tuning while running some previously recorded flight data, it was time to repeat the test with PID control. The chart below shows how the plane (once the autopilot went into navigation mode) makes a steep turn and heads quite straight for the waypoint (the wind was quite strong at the time). The journey this time took roughly 5 seconds.
The test was repeated several times with the same result, so hurray for PID control! Most autopilots use PID to control height, roll etc., so I'm not breaking new ground here, but the two images nicely shows the effect of an efficient PID controller.
Next steps
It's certainly doable to separate the autopilot from the actual aircraft (which made developing and onsite tweaking so much easier) and basic autopilot features have been achieved. There are a lot of practical limitations in the separation, but also solutions to most. A lot have been learned from the small plane (designated UTV-3 - Universal Test Vehicle) and as the flying season is winding down it's time to start building a new and larger version which will facilitate a host of sensors and allow further testing of ie: the ALF system as well as letting one drone control other drones in a coordinated effort. The next plane will be based on the Phantom FX61 airframe which is a bigger brother of the UTV-3.
Comments