I’ve been continuing to use my Remzibi OSD with my Arductoper quad and ACM version 2.7.3. I haven’t released this software in a while for the few who may still be wanting to use Remzibi OSD so I’m attaching the software to this post. This is the source code for the converter and needs to be compiled with Arduino 1.0.1.
Here is a link to the original article. Mavlink to Remzibi Howto
I’ve just uploaded the latest Ardustation 2 release – 2.0.15 which adds Mavlink 1.0 support. This is to support the upcoming releases of ACM and APM with Mavlink 1.0. You can still use this release with Mavlink 0.9 by commenting out the “#define MAVLINK10” statement in the main ardustation2.pde file.
This version will also warn you if it detects the wrong Mavlink heartbeat being transmitted. Ardustation 2.0.15 will display an error message on the LCD when it detects the wrong heartbeat and direct you recompile with the opposite state of the #define MAVLINK10 statement. The start up message displayed on the LCD will indicate if you have compiled for Mavlink 1.0 or Mavlink 0.9.
I’ve have tested Mavlink 1.0 with ACM 2.6 Gamma, APM 2.4 (with Mavlnk 1.0 enabled) and with the Mavlink 1.0 version of the Mission Planner.
As always, please let me kinow if you have any issues with this release.
http://code.google.com/p/ardustation-ii/downloads/list
and is also available in my git clone here:
http://code.google.com/r/hrpull-ardustationii/source/checkout
and you will need a git client to pull the clone down.
has my updated blog post.
I’ve updated the Ardustation 2 source code to allow compilation with Arduino 1.0 Relax and the latest libraries for ACM 2.5.3 and APM 2.3.0. This update also includes a modification of parameter names for PID editing that match ACM and APM. The updated version is 2.0.12.
The download zip file also includes the libraries used to verify compilation of the software. The software has been lightly tested with ACM and 2.5.3 and has not been tested with APM 2.3.0. If you find any issues feel free to comment here or post an issue at the Ardustation 2 Google
The software is available here:
http://code.google.com/p/ardustation-ii/downloads/list
Download 2.0.12 for ACM 2.5.3 or APM 2.3.0 – compile with Arduino 1.0 Relax
Download 2.0.11 for ACM 2.0.48 or APM 2.24 – compile with Arduino 0022 Relax
Thanks to EEWeb for posting my featured engineer interview.
I was listed as site of the day on www.eeweb.com. Here is the link:
My site of the day post
Some FPV video from my quad and fixed wing EasyStar
(volume is a bit loud on both videos)
Quadcopter FPV video with on screen video symbology and a little flip at the end
EasyStar FPV video with a crash at the end
Thanks EEWEB!
My Arducopter has a 1.280 Ghz video transmitter and camera for sending live video down to a groundstation. Initially I used a fixed ground antenna to match an onboard dipole transmitter antenna and found that multipath was a severe problem when flying in an area with many structures. The ground antenna is a high gain patch and isolates the multipath if it is pointed directly at the Arducopter in flight. Having seen tilt/pan antennas for FPV and UAVs on the Internet, I started looking for a inexpensive solution that could use the datalink transmitted GPS location information to point my high gain patch at the quad during flight. My search led me to an inexpensive tilt/pan antenna system from readymaderc.com:
Antenna Pan/Tilt for EagleEyes Antenna Tracker
This tilt/pan assembly comes by default with Hitec HS-485HB servos which have enough torque to operate my patch antenna and video receiver. Once installed, the servos are geared to operate from 0 to 90 degrees in tilt and 360 degrees of pan. One disadvantage is that the assembly must rotate a full 360 degrees when exceeding the stop in either direction although this happens very quickly in my experience.
To operate the Tilt/Pan assembly, I have modified Phillip Anthony Smith’s Mavlink Ardustation software to include tilt/pan commands driven by received Mavlink GPS position. RAM is very tight in the code and is focused on APM, but I manged to add a few new screens to output tilt/pan info and set/display home information for the antenna location. I had to remove APM pid modification screens to make my changes fit in RAM. This is problematic if you want a complete replacement for a ground station, but it was not a problem for me since I also use a second Xbee with a notebook to monitor the Arducopter. I just use the Ardustation for antenna positioning. I’ve also added code to position the location of the pan stop to the least obtrusive position at the flying site. The following video shows the readmaderc.com antenna tracker in operation and some tips for using the software. The software can be downloaded here for others to modify or use as they see fit.
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 Ardustation 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.
A new version has been released that fully supports Arducopter and ArduPlane, parameter editing, antenna tracking, and autodetection of which platform is connected. This version also compiles with the latest libraries in ArduPlane 2.24 and Arducopter 2.0.48/49. The latest Ardustation 2 software is 2.0.11.
New development and fixes for source here
Original ArdustationPSTilt/Pan Arduino Source
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)
I found this today cleaning up the basement. This is an audio cassette shipped by MITS in 1977 containing an FSK version of Altair (Microsoft) 4K BASIC for the Altair 8800 computer. My Dad and I built our Altair in 1975 and finally got enough memory (5K) to run BASIC. We used the Altair ACR board hooked up to a cassette tape recorder to load the software. The cassette was also shipped with a snippet of ASR-33 paper proving that this cassette loaded on an ALTAIR- along with a statement of free memory. I wish I still had the snippet – but it most likely has been lost to the ages. The back side of the cassette has hand written 125/256 so I suspect this was a batch of 256 cassettes. There were apparently earlier versions since this is listed as version 4.0.
I ordered a new MTK 3329 GPS module and tested last weekend on my Arducopter. The new one works fine in the cold – no more resets back to NMEA. Very strange issue on my original MTK.
I’ve been flight testing my Arducopter since Christmas with excellent flight performance (RC2 firmware) but mixed results for the Gps hold function. I finally tracked the issue down to my MTK GPS resetting itself while running the September firmware when it is cold. The GPS runs great indoors as verified in my XBEE serial monitor using the “4” selection, but would stop reporting a position (TOD stops updating) a few minutes after I was flying in cold weather (20 degree F). I used my USBEE logic analyzer to figure out what was going on and I see the proprietary binary protocol change to the default NMEA protocol when I place the Arducopter outdoors.
The LA showed the output in proprietary format at a 5 Hz rate stopping for 2 seconds and then a $PGMOD message with the default NMEA output resuming just after. The blue light on the MTK carrier board maintains a solid blue light through the reset which was fooling me when trying to test the GPS hold in flight. I checked the 5 volt power going to the GPS when the event happens and everything is fine so it seems my MTK is temperature sensitive.
My MediaTek is an older one (purchased in late Summer 2010) with a coin battery on the back and I’ve ordered a new one. I just wanted to give a heads up to others since the the switch back to NMEA was so weird when trying to get the GPS hold to work.
Here is the USBEE screeen capture showing the serial port messages changing to the default message format during the MTK reset, the left packets are the proprietary messages at 200 msecs, then a pause, a reset message, and then NMEA packets. (Love the USBEE by the way):
