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!
Comments
Serial.print(buf->next_WP.lat, DEC);
Serial.print(" ");
Serial.println(buf->next_WP.lng, DEC);
Serial.print(" ");
Serial.println(buf->next_WP.alt, DEC);
Serial.print(" ");
Serial.println(buf->checksum, DEC);
I would like to expand on it by adding a control code, variable len packets and a two byte leader. however the software serial and plug into the code is the useful part
Do you have a log file that shows the actual transfer of sending a waypoint? I haven't looked at a Java source file in 8 years. I'll continue to try to reverse engineer, but it would be easier if you just had a communications protocol document.
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?
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.
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 !
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
@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.
Anyone interested in it now?
-
1
-
2
-
3
of 3 Next