Howdy DIYDrones. I'm presently working on a university research project with a few other students integrating a PixArt IR sensor from a Nintendo Wiimote with ArduPlane. I'm using version 2.24 of the codebase but will likely be porting it forward in the next couple of weeks. I'm hoping to get some input from the APM dev team as to whether or not I've got everything sorted out on the aircraft side of things.
What I want to do is collect data from my sensor and send it over Mavlink to my GCS. Unfortunately, I haven't been able to find a discussion by anyone else that's written a fully-integrated sensor payload addition to APM. The closest I've seen is Eric's post on local logging from a humidity sensor. Here's what I've done so far:
So all of the above compiles but I don't really have any way of testing it until the ground station guys finish. I'm just wondering if I missed anything so we can avoid some headaches later on. Also, what's the preferred method of maintaining stuff like this (version control, diff patches?)
Impressive! I have no idea if that's all right (I'm not one of the developers), but it sure sounds like you know what you're doing!
Thanks! I got here by starting with ArduPilotMega.pde and reading down the page, tracking function calls for one or two other sensors through the various code files and trying to piece together how the main loop structure and Mavlink implementation work. There are plenty of places I haven't gotten into yet though which is why I'm wondering if I've missed anything.
Andrew, what are you having trouble with on the GCS?
I was unable to connect with APM on serial port 3 due to a defective XBee interface board. I found out too late that the Sparkfun XBee Explorer Regulated isn't actually TTL-level compatible. Apparently this is a known problem. I received and assembled a DIYDrones XtreamBee board the day before we went on winter vacation and only had enough time to verify the wireless was working with a loopback test program.
I'm one of the people working on the GCS end, and I did most of the implementation of the message definitions and UI widget. There aren't any specific technical problems we've had with the GCS itself. The maintainability problems mostly derive from having to write a custom parser for the custom Mavlink messages. Another issue is simply that none of us are particularly familiar with VB.NET, as we do mostly C/C++/Python.
As it is, I believe all the current changes should work (barring any mistakes on my part); as was mentioned we simply haven't had a chance to connect the APM to the GCS and test our custom messages because of the XBee problems. I was able to connect the APM to the GCS over serial and read the standard message set.
Ok, are you guys doing 2-way with the GCS or just reading the outbound data stream? If it's just out from the auto pilot, you might want to try a simple ArduPilot Legacy stream which would be easy to maintain.
We're doing two-way with the GCS. As an aside though, which GCS still supports legacy APM streams?
Mine....and I assume you could still download the LabView GCS. But I wouldn't recommend it.
Good to know!