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.
Comments
I tapped off the Ardustation FTDI port, but only the ground pin and the pin that is sending data from the xbee to the Ardustation - this is the same pin that receives data from your PC when you are connected via the FTDI(without the xbee installed) to load/debug the Ardustation. This means that the second APM can only receive data from the xbee, it cannot send data back. Sorry, but I am out of town this week, so can't tell you which pin numbers.
The data flow is as follows - note that there is only a one way data flow (->) to the second APM
Aircraft APM <-> Aircraft Xbee Wireless<-> ArduStation Xbee Wireless<-> Ardustation
|
-> APM -> Remzibi
Screenshot in Manual mode showing Video Tx battery votage, Pan, Tilt angle, HDOP value
and User ID
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?
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 ;)
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.
-
1
-
2
of 2 Next