CatsEyesAP: Autonomous Flight Vehicle blog

AF Vehicle blog — August 27, 2009

To describe this concept as a LAN or "network" is perhaps to give it the wrong impression. It would probably more properly be called a "serial bus." I have been researching some of the existing bus specifications out there to see if anything would be appropriate. The most obvious one is the I²C bus.

The I²C bus

The I²C bus sounds on the surface like it might be ideal for my purposes. It consists of just two wires (not including ground and power). I was hoping to get away with just one, but two is not onerous. There is a lot of flexibility in terms of timing and, for instance, a node that is receiving data too fast for it to process can tell the transmitter to wait until it catches up. Since I am not planning on dedicated hardware, this might be useful.

However, upon further investigation I think it may not be exactly what I want. It is really designed for point-to-point communication, where there is a specific transmitter sending data over the bus to a specific receiver. I was envisaging more of a "broadcast" type of scenario, where a node would identify itself and the data it was sending, but not specify a receiver. Any other node on the network (which might be multiple nodes) could use the data.

The I²C bus seems to be geared to a more standard computer system architecture, where there is a central, relatively powerful CPU communicating with several peripherals. The communication is initiated and mediated by the CPU, whereas the peripherals just respond slavishly. This is really not in keeping with the modular approach I am envisaging.

Finally, it looks like the programming required might be somewhat complex to implement the I²C bus specification, or even a subset of it (for instance I would not need the "multi-master" mode). I am not afraid of a little programming, but code space is limited in some of the controllers I have in mind.

Therefore I have concluded that the I²C bus is not going to meet my needs. Researching it has been useful, however, in that it has given me more focus on the bus I actually will be designing. I may also want to implement a short I²C bus segment to interface between my bus and an EEPROM device to store flight parameters (the "black box").

Current bus concept

The concept as I now have in mind would work as follows.

There would be a single "master" module that would take care of timing on the bus. It would "poll" the other nodes to see if they had any data to transmit. The other nodes would not transmit their data until polled and this would thus avoid collisions. Polling would be done one-by-one for each of the nodes on the bus. If a node's address was polled and the node didn't respond within a certain time, it would be assumed to be busy or have no data to transmit and the master module would move on to the next.

A complete polling cycle (all nodes polled) will probably end up being 20mS, the same as the receiver's frame rate. This would make sense as the receiver module will be "busy" timing the receiver pulses for much of the time, but after all the pulses have been measured it would be available to transmit its data to the bus. The other modules can I believe be designed to wait for their turn to transmit, or can easily skip several frames if busy doing other things. For the servo and ESC modules, which are going to output a standard servo signal, the 20 mS cycle makes it very easy to program these modules (probably at least two and possibly three "modules" could probably be combined on one controller).

I imagine the receiver and master modules would be separate controllers, and separate nodes on the bus, but might be linked by an extra wire to syncrhonize timing. That is, the receiver module would send a signal to the master module (not over the bus) saying, in effect, I have data now, please start the next frame." I might also futz with the roles a bit, so that the receiver module would act like the master module for a short period of time and start the polling sequence, in effect polling itself, then transmit its data as per any other module. The master module would then take over the polling for the rest of the nodes. I don't think it would be possible to combine them in one controller, since the master module has to do the polling at the same time as the receiver module is timing the receiver pulses for the next frame.

The basic R/C aircraft configuration (before the introduction of any autonomous flight capability) would consist of the R/C receiver, the servo and ESC modules. Once this is complete and functional, I can start working on the other modules. The next one to be introduced would probably be the altitude module. I envisage the altitude module will work like this. In the full autonomous flight mode, it will receive instructions on what altitude to fly the plane to from the navigation module. However, at first we can just test the module's ability to fly the plane to a certain pre-defined altitude.

The altitude hold module would listen to the receiver module's output on the bus. One of those channels will be a toggle tied to a switch on the pilot's transmitter. When the pilot triggers this switch, it puts the plane in autonomous flight mode (or during the testing I am describing, in "altitude hold" mode). When the altitude module sees that the pilot has switch to altitude hold mode, it begins sending commands to the ESC module to tell the motor to speed up or slow down to put the plane at the correct altitude. The ESC module initially listens to the receiver module's channel 3 signal (the standard throttle channel) to decide what to do, but it also listens for the altitude hold module. If it finds commands from the altitude hold module, these commands override those from the receiver module and it responds to those commands instead. (It might also listen to the trigger channel from the receiver as well, to make sure the pilot indeed triggered altitude hold, as a precausionary measure.)

This of course puts a specific requirement on many modules to monitor a specific channel from the receiver and compare it with a specific value to determine if the plane has been toggled into autonomous mode. This is probably not a good idea as it would require re-programming many of the modules if this mapping ever changes. A better solution is probably to put this logic in the receiver module, which would then transmit a mode byte that would have a specific unchangable meaning. If the toggle mechanism ever changes, then it is only the receiver module that needs to be re-programmed.

At the moment I am thinking of just two modes, "R/C mode" and "autonomous mode," but this would allow other modes to be introduced. For instance, there might be a "return to home" mode that could be triggered under certain conditions that would cause the plane to immediately try to return to the location it took off from.

Way forward

The first step will be to develop a tentative bus protocol and try to implement a simple data transfer between a couple of controllers. Actually trying to program and test the protocol will I think give me a good idea of what will work and what won't, whether it will be too code-space intensive, whether it will be too slow, etc.

I also will have to take a look at the actual R/C receiver I am going to use, an XPS 2.4 GHz spread spectrum receiver. There is no necessity, for instance, that the channels be serialized (i.e. the pulse on channel 2 occuring right after the pulse on channel 1) the way they are for a 72 MHz receiver. I am hoping they are (it's probably easier to design it that way), but there is no guarantee. In worst-case, if all the pulses occur at once and overlap, I'll probably need one controller per channel! If they are serialized, I should only need one controller for all the channels.