In part 2 of this blog, I take closer look at the communication protocol, range guard and state machine of the autopilot. As with part 1, this blog post is for those who think developing drone software is interesting and would like to know some of the thoughts that have gone into making this particular system.
Some may ask why one would go through the trouble of taking the autopilot off the airframe, when it’s been sitting there happily for so long. The simple is answer is, interconnecting is more fun!
A long time ago, we had personal computers but no internet to share data through. Data had to be transported on floppy disks and magnetic tape. Facebook, twitter, Online multiplayer gaming, email and a zillion other things were not practical without the connecting abilities of the internet.
In the old days, the first power plants were only serving a few local businesses with no way to handle sudden break downs etc. Today we have connected state and even countries through our power lines to be able to sell electricity or cope with breakdowns on the grid.
In short - we tend to want to connect solitary systems, to make them more usable.
Thats why I find this project fun. By making the autopilot a central entity, that is connected to multiple drones, the possibilities of what these drones can achieve together are endless. See it as a low-cost, hobby experiment - exploring what such systems could do for us in the future or as an alternate to the APM type of autopilot.
Another advantage is the possibility of running the autopilot of a laptop, where modifications are easy to do during flight tests and no expensive hardware is damaged, should the craft to self destruct.
Finally, this system is versatile in the way that it connects to its surroundings, so if you’d like to have the autopilot stay in the airframe, it simply stays there and connects through the serial port…
The system relies heavily on constant communication with the drone. The drone sends a lot of telemetry metric back to the autopilot, which the autopilot in turn interprets and react to, sending back correctional data to make the drone achieve it’s mission. Stability is handled locally on the drone by a modified multiwii and it is therefor only correctional data such as throttle, pitch and roll that is sent back to the drone.
As we want to be able to control as many drones as possible, with only one radio link, the communication protocol has to be as efficient as possible, meaning, don’t include data that is not needed and send it as compact as possible.
I’ve not optimised this to the fullest but sending data to the drone only takes up 8 bytes - these are:
[Start data byte] [Drone id byte] [ROLL] [PITCH] [THROTTLE] [YAW] [Checksum] [Data done byte]
Start data byte simply indicates that a transmission of data is about to begin.
Drone id byte indicates which drone this data is intended for.
Roll, Pitch, Throttle and yaw are the native values that multiwii uses normally as input from an RC Radio and is normally a number ranging from 1000 to 2000 (PWM Cycles). A byte can only describe the range from 0 to 255 or -128 to 127. The values are therefor divided by 10 before sending, and multiplied by 10 upon reception. We loose a little precision only being able to send values in the increment of 10, but thats acceptable.
Checksum is a control byte that is calculated from the previous data - as this checksum has to be computed fast on the receiving embedded system, I choose to use a simple xor checksum. This will still be a pretty good error prevention mechanism, and should faulty values come through, the autopilot will correct them on upon the next telemetry update.
Data done byte signals the end of the data packet.
Should the checksum or number of bytes between start byte and end byte be wrong, the transmission is discarded.
As with the usav (android based autopilot), the system features a range guard system, that acts independently of all other systems. If the drone gets higher or further away than whats allowed, it can either land the craft or turn it around regardless of what the craft is doing. Internally this is handled by the state machine, that ensures that the proper transitions are made from what ever state the craft was in when the range guard was activated.
The State machine
The state machine control the basic actions of the system, and makes sure that things happen in the correct order. While testing auto takeoff and landing, the state machine is configured to simply go through the preflight check, wait for the auto takeoff command, execute the auto takeoff and immediately issue the auto land manoeuvre once auto takeoff has been carried out.
In blocks, the configuration looks like this, where non transparent arrows shows automatic transitions and transparent represents user determined state changes.
A state consists of a number of things.
Condition dependencies - A state is not allowed until some conditions are fulfilled. ie. preflight state is not allowed until we have solid telemetry (gps fix etc..)
Allowed pre-states. A state can only occur if the previous state is on the list of allowed states. This makes sure that you cannot land before you’ve actually taken off. Or that you cannot go into preflight whilst in the air.
State precode - Any code that will prepare the system/craft for the coming state.
State main code - The code that is to be executed once the state is effective.
State post code - Any code that should be executed when leaving the state
Auto advance to next state - Indicates if the state should automatically advance to another state once the state main code has finished.
Below is a block example of the preflight state.
The state machine is easily configurable which means that it will grow to something like this, once more testing has been done. The state machine will most likely contain a free flight state, where the user is able to control the craft directly using an app.
As you see, the range guard system is fully independent state, which will be triggered if the craft get too far away, and will disable any current activity and switch to auto land.
The system relies on predefined maneuvers. The maneuvers can either be very simple (turn right) or pull on telemetry data, include logic etc, as is the case with the auto takeoff maneuver. I'll show some examples.
Also, some graphs and logs from flite testing.