Blogs

Project Andromeda - Communication Protocols

Posted by Nima K on March 23, 2010 at 4:45am


I've been busy writing the communication protocols between the Ground Station and Autopilot. I thought some people might be interested and possibly make use of the approach I've taken. It's all done in binary with discrete packets and makes use of DMA and Interrupts to use as little processor time as possible.


Asynchronous operation is achieved by the use of two FIFO queues and double buffered DMA channels for each radio. There is a lot of detail that will make the diagram above make a bit more sense.


Full article at: http://www.projectandromeda.com.au/blog

E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • lionel March 25, 2010 at 11:44am
    Well, CCSDS and PUS are open too. They are very reliable, scalable and can cope with data loss (quite useful when flocks of bird fly over ground station antennas when dumping/uploading data). In addition they have been tested for years by the space agencies. But I do understand that for your current application they are quite an overhead.
  • Sarel P. Wagner March 25, 2010 at 3:13am
    I think that is way to complicated with much of an overhead. UAVTalk is open, all done, tested and working. Our ground station can have a much wider application if we go with UAVTalk.

    See:

  • lionel March 24, 2010 at 5:36am
    Why don't you use the CCSDS standards ( http://public.ccsds.org/publications/default.aspx ) or the ESA's PUS ( http://adsabs.harvard.edu/abs/1994RBrCM..16..311K )?
  • Nima K March 23, 2010 at 9:50pm
    The RFM radios are good in that they will CRC check packets and therefore only send data if it is valid. For each packet sent, the radio produces and reply packet to indicate whether an ACK was received from the remote radio. This packet is received in the framework and indicates whether or not the command was sent.

    When a reply is received, only commands that have been successfully sent are screened to determine a match. Once a match is obtained, all the packets that were sent before it are flagged as timed out.

    The system also does not continuously try to send a command. It will send it only once. The internal retry count of the RFM radio may or may not attempt to re-send the packet but as far as the queue is concerned, once the packet is given to the radio, it can be considered to be "sending". Once the ACK is received, the packet is marked "sent" and depending on the type, may have a reply associated with it.

    As long as the system continues sending commands at all, the most recent command that makes it through the RF link will be detected and executed by the Autopilot.
  • Sarel P. Wagner March 23, 2010 at 2:00pm
    Please have a look at this for consideration: UAVTalk
    From the link "UAVTalk is a completely open binary protocol designed specifically for communication with UAVs and is licensed under the Creative Commons BY-SA license so it can be implemented in commercial as well as Free software.

    The UAVTalk Protocol uses the concept of telemetry objects, this object orientation makes the protocol extremely flexible and scalable. The object based design also allows the protocol to be optimised for low speed telemetry channels but conversely can also be configured for rapid update times and large object payloads for high bandwidth links. "

    Rgrds
  • David Ankers March 23, 2010 at 9:14am
    I'll send you a PM but basically you want to talk to Dr. Erhard Siegl as he has vast experience of this field and is extremely good at communications protocols.
  • Developer
    John Arne Birkeland March 23, 2010 at 7:53am
    My first thought also. Depending on the equipment used for the wireless serial communication there may or may not be delivery guarantee of the data. Maybe some kind of -check and retry- system should be implemented?
  • bGatti March 23, 2010 at 5:52am
    My first thought is how nicely does the system degrade as communications become iffy.

    For example, does the que get delayed, and then when com is restored a bunch of old commands are performed?
    Generally some commands are more important than others, some are time sensitive (move a control) etc,... so I might expect to see a command prioritize?
This reply was deleted.