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 protocol
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.
RangeGuard
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.
Next time
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.
Comments
Hi Dan - The stabilisation system (in my case the MultiWii) still resides on the airframe, so even without input from the AP, the craft stays balanced in the air. Also, the MultiWii handles los of signal etc., and makes sure to land the craft or return it to it's starting position)
You have a good point about AP's becoming more advanced. Typical AP's are made on arduino type embedded systems, and these often lack the memory and storage capacity to do heavy analysing, image stitching etc... Their strength is their simple real time operation mode.
I think that something like the UDOO is cool, cause it has both. Arduino for fast stabilisation and close-to-the-steel control of motors, servos etc., and a linux type of computer that can do the more sophisticated analyzation stuff. My combo is somewhat the same (just not on the same circuit board).
Mathew - The system for now runs on its own private "network" (using xrf radios), even though they have a very limited bandwith, even compared to cell-phone networks, this still works very reliable and fast.
In my previous project, I used the gprs capabilities of normal cell-phone networks to communicate, which also worked great. I guess it depends on what your goals are.
yeah I'm going to agree with Dan here a decentralized AP while a neat concept is a bad idea in the real world. networks will never bandwidth nor reliability to handle this kind of up and down throughput needed to pull this off. it better to have each drone have their own self contended AP and have they talk to each other.
I think it's really cool that you're doing this, and I'm sure there are some applications for it with which I am not familiar, but I would personally be extremely weary of having a decentralized AP, especially for a multirotor where it is needed to stay in the air.
What with embedded hardware becoming so cheap and powerful, I would think that the shift will be in the opposite direction, as the AP itself starts doing more than navigation - things like inbuilt computer vision, SLAM, etc.