The Remzibi OSD is a versatile and inexpensive OSD solution which is tailored for use in fixed wing aircraft with an inexpensive GPS module in its default configuration. However, using the default configuration is a problem with the DIYDrones Arducopter for several reasons.

1. The OSD comes with a GPS module that is small and easy to mount but does not work well with  the MTK 3329 GPS (and the rest of the Arudcopter’s recommended electronics) operating at the same time. It is also a waste of power to operate both GPS’ at the same time.

2. The Remzibi’s firmware is closed source but configurable through Happy Killmore’s setup software.  There are limits to the configurability however. The data elements that can be enabled for screen display are fixed to specific fields within the NMEA messages coming from the GPS.  For a quadcopter, the GPS course value is not useful for display since the course is not stable in a hover. The magnetometer course is valid in a hover and therefore is the best choice. There are 2 ways to get the magnetometer value displayed (when not using the included Remzibi compass module). One  is to use the special messages in firmware 1.74 that can display arbitrary values on the screen and disable the NMEA course value for display. Another way would be to create a dummy NMEA messages and fill in the data fields with the best available parameters for the quad.

3. To integrate the special character display messages and an NMEA stream requires that one of the APMs (Arducopter’s main processor) serial ports be dedicated to format NMEA messages from the MTK 3329 GPS. The special character display messages would also be interleaved within the NMEA messages to display the magnetic course value and other desired fields such as flight mode or ham call sign. Serial 1 (usb connector and CLI) and serial 3 (telemetry) are the available ports and Mavlink is already allocated to serial 3 if a ground station is in use.  Serial 1 is dedicated to the usb connector so the only option is to interleave Mavlink and Remzibi protocol or choose one over the other.(Edit – changed this due to new information of how the FTDI goes tristate when no USB attached 8/27/2011) Port 1 is connected to an FTDI chip and the USB connector and can be used if pins are brought out from J7 on the oilpan and the USB is not connected. This also means that when the USB is connected (for firmware loading or CLI use), the connection from port 1 to the Remzibi OSD would have to be disconnected. Since Remzibi is closed source, it would seem that interleaving Mavlink and Remzibi messages which would be problematic at best (and confirmed to not work 8/27/2011). Using port 1 for Remzibi and port 3 for Mavlink would work, but requires a change to the ACM code to also output Remzibi style ASCII messages and also require care when installing new ACM firmware and using CLI mode.  Also, unless Remzibi processing was formally added to ACM (and APM) code lines, the adhoc Remzibi code would have to be added to each new ACM release and compiled to load into the Arducopter.  Choosing to run without Mavlink (and use Port 3 for Remzibi)  is also not a good option with all the capabilities of ground stations and ground based tracking antennas.

For these reasons, I thought the best solution would be to use a small separate processor to “y off” of the existing Mavlink serial output to the Xbee transmitter and process the serial stream using a Mavlink to Remzibi converter.  Mavlink is a standard on both APM and ACM and the converter can be used with future versions of ACM without recompiling ACM.

Using this approach, I create a dummy NMEA message and substitute the magnetometer heading for the GPS heading. I also decode the navigation mode (stabilize, simple, loiter,…) as a seperate field on the display. My ham call sign is displayed on the bottom left also. The following video shows the output of the converter operating in flight.

The Arduino Pro Mini is a very small board that is easy to mount near the Remzibi OSD and can process Mavlink messages and emit Remzibi format with its single serial port. The following diagram is how I wired the boards on my Arducopter. The Arduino source code is available here: osdmavlink. I used this software with Remzibi firmware 1.74. To compile this code you need to have the Arduino 22 sketchbook area contain the libraries from either the latest APM or ACM code. For use with the Arducopter, you can download the latest 2.xxx release (such as 2.039) and make sure it compiles in Arduino. Then you can compile the osdmavlink sketch in the same Arduino sketchbook area.  Make sure you restart Arduino whenever you make library changes.

Note: – Thanks to Phillip Anthony Smith for the Mavlink Ardustation firmware which became the basis of the Remzibi converter software. His software was announced in this post.

Warning – check your silk screen on the Arduino Pro mini for the Remzibi connections.  The one listed below in my connection diagram is reversed from the one on my Arducopter. The proper pins to solder to on the Arudino are marked “TX0”, “VCC”, and “GND”. Also make sure you are using the 5 volt version of the Arduino Pro Mini. The Remzibi puts out +5 volts on its GPS connecter – not 3.3 volts.

Note: The libraries distributed with versions of Arducopter 2.0.40 and later will get compilation errors due to changes in the Mavlink headers within the library. You can compile with the library contained in the Arducopter 2.0.36 source code distribution and the Mavlink OSD software will still work with Arducopter 2.0.40 to 2.0.46. I’m working on source code changes to allow compilation with the modified Mavlink libraries.
PDF of the connection diagram
OSD Configuration Bin File (be sure to rename to .bin)

APM version of osdmavlink