APM Sensor Integration
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:
- Wrote a sensor driver. Actually, I took the great work done by the Wiibrew community and especially the Arduino PVision library from Steve Hobley and added some features and generally adapted it to my needs. The big change I made is implementing on-the-fly sensor sensitivity settings changes. I've tested and debugged it on the ground in test software (not the APM codebase.)
- Included the sensor driver library in the ArduPilotMega.pde Libraries section.
- Added the sensor data object declaration to ArduPilotMega.pde Sensors section. The constructor is set up to fully initialize the sensor so no further code is required before data can be read.
- Added the sensor data object read/update command to the medium loop in the same case as the GPS. I don't need updates very often and wasn't sure which of these has the least overhead and could take the additional overhead of the sensor update command. It's a pretty straightforward I2C transaction of 10 bytes so the additional latency should be low.
- Wrote a new .xml file defining the Mavlink messages I want to use to get data from the sensor and send new sensitivity settings from the ground station and included it in ardupilotmega.xml. They're defined as <message>.
- Used mavgen to autocode the C helper functions for the entire project, then overwrote the relevant files in libraries/GCS_Mavlink/include. Since I'm on 2.24 I used Mavlink protocol version 0.9 instead of 1.0, but I should be able to change that to 1.0 without messing with the .xml in the future?
- Added send_message commands with my Mavlink helper names to the available streamRateExtra3 stream in GCS_Mavlink.pde.
- Added a case to handleMessage in GCS_Mavlink.pde which sets the sensitivity settings on the sensor when it receives the set sensitivity message.
- Added cases for each message to mavlink_try_send_message in ArduPilotMega/Mavlink_Common.h.
- Incremented the MAX_DEFERRED_MESSAGES value in Mavlink_Common.h by the number of messages I added.
- My team wrote a parser and UI widget for HK GCS using the new message definitions, but maintaining it is turning out to be a royal pain. We're in the middle of porting it over to QGroundControl.
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?)
Replies to This Discussion
-
3D RoboticsPermalink Reply by Chris Anderson on -
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!
-
Permalink Reply by Andrew Beckett on -
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.
-
Permalink Reply by Paul Mather on -
Andrew, what are you having trouble with on the GCS?
-
Permalink Reply by Andrew Beckett on
-
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.
-
Permalink Reply by Josh Harris on -
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.
-
Permalink Reply by Paul Mather on
-
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.
-
Permalink Reply by Andrew Beckett on
-
We're doing two-way with the GCS. As an aside though, which GCS still supports legacy APM streams?
-
Permalink Reply by Paul Mather on
-
Mine....and I assume you could still download the LabView GCS. But I wouldn't recommend it.
-
Permalink Reply by Andrew Beckett on
-
Good to know!
-
Permalink Reply by Andrew Beckett on
-
We'll definitely keep that option in mind if getting Mavlink with two-way comms working proves problematic. If necessary, we can rework the experiment for one-way but here's hoping we won't need to.
I was thinking of the LabView GCS when you suggested the legacy stream and as I recall it's not maintained. Glad there's an alternative. -
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1299 members
-
Moderators
24 members
-
Melbourne
48 members
-
Documentation Editors
51 members
-
UK Ardupilot Group
111 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
