Update 10/22/2012 - For those few who may be interested, I'm now using this software on my personal quad with ACM 2.7.3 and 2.8. This software now compiles with Arduino 1.0.1 and works with Mavlink 1.0 or 0.9. The wiring and hardware requirements has not changed. You can download the software from my personal website at this link.
Original Post:
Since I purchased my Arducopter last November, I've wanted to use my NTSC video camera, Remzibi OSD, and 1.280 Ghz video transmitter with my quad and experimented with different ways to do it. It was easier with Arucopter NG RC2 since Mavlink was not in use and I could generate my own serial stream to the OSD. With the release of Arducopter 2.0.x and Mavlink it was a little harder. I really wanted to have Mavlink up and running to my Ardustation tilt/pan antenna and notebook while using the on board OSD.
My solution was to add an Arduino Pro mini to my quad configuration and modify some Mavlink Ardustation software from phillip.anthony.smith to create the serial stream that the Remzibi OSD likes. The details of this mod and link to the my Mavlink to Remzi converter software is available here:
Comments
Hello Heino,
I'm currently investigating how I can use the ImmersionRC XuGong V2 Pro OSD with a Pixhawk/APM.
The OSD that ships as part of the PDB is based on the EzOSD from Immersion and typically get's it's data from a Naze FC or - based on the latest info on in the manual - directly connected NMEA GPS.
It sounds like your code could therefore be used convert the mavlink data stream to a ImmersionRC palatable format.
From what I figure the OSD will take the data for the following functions via the NMEA stream:
- Altitude
- Speed
- Distance and Home direction (a bit a question mark how this would come from the gps or whether the OSD does that automatically based on first GPS coordinates received)
- Sat status (number of sats)
I will give this a try once my XuGong arrives and report back.
Yes the Arduino Pro Mini is flying on my quad decoding the Mavlink and converting it to Remzibi style serial commands for OSD symbology. The feed was one way though - the uplink to the APM is coming from my XBEE and the downlink is tee'd off to the Arduino Pro Mini and Xbee. You can feed the APM Mavlink only if it is the only source. If you still had telemetry to the ground and back, you would need to process the ground stuff in the Arduino and provide a combined Mavlink feed to the APM for manual commands.
Heino
Heino,
Wow, you have done some impressive work setting up your copter and ground station. Did you add MAVlink functionality to the Arduino Pro Mini on-board your copter? Most of the MAVlink/Arduino applications that I have seen are for use in ground stations. I would like to have an on-board Arduino produce “MANUAL_CONTROL” commands for my copter’s APM. My first step is just loading MAVLink functionality on to my Uno. Have you seen this done anywhere?
Thanks,
Jeff
Hi Bryan,
The Remzibi OSD's require a version of their firmware that supports sending arbitrary characters to the OSD display. The converter software I wrote takes Mavlink data coming from the APM, and sends it to the OSD as if it is coming from a GPS (using NMEA messages). I added the additional command to send my callsign as arbitrary characters in the bottom left corner.
Heino
How does someone get their callsign to display?
Yes it will work with Ardupilot also. I just haven't tested it lately - but there have been users of it.
73's
I am guessing this is will work with Ardupilot as well?
Glad to see you identify your transmissions with your callsign.
KB6WSQ
Thanks Monroe
You can use the 8mhz 3.3 Volt Arduino Pro mini if you add a voltage divider to the cabling. The APM puts out a 5 volt serial transmit signal and the Arduino Pro mini can tolerate a max of 3.3 volts. Therefore using a 4.7k and 10k resistor will do the trick:
APM Serial TX -> 4.7K -> 10K -> GND
You would wire the Arduino Pro mini serial input at the connection between the 4.7K and 10K resistors. The Remzibi OSD should read the Arduino Pro mini's output at 3.3 volts correctly without anything special.
I've updated my blog to reflect my new understanding of the use of port 1 on the APM when USB is not plugged in. I still think processing Mavlink to update an OSD is better than modifying ACM/APM code to output a second serial stream of OSD data on top of the Mavlink output. However it is indeed possible to use port 1 for an OSD while using port 3 for Mavlink.