Communication protocol

Here is the place for all your dsPic or autopilot questions.

Moderator: lukasz

Communication protocol

Postby Tom » Sun Dec 06, 2009 10:30 pm

A well chosen software architecture should make the first "communication protocol" not that important. It can easily be modified afterwards. However! These things don't change often once there is a working solution that several people use. So we better get it right from the first time :-)

So I would like to know: Do you prefer a binairy communication protocal (fast and little overhead!) or a human readable CSV- or NMEA-like protocol (easy to read and debug)?
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Communication protocol

Postby Laurent » Mon Dec 07, 2009 8:50 pm

What about a compromise 'a la belge' with some Base64 encoding/decoding ?

I'm saying this because this is how mikrokopter implement his protocol. Not that i'm a big fan of it, but it have some advantages (and i still need some compatibility with mikrokopter for now) :
- Still "readable" (with good eyes) and 'writable' (at least copy/paste-able)
- Not much lengthening compared to raw binary (3 bytes -> 4 base64 character; hexa gives 1 bytes -> 2 characters & dec gives 1 bytes -> 3 characters)
- No problem with that '0x00 value' which is considered as 'end of string' in some languages and can get bothering sometimes.
- quite easy to implement (no need for huge scanf)

currently my protocol is based on this scheme, derived from mikrokopter :
#nc[data][crc]cr
# is start of frame
n is adress of target (1 ascii char)
c is command (1 ascii char)
data is optional parameters or return values
crc is a 2 char crc
(cr) is carriage return

This is just an idea, i have no real preferences, as long as it is efficient.
Laurent
 
Posts: 5
Joined: Fri Nov 27, 2009 5:23 pm

Re: Communication protocol

Postby catur4widhi » Tue Oct 26, 2010 1:07 am

because we are limited by hardware bandwidth (serial 115Kbps) and we need speed and precision of data transfer, its better idea to use binary protocol...
catur4widhi
 
Posts: 4
Joined: Sun Oct 24, 2010 8:33 am

Re: Communication protocol

Postby Chris » Tue Oct 26, 2010 4:56 pm

I agree that binary is better because the data rate is so limited. Maybe if there was a simple little app to display or write a file with the data converted to a readable format, it wouldn't be an issue that the actual communication is in binary. It could be a really small, simple little program that you could easily download. Not necessarily the gluonpilot configuration tool, just a generic program to convert the binary to readable text.
Chris
 
Posts: 19
Joined: Sat Dec 12, 2009 4:49 pm

Re: Communication protocol

Postby Mitch » Tue Oct 26, 2010 8:39 pm

I know we could spend a lot of time arguing the best protocol. Obviously binary is going to be faster, but why do we need all of the bandwidth?
User avatar
Mitch
 
Posts: 118
Joined: Sat Dec 05, 2009 1:59 pm
Location: Florida, USA

Re: Communication protocol

Postby Tom » Wed Oct 27, 2010 4:47 pm

Yep I mostly agree.
Example: Basic GPS data from gluonpilot: GPS
TG;1;0.887507;0.064048;0;626;3;102 + CR
length: 35 bytes

Binary:
[Packet type | Latitude | Longitude | Heading | Speed | Height | Number of satellites]
2 4 4 2 4 2 1
= 19 bytes

So the ASCII data is less than half. Instead of sending data at 250 bytes/sec (say 2400 baud), I'd only need 135 bytes/sec (say... probably still 2400 baud).

So would binary transmission be better? Of course! But my critical resource is time and not bandwith :-)

If you favor bandwith and CPU time, please feel free to implement a binary protocol, it would be great!
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Communication protocol

Postby Chris » Wed Oct 27, 2010 6:30 pm

Yea, ok. But, for attitude data it should be a lot faster (faster than the max 20Hz its at now, too if you want any kind of frequency content), and for sending controls via serial it seems so far like that needs to happen pretty quick for smooth controls. You're limiting yourself by choosing a slower protocol now if there is some greater amount of data you need to send later on, like in flight tuning or debugging or something along those lines. Why not just read the serial port with a little app instead of hyperterm or whatever you use now? Binary is also less work for the microcontroller since it doesn't have to do as much data conversion.

I don't see the advantage of ASCII for those reasons, but I understand that it's not what's on there now, so it would take a bit more time to put it together. I just think it's kind of shortsighted, not trying to knock anyone, but not too far down the road I think you'll find uses for more bandwidth.
Chris
 
Posts: 19
Joined: Sat Dec 12, 2009 4:49 pm

Re: Communication protocol

Postby Tom » Wed Oct 27, 2010 6:52 pm

Hi Chris,

Of course you have a point, but unfortunately I have limited time for the moment, and I prefer to work on quadrocopter stabilization right now. Gluonconfig already reads and writes all commands, so there isn't event a need anymore to see them. It was just one of those decision you need to take: "I'll start with a simple ASCII protocol and change it to binary when everything works". Well, hobby projects are never finished :-)

For attitude data: if 20Hz isn't enough, you can easily change this in code to have a higher update rate: http://code.google.com/p/gluonpilot/sou ... n_csv.c#78
You could change the protocol to binary (can be done in the same code: header=2 bytes, last byte = <CR>, the bytes in between can be anything else) if bandwith is the limit.

For control over serial:
Can be done in a very efficient way (you only need to send 4 controls, which would make it about 8 bytes in the current CSV protocol mode) reaching speeds similar to an RC-link (not taking into account XBee delays).

Did you have time to make any progress on this? I'd love to integrate a Joystick tab in gluonconfig :-)

Tom
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Communication protocol

Postby Mitch » Wed Oct 27, 2010 8:31 pm

We're really hardware limited. Using low cost telemetry, we could never get the bandwidth high enough to really analyze stability, binary protocol or other. I reverted to hardwire serial just to plot quad step responses. Max throughput on an xbee is only about 19.2kbaud. So even if we could double the data rate we still haven't accomplished enough. I've looked at alternatives, bluetooth, wifi, irda and am presently even looking at using a Frsky transmitter module onboard. It's all a compromise - weight, cost, complexity... that is the hobby! :D
User avatar
Mitch
 
Posts: 118
Joined: Sat Dec 05, 2009 1:59 pm
Location: Florida, USA

Re: Communication protocol

Postby Chris » Thu Oct 28, 2010 6:09 pm

@Tom: For the joystick, it didn't really come out as a drop in solution since a lot of the PPM stuff got changed just out of convenience. I'll see if I can put some code together that has the packet types for the pilot controls data. A switch or flag could probably be coded in to switch between PPM or serial controls, but we just turned off the PPM in hard code, so that part might take a little fooling around.

Also, to deal with communication problems (dropping bytes, incorrect bytes, etc) we implemented a checksum at the end of each packet and that pretty much eliminates that problem. I am thinking of switching the code so it follows something similar to the CH robotics protocol (http://www.chrobotics.com/), which is described in their data sheets for the 6d and 6dm modules. It is like this: 'snp' PT numberDataBytes dataBytes checksum. The point being there are no semicolons so you eliminate lots of excess. The 'snp' means 'start new packet', but you could just start the packet with the 2 letter PT (Pacekt Type) and save more bytes. All but 'snp' and PT are in binary, so you can push a lot more data than with GLuonpilot's current protocol.

@Mitch I'm definitely interested in new radios. I like the XBee for its simplicity, but it is certainly limited. I'd be interested to hear what you find out.
Chris
 
Posts: 19
Joined: Sat Dec 12, 2009 4:49 pm


Return to Firmware

Who is online

Users browsing this forum: No registered users and 3 guests

cron