Loading a Waypoint in the Air with XBees

Hey everybody, me and my friend Chester would like to share our implementation of loading a waypoint into the ArduPilot in air. We use XBee radios, NewSoftSerial, and our own GCS written in Java (using Andrew Rapp's xbee-api) to do this. Our GCS was originally designed to facilitate a collision avoidance system for multiple UAVs (this is part of a research project at Auburn University), but we've added a small GUI to allow the user to type in their own waypoint to push to the plane.

In the ArduPilot code, we added a function to poll the XBee for a waypoint packet (we give it a data type of GCS_packet_t) in the 3 1/3 Hz loop. The XBee's TX pin is hooked up to analog4 (one of the few pins we found was not in use) via NewSoftSerial and runs at 57600 baud. If it has a valid packet, it replaces the ArduPilot's next waypoint value with the one from the packet. After it hits this new waypoint, it loads the old next waypoint back in from EEPROM and continues on its original path.

We tested this in our setup with a Multiplex EasyStar, an ATmega328-based ArduPilot running 2.6.2 modified with our code (compiled in Arduino 0018), and an EM406 GPS also at 57600 baud. We are ArduPilot newbies ourselves, but we think everything worked to our expectations.

Our code is available at this github: http://github.com/wjwwood/au-proteus. In the ArduPilot_2_6/ folder, you can find our modified ArduPilot code, along with an extensive guide (XBee_Guide.txt) written by Chester on where the changes are and the rationale behind them. In the xbee-api/ folder, you can find a Readme for the GCS code (XBeeGCS_README.txt).

While we'll be leaving our research program in a few days and not be able to work directly with the planes at Auburn anymore, we'd be glad to hear your comments on this work. Cheers!

For those interested, I can recompile the current(old) LabView GCS with my plugin of clicking a point in google earth and having it ready to send to Ardupilot in the air running Varun's modified code. This would be temporary until Ardupilot officially supports it, and the GCS team (which still hasn't emailed me on joining :-( ) releases there new GCS which is suppose to have it as well.

@Greg: yep, the GCS code is also in that github link in the blog post, inside the xbee-api/ folder.
@Bill: That sounds great, I hope the GCS code we have up now is flexible enough. Right now our solution on the ArduPilot is kinda hackish in itself, since it avoids touching the EEPROM.

Bill,
Pls go ahead and compile. I am sure there are hundreds who would appreciate your plugins for LV GCS. I am avid user of LV GCS. The GCS team is right now busy with few other developments and probably come back to GCS development in next couple of months. Thanks

Hi Varun ! Hats off to you and to your friend Chester for sucha wonderful work !
You guys have done a great job of waypoint updation on the fly, have you flight tested the modified Ardupilot code or you just ground tested it ?
I wish you all the best for your bright future !

@NS Rana: Thanks! We have tested it in the air, and as far as we can tell, it flies to the waypoint we loaded in the air. The XBeeGCS shows that the next waypoint is the one we loaded, along with our special waypoint index (997). After reaching it, it reloads the waypoint we overwrote in SRAM.

Thanks, I was going to see if software serial could handle some of the load allowing for two way. It is really useful that you have proven this to work and I vote that this code (or similar) to be included in the main ardupilot realease.

Two way telemetry opens many doors...

I also vote for the IMU code to change so that it receives a config instruction via xbee (or serial) to specify the GPS type at startup. The IMU seems to have enough free code space for it to compile all current gps types.

If DIYd shipped IMU's loaded with this code (in text mode) then non-technical users could buy a gps, imu, two xbee (with shields) and have telemetry working "out of the box" without the need to change code or own an FTDI cable.

It would be a system that provides a number of upgrade paths. A worthwhile investment even without the ardupilot.

Okay I've looked at the code and I like the fact you have maintained compatibility with the existing GCS_PROTOCOL of 0.

Am I right in thinking that you have not altered the main 2.6.2 code substantially and that everything works as normal? To switch on two way telem we simply leave the #define XBEE_READ at the end of the config .h?

If you agree with my comments then it really is very clean and the right way forward.

As concerns tracking multiple planes do you think a new config property containing the id or "call sign" of the equipment would be a good idea? I would like gcs logs to identify the UAV and a config setting seems more reliable over the long term than xbee ids?