After learning in my last thread that the ArduPilot roadmap is going in the direction that I was considering branching it, I tried to think of the best way for me to help accelerate the effort without duplicating existing projects or stepping on anyone's toes. I've decided to begin work on a ground station for the ArduPilot, which will allow for more complex in-flight manipulation of the flight path as well as replace the traditional analog control radios.One component of this task is designing a standardized communication protocol that will allow the ground-based computer to communicate with the ArduPilot over digital radios. It would be great to get some input from others on what sorts of commands this protocol needs to be able to handle.Here are my current off-the-top-of-my-head ideas:Manual flight controls:- Set throttle- Set rudder- (is there anything else requiring manual control?)Autopilot flight controls:- Navigation mode (waypoint, manual, RTL, loiter)- Picture mode (single, continuous, off)- List of waypointsPlane information:- Current position- Current velocity- Battery voltage- other sensor readouts?- Firmware versionI anticipate sending a command with a unique two- or three-character string would be selected to indicate the command type, followed by the pertinent options and an end-of-command character. The plane would respond with a short "ok" message.Example: set the navigation mode to waypointGround station string: "sV:15.00\n"Plane response string: "sV:ok\n"Example: get the current battery voltageGround station string: "gBV\n"Plane response string: "gBV:12.21\n"
You need to be a member of diydrones to add comments!
Interesting stuff, I've been thinking along some similar lines.
My main concern with the ATMega168 is the single uart it has, so how would you share it effectively between GPS and RF incoming comms?
I've been thinking of trying out the bigger ATMega types with more uarts to have a dedicated GPS uart and ground comms uart...
My goal would be to eliminate the RC Rx/Tx entirely and use manual mode through commands via RF to the ardupilot instead of mux and Rx...
Kyle, just found this post, I am also working on a ground station for Ardu. Interesting you are using Python, I was planning C++ but I know some Python as well. How far have you gotten?
I have developed a byte oriented protocol rather than one based on strings. This saves some space and is very easy to implement. i am working with fixed length messages of 6 bytes. cmd, data1, data2, data3, data4, checksum. The command can transmit four bytes, two words or one four byte integer. Its really easy to implement and it uses minimal overhead as long as there is limited amount of data to transmit. Here are som examples of commands in my protocol:
11 GPS status 1= no fix, 2= 2D fix. 3= 3D fix
12 Rtarget,Ptarget : short +/- 90
13 Rangle, Pangle : short +/- 90
14 RServo, Pservo : short +/- 500
Always send 12,13,14 in sequence
15 Calibration done : short irmax
16 pid value : short pidID, Value
17 IR value : short irID, Value
18 Servo value : short servoID, value
cmd to STAB (cmd 01-99)
1 Set Rangle, Pangle : +/- 90
12 Set PID, PidID,0-10000 div by 100 in stab
13 Get PID, PidID : int PIDvalue (dic by 100 to get double in pid loop)
PidID
1 RP
2 RI
3 RD
4 PP
5 PI
6 PD
7 SP
8 SI
9 SD
14 SetServo servoID, value
15 GetServo servoID, value
Servo ID
1 Aileron max 1500-2500
2 Aileron min
3 Aileron center 1000- 2000
4 Elevator max
5 Elevator min
6 Elevator center
16 SetIR values
17 Get IR values
IR ID
1 IRMax, 511 - 1023
2 roll center, raw ir value 511
3 pitch center, raw ir value 511
90 Rtarget,Ptarget (int,int)
The downside with this protocol is that if you loose one byte you will get out of sync and not be able to recover. My solution to this is to add one byte to the message and use only seven bits for data transfer. This way i can use the eight bit to indicate start of message in the cmd byte. This is the way the MIDI protocol is built and it has some similarities to what we want to achieve. We want to be able to send large chuncs of data when upploading waypoints or settings, but we also want to stream data very quickly when controlling the rudders in manual or semi manual modes.
If you are interested google the MIDI implementation. I think it is useful for what we want to do.
Good point, I agree that when controlling individual servos in manual mode priority should be on spitting out commands at the maximum rate possible, and missing data isn't a big deal. But I think that when in autopilot mode the connection will probably be less crowded, and there should be room to verify whether the plane is getting the information it should.
Joshua,
Interesting! I haven't written the comms module yet and probably won't get to it for a while, but that sounds like a good step towards getting it to work in the real world. My goal is to create a bare-bones release in the next month or so, but adding support for that will be a priority once everything else is good to go.
EDIT: I forgot to add that as I was browsing the XBEE 900 spec sheet there was something about the radio having a built-in signal strength level estimation that could be read, which might be useful in setting FEC levels.
May I recommend at least considering Forward Error Correction.
As a UAV often at the edge or beyond the radio range, you never know when that command you just sent could have been critical to the flight. Maybe it’s to deploy the parachute in case of an emergency or dodge that previously unknown obstacle.
Look here for more details. http://en.wikipedia.org/wiki/Forward_error_correction
As an avionics technician and a HAM Radio technician, I can say that it makes a huge difference when implemented properly no matter what kind of digital data is traversing the airwaves.
More bandwidth WILL be used but if there is bandwidth to spare at all, it is worth it. Most implementations allow for FEC to be either OFF, or at varying ratios such as 5%, 20%, 50%, etc. For extended range a larger FEC ratio would help make sure those commands make it back and forth from the UAV when signal strength is very poor.
"Many FEC coders can also generate a bit-error rate (BER) signal which can be used as feedback to fine-tune the analog receiving electronics." Quoted from Wikipedia.com article above. Imagine the ground station and the UAV being able to independently recognize deteriorating signal quality due to errors in the data and being able to automatically adjust the FEC ratio to compensate and extend the useful range.
FEC is usually implemented in radio circuit very close to the modulation and demodulation but can also be done in SOFTWARE on the data stream. Obviously the choice is modify the RX'r & TX'r or to implement the FEC in code. So instead of sending the RAW command of "StartEngine" it would be run through a function(in code) to translate "StartEngine" to a format such as binary that will be sent over the radio through the D/A converter and out the transmitter. The process reversed on the other side. I guess that was a complex way of saying either it can be done by adding the appropriate IC's in the radio circuits or by doing it in the software code such as on the Arduino and the computer base station for example.
It may not be worth all the effort but I would at least like to throw the idea out there.
I plan on experimenting with a solution like this with ArduPilot and a ground base station with a tracking antenna to further the range I can receive telemetry data and video feed. I plan on trying to use off the shelf 802.11n equipment which offers MIMO and Spatial Diversity advantages.
See: http://www.wirevolution.com/2007/09/07/how-does-80211n-get-to-600mbps/ for some impressive details. I hope that I can find a solution that will work. 600mbps is almost unimaginable although I figure I might get half of that. As most of you will know your wifi automatically lowers the bit rate of your connection as distance increases and signal quality/strength decreases automatically extending useful range of your laptop.
I can't wait to get back in country to play with my new toy ideas. Hopefully the wife will think it’s as neat as I do. :)
Such protocol for up/download and groundstation would be a very nice complement to ArduPilot.
May I suggest using 1 byte alphabetical headers followed by 1-2 byte data? For many tasks, a 1 byte data is sufficient (0-255 steps).
At least it is such minimal header/data that I implemented in my headtracker-pan&tilt system over Xbee Pro 868 (which has limited bandwidth in its 10% duty cycle) (code is here).
As to servo control serial upload, I wonder if the acknowledgment data should not better be avoided. In fact, in case a servo position data is not received by the plane, it is much more important to receive the next position data rapidly than waiting for the missing data.
As to a Python groundstation, I agree it would be better to have a free solution that people could tweak to their needs, although a Labview groundtation as an exe would be perfect for people just wanting an as is working solution.
Overall, this would really be a nice complement, Kyle.
Kyle, that's terrific. Jordi has a working groundstation, but it doesn't have upstream commends. It might be a good idea to harmonize our commands with AttoPilots (see them midway in this post), on the hopes that we can someday share technology or software between the two autopilots.
Replies
My main concern with the ATMega168 is the single uart it has, so how would you share it effectively between GPS and RF incoming comms?
I've been thinking of trying out the bigger ATMega types with more uarts to have a dedicated GPS uart and ground comms uart...
My goal would be to eliminate the RC Rx/Tx entirely and use manual mode through commands via RF to the ardupilot instead of mux and Rx...
I have developed a byte oriented protocol rather than one based on strings. This saves some space and is very easy to implement. i am working with fixed length messages of 6 bytes. cmd, data1, data2, data3, data4, checksum. The command can transmit four bytes, two words or one four byte integer. Its really easy to implement and it uses minimal overhead as long as there is limited amount of data to transmit. Here are som examples of commands in my protocol:
11 GPS status 1= no fix, 2= 2D fix. 3= 3D fix
12 Rtarget,Ptarget : short +/- 90
13 Rangle, Pangle : short +/- 90
14 RServo, Pservo : short +/- 500
Always send 12,13,14 in sequence
15 Calibration done : short irmax
16 pid value : short pidID, Value
17 IR value : short irID, Value
18 Servo value : short servoID, value
cmd to STAB (cmd 01-99)
1 Set Rangle, Pangle : +/- 90
12 Set PID, PidID,0-10000 div by 100 in stab
13 Get PID, PidID : int PIDvalue (dic by 100 to get double in pid loop)
PidID
1 RP
2 RI
3 RD
4 PP
5 PI
6 PD
7 SP
8 SI
9 SD
14 SetServo servoID, value
15 GetServo servoID, value
Servo ID
1 Aileron max 1500-2500
2 Aileron min
3 Aileron center 1000- 2000
4 Elevator max
5 Elevator min
6 Elevator center
16 SetIR values
17 Get IR values
IR ID
1 IRMax, 511 - 1023
2 roll center, raw ir value 511
3 pitch center, raw ir value 511
90 Rtarget,Ptarget (int,int)
The downside with this protocol is that if you loose one byte you will get out of sync and not be able to recover. My solution to this is to add one byte to the message and use only seven bits for data transfer. This way i can use the eight bit to indicate start of message in the cmd byte. This is the way the MIDI protocol is built and it has some similarities to what we want to achieve. We want to be able to send large chuncs of data when upploading waypoints or settings, but we also want to stream data very quickly when controlling the rudders in manual or semi manual modes.
If you are interested google the MIDI implementation. I think it is useful for what we want to do.
/Magnus
Good point, I agree that when controlling individual servos in manual mode priority should be on spitting out commands at the maximum rate possible, and missing data isn't a big deal. But I think that when in autopilot mode the connection will probably be less crowded, and there should be room to verify whether the plane is getting the information it should.
Joshua,
Interesting! I haven't written the comms module yet and probably won't get to it for a while, but that sounds like a good step towards getting it to work in the real world. My goal is to create a bare-bones release in the next month or so, but adding support for that will be a priority once everything else is good to go.
EDIT: I forgot to add that as I was browsing the XBEE 900 spec sheet there was something about the radio having a built-in signal strength level estimation that could be read, which might be useful in setting FEC levels.
As a UAV often at the edge or beyond the radio range, you never know when that command you just sent could have been critical to the flight. Maybe it’s to deploy the parachute in case of an emergency or dodge that previously unknown obstacle.
Look here for more details.
http://en.wikipedia.org/wiki/Forward_error_correction
As an avionics technician and a HAM Radio technician, I can say that it makes a huge difference when implemented properly no matter what kind of digital data is traversing the airwaves.
More bandwidth WILL be used but if there is bandwidth to spare at all, it is worth it. Most implementations allow for FEC to be either OFF, or at varying ratios such as 5%, 20%, 50%, etc. For extended range a larger FEC ratio would help make sure those commands make it back and forth from the UAV when signal strength is very poor.
"Many FEC coders can also generate a bit-error rate (BER) signal which can be used as feedback to fine-tune the analog receiving electronics." Quoted from Wikipedia.com article above. Imagine the ground station and the UAV being able to independently recognize deteriorating signal quality due to errors in the data and being able to automatically adjust the FEC ratio to compensate and extend the useful range.
FEC is usually implemented in radio circuit very close to the modulation and demodulation but can also be done in SOFTWARE on the data stream. Obviously the choice is modify the RX'r & TX'r or to implement the FEC in code. So instead of sending the RAW command of "StartEngine" it would be run through a function(in code) to translate "StartEngine" to a format such as binary that will be sent over the radio through the D/A converter and out the transmitter. The process reversed on the other side. I guess that was a complex way of saying either it can be done by adding the appropriate IC's in the radio circuits or by doing it in the software code such as on the Arduino and the computer base station for example.
It may not be worth all the effort but I would at least like to throw the idea out there.
I plan on experimenting with a solution like this with ArduPilot and a ground base station with a tracking antenna to further the range I can receive telemetry data and video feed. I plan on trying to use off the shelf 802.11n equipment which offers MIMO and Spatial Diversity advantages.
See: http://www.wirevolution.com/2007/09/07/how-does-80211n-get-to-600mbps/ for some impressive details. I hope that I can find a solution that will work. 600mbps is almost unimaginable although I figure I might get half of that. As most of you will know your wifi automatically lowers the bit rate of your connection as distance increases and signal quality/strength decreases automatically extending useful range of your laptop.
I can't wait to get back in country to play with my new toy ideas. Hopefully the wife will think it’s as neat as I do. :)
May I suggest using 1 byte alphabetical headers followed by 1-2 byte data? For many tasks, a 1 byte data is sufficient (0-255 steps).
At least it is such minimal header/data that I implemented in my headtracker-pan&tilt system over Xbee Pro 868 (which has limited bandwidth in its 10% duty cycle) (code is here).
As to servo control serial upload, I wonder if the acknowledgment data should not better be avoided. In fact, in case a servo position data is not received by the plane, it is much more important to receive the next position data rapidly than waiting for the missing data.
As to a Python groundstation, I agree it would be better to have a free solution that people could tweak to their needs, although a Labview groundtation as an exe would be perfect for people just wanting an as is working solution.
Overall, this would really be a nice complement, Kyle.