Yes, but not with ArduPlane/ArduCopter.
It is not something you can simply turn on. You have to tell your application how to use it. That is why it is called API mode. http://en.wikipedia.org/wiki/Application_programming_interface
Yup thats true...trying to do that ...I am trying to insert my XBee API header and footer before and after the MAVlink packet in the function _mav_finalize_message_chan_send contained in mavlink_helpers.h file. But as soon as I download them to the board all communication just goes down. Most probably, this is something to do with the timing for sending a telemetry packet. Hence the query.
Get a copy of "Building Wireless Sensor Networks" by Robert Faludi
See also http://code.google.com/p/xbee-arduino/ (Make sure you are using Series 1 examples)
Any luck working this out? I am looking to do something similar- Use API to send MAVLink packet, so that I can try the Series 2 mesh network concept with MAVLink data. Let me know if you have made any progress/ decided it is not possible.
We were successful in transmitting a MAVlink packet to QGCS using XBees programmed in API mode. Just attach the API header and calculated checksum as the footer to the MAVLink packet in MAVLink_helpers.h. We also implemented a framework for HILS of a bunch of aircrafts using the XBee API mode for inter a/c comms.
That's great news... I took a break from trying to crack the XBee problem to put out some other fires, but I will definitely give that a try.
I am working on demonstrating multiple a/c formation flight - I'd love to hear more about your HILS framework... What is the set-up?
Nothing much...we were using APM1.4 without the oilpan with the firmware that JLN had modified to work w/o an oilpan (http://code.google.com/p/ardupilotdev/downloads/detail?name=ArduPla...) . We connected 3 APMs to a laptop started 3 FGFS instances with different port numbers, set the same port numbers in the 3 individual APM mission planners and that's it!! The a/c communicated with each other via XBee. The Overall system was monitored via QGCS. Hope this helps...
How did you deal with the API on the GCS side? I understand that the modified Mavlink_Helpers takes care of things on the UAV side, but how did you get the mission planner to deal with the extra junk?
QGCS is a clever piece of software. It just ignores the XBee API headers and picks out the MAVLINK info only. BUT, we did have to configure the QGCS side XBee in API mode, and disable just the API mode.
Mission planner goes crazy if it gets multiple a/c packets and cannot distinguish between the a/c since it does not distinguish between the a/c id in MAVLINK. So, we used APM Mission planner just as a glue between FGFS and APM.
Hope this helps.
I'm having having a hard time trouble-shooting.
I'm wondering if I am actually missing some crucial steps... Most resources I've seen tend to hand-wave the initialization of an ZigBee network using the API mode. Are you doing any special setup for the network in an initialization function?
I think this is my sticking point... What do you mean by this?
"BUT, we did have to configure the QGCS side XBee in API mode, and disable just the API mode."
The more I understand about the API mode, the more I feel like QGCS needs to know it is dealing with an XBee in API. I see an option in the QGCS communication setup to work with an XBee in API, but I have not had any luck establishing a connection with that.
Right now, I have XBees on the UAV side in API as well as the XBee on the QGCS. I have the API header and checksum wrapped around the outgoing MAVLink protocol. Still can't them talking. Any suggestions are appreciated.