Hi everyone,
A small group of us are working on "swarm" UAV flight and it's become my task to put together/help work out the onboard computing situation. I've worked in satellite systems and building UAVs but I'm pretty new to the software and interface arena. I'd like to share what I have going so far and get your input on a couple of issues I'm running into in this process.
The platform we are using is the flying wing configuration, specifically the Zephyr at the moment. They are being controlled with the APM2.5 board. As we progress farther with the project computing power is going to become an issue (the most we've flown is five UAVs to a ground station with two ground stations). Our aim is considerably higher, flying 50 UAVs at once.
Earlier I managed to connect an Arduino Mega (as slave) board to the RPi using I2C, and was able to get connection to QGroundControl and RPi, displaying the heartbeat MAVLink message to both. Of course, moving on to the APMx board is another story as, of course, the barometer I2C connection automatically bumps the APM board status to I2C master which is not compatible with either of the platforms were are looking at, RPi and GUMSTIX.
My next step then is moving on to UART or SPI (trying to leave the USB ports open). This is where my knowledge gets especially thin. I2C was fairly easy to follow (lots of online support) but not so much for UART or SPI, and with the APM2.5 I noticed that the telemetry port is UART, so how many devices/comms can UART support? Can it interface with radio AND RPi? It seems that there isn't an address assigned so specifically as in I2C, which is a little concerning, that or I just haven't explored it enough yet. Either way, I'd certainly appreciate input! And I'm sure I've left a couple things out, so apologize in advance.
Replies
Fun Update:
Successfully connected a RPi to the ArduPilot. What does this mean, exactly? Simply, I have a python script running on the Raspberry Pi that I took from the EastBay RC group page (linked in the discussion) that is receiving MAVLink/Serial via USB (between it and the APM2.5), and telemetry working through the hardlined UART2 on the side of the board. I was expecting "something" magical to keep it from working, but telemetry successfully connected to the APM2.5, and displayed the autopilot data on QGroundControl. At the same time, the decoded MAVLink messages are being shown on the RPi terminal.
Next step then, is to understand how messages from the respective computers (RPi/GCS) are/can be choreographed to control the APM.
Am I missing something? Is there a reason you don't hook up the raspberry pi serial to the telemetry leads of the APM?
and then use ser2net on the pi (which you have wirelessly networked in some manner)?
To end the day, a little foolishly perhaps, I can't seem to locate the FastSerial.h library anywhere in the ArduPlane code. This weekend should verify, but surprising/confusing/intriguing nonetheless.
Hi Carson!
I stumbled on the same problem recently, and even though I haven't yet made any modification to the APM code, these links I found should help you (there's even working arduino code) :
http://www.i2c-bus.org/MultiMaster/
http://forum.arduino.cc/index.php/topic,13579.0.html
Basically, in I2C, you can have a multimaster mode -> so with a simple modification to your current code, you should be able to get it to work even in the presence of the barometer.
Hope that helps! And BTW, it you could publish your modifications to the APM code to talk via I2C to a RPi, that would be great! -> I wouldn't have to duplicate your efforts ;-)
Status Update:
For our purposes, we only need one extra UART or I2C connection, from the ardupilot to the Raspberry Pi. Currently, I have UART comms between a RPi and Mega/Uno, but now struggling to discover how I can use the Software Serial library (if it's even possible to use with APM2.5 pins, though I don't see why not). Find the pin declarations is a little more difficult than I'd expected.
A potential alternative is to find a USB to I2C adapter (which can be found at Robotshop and Sparkfun, though, I'm not yet familiar with these alternatives yet. The thinking there is that that might bypass the need for a defined slave, though I'm skeptical. I imagine the protocol for I2C itself defines the need for a slave. However, I've learned that I2C is also a multi master protocol... We'll see how this pans out.