Integration of Remizibi OSD with Ardupilot Ground Station

I am just starting out in FPV, putting together a HK airplane with video, Ardupilot Mega (APM) and a ground station. My end goal is to overlay computer generated symbology with camera video and/or a synthetic representation of the terrain - not quite there yet, but the flexibility of the APM with the availability of source code has convinced me that it is the right platform to build on.

However, I have got the APM running with xbee modules to communicate with an Ardustation Mega running the load from Colin as described here (http://diydrones.com/profiles/blogs/ardustation-twoway-telemetry). I made a couple of mods to get a display of GPS satelite count but this was primarily as a first Arduino programming exercise - the rest would have worked fine wthout the mod. The Ardustation is self contained with a LiPo in the box for power with the balance connector pinouts taken through the 9 pin D connector on the side for charging.

I then tried to figure out how to integrate a Remzibi OSD, but didin't find much on the web about using it with the APM (as opposed to the standard Ardupilot), and quickly realized I was out of comm ports if I wanted to have the xbees running at the same time. However, I had a spare APM (no IMU) so came up with a protocol converter - basically it reads the serial stream running through the xbees and sends out Remzibi 1.71 data on a second comm port. For the data that is coming out of the APM using the GCS_Standard protocol it works with the standard APM S/W load - S/W changes are required only to get access to data that is not already on the telemetry link. The Remizibi output code is derived from the Ardupilot 2.6 code posted by HappyKillmore for Remizibi integration as described in his thread here http://www.rcgroups.com/forums/showthread.php?t=1234310.

It was getting a bit tight in my HK FPV (even after cutting out a fair bit of the foam and gluing 1/16 ply for new sides), and while figuring out how to handle that I realized that the OSD does not need to be on the aircraft - it can equally well be on the ground. I packed the OSD and second APM into a little box, and hooked on to the Ardustation serial data from the xbee. As of today I have all the standard GPS data (lat,long,GS, altitude, date, time, etc.), APM mode, and artificial horizon.Date and time took some mods in the APM code, everything else was available.

Next is to use one of the spare inputs on the IMU to add a current sensor input and hook up the battery balance connector to the IMU for voltage monitoring.

One downside of moving the OSD to the ground station is that you lose the mAh counter built in to the Remzibi. It doesn't look like there is any way to send a command that substitutes for the ADC6 (default current sensor) input, so will need to add some code to either the main or ground station APM code to integrate the current sensor input. An alternative might be to run one of the PWM output pins of the APM through an RC filter and send that to the Remzibi ADC6 input.

Apart from simplifying the wiring in the aircraft, this approach means that I keep the OSD symbology even if the video link has problems (of course, I would lose the symbology if the telemetry link goes down). I  also have the standard video (no symbology) and the version with symbology available simultaneously, flying on one while recording the other if desired. Nothing in the implementation is dependent on the Ardustation beyond access to the xbee data (and that could always be handled by an FTDI to xbee adapter board), so I can move the Remizibi back and forth between the ground station and the aircraft without needing to change the code.

 

If I had thought this all the way through before starting the build I think that I would have used a larger box and integrated everything (Ardustation, Remzibi, second APM) into one unit.

From a quick look at the 2.0 code it appears that the "GCS_Standard" protocol has gone, so will require some rework to integrate the MAV link protocol, but I think that the basic approach will still be valid.

 

Won't get to test fly it for a couple of weeks, but it has been fun so far.

Views: 1546

Comment by Earl on March 2, 2011 at 6:40pm

It is GPS_LEGACY protocal. I use it with my ER9x transmitter display on the tx lcd.

Earl

 

Comment by Andrew Fernie on March 2, 2011 at 7:27pm
I am using GCS_STANDARD for this project - the ArdustationM code I started from was based on it. GCS_LEGACY was available in the APM load, but is not being used.

Andrew
Comment by Darren on March 3, 2011 at 6:47am
just so happens i have a spare APM without an IMU, so would be very interested in looking at the code your running on the apm.
Comment by Andrew Fernie on March 3, 2011 at 7:02am
I will make the code available after I fly it - I want to make sure that I have not missed anything.

Moderator
Comment by Hai Tran on March 3, 2011 at 7:14am
that's a great idea to use the overlay on the ground instead!!

Developer
Comment by Mark Colwell on March 3, 2011 at 9:58am

Great job with ArduStation, I needed to update ArduStation for APM.2 but you beat me to it !!

I'm waiting for your published code. I enhanced uBlox to send GPS_Lock with quility of fix data.

Comment by Darren on March 3, 2011 at 10:31am

I've got a hacked up version of the ardustation to run on the mega apm_rc libraries too... :)

never dawned on me to just overlay the data on the ground side... this can really help curve my weight issues ;)

Comment by JJ Blackwood on March 3, 2011 at 10:53am

I've been struggling with the same issue - same airframe, same hardware, trying to find a way to push GCS data to the Remzibi and Xbee. I like this solution, saves weight in the air and cargospace.

 

I would like to keep the mah counter functionality, the OSD ADC6 is a 10-bit ADC, and it looks like we have access on the IMU to several 10-bit ADCs available through the IMU expansion port AN6 and AN7. I'm guessing adding the current-sensor reading to the GCS would allow recreation of the mah counter on the ground, but I'm wondering if it would be better to read in a 10-bit ADC value through the expansion port on the IMU, or is there a 12-bit ADC free onboard that could give a better reading?

 


Developer
Comment by Mark Colwell on March 3, 2011 at 11:29am
These should all work, (12 bit dac maybe..) and more. I can foresee a simple RTL AP in Remzibi OSD similar to EagleTree Pro, but that is just a dream now. Here are screen shots of it working in real time, Not all senor are connected.. In Manual mode it send Pan & Tilt data.

Developer
Comment by Mark Colwell on March 3, 2011 at 11:59am

Screenshot in Manual mode showing Video Tx battery votage, Pan, Tilt angle, HDOP value and User ID

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service