I’ve been working on the Ardustation 2 software since August 2011 and I’ve finally gotten around to adding a feature that has been asked for more than once: a buzzer warning when the received Mavlink aircraft battery voltage has dropped at or below a set value. The buzzer is sounded ( at LCD screen updates – 1 Hz) when the voltage is at or below the set warning value while the “flight data” screen is displayed (see below).
Switching to another screen will silence the buzzer until the flight data screen is brought back up. I wanted a way to silence the buzzer if necessary and this mechanism turned out to be the simplest way to implement it – given the need for an interrupt driven buzzer timer. All other features of version 2.0.17 are intact (antenna tracking, parameter update).
I had a chance to test fly 2.9.1 on my Arducopter over the Easter weekend and this worked pretty well to keep my 4000 mah 3S Lipos from exceeding the use of 80% of the batteries capacity. Using a HobbyKing 3S voltage warning was killing the life of my batteries. After 12 flights trying to slowly increase the flight times vs battery remaining capacity, I settled at a warning at 10.6 volts (my quad’s current drawn is about 20 amps at a hover) and that is the default in the software. I have another 2 minutes of flight time to land after the buzzer continously sounds and I’m happy that I’m not puffing my Lipos anymore. This can be easily changed to other values in the source code before loading into the Ardustation.
My Ardustation has served me well over the last 2 years and I don’t anticipate adding any other features since RAM and screen real estate is very tight. Thanks to everyone who has downloaded the software and provided feature requests and comments and to the code contributors who have worked on Ardustation 2.
As always, the software is available at this link. Be sure to test this with your aircraft on the ground to verify that you understand the behavior and its limitation. I’ve only tested the voltage monitor with my quad – although it should work with airplanes also.
Compile this code only with the library contained within the zip file. The libraries provided with APM or ACM source code have changes that will cause compilation errors. This code can be compiled with Arduino 1.0.1 or 1.0.3.
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)
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 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):
I’m having some trouble with the MTK GPS and the winter weather in St. Louis, but otherwise, this is the best flying copter I’ve ever had. It has a GPS/barometric pressure/sonar rangefinder driven autopilot that will be able to fly waypoints and come home on command. I’m working now on a tilt/pan video camera transmitted to the ground and commands on a bidirectional data link (XBEE). Highly recommended and available at: DIY Drones.
This is video from last September of my first Ardupilot test. To keep the first test simple, I modified the software configuration to fly a simple fixed heading of 45 degrees when I engage the autopilot from the R/C unit. This worked very well for a while until the last attempt, when something glitched in the software/GPS and commanded a dive into the ground into one of the few trees in the field. The end of the video shows several frames of video as the pieces were stripped off the airplane by the tree. All the electronics survived the crash and I’m rebuilding a new airframe to test in the Spring.
I’ve been working on the Ardustation 2 software since August 2011 and I’ve finally gotten around to adding a feature that has been asked for more than once: a buzzer warning when the received Mavlink aircraft battery voltage has dropped at or below a set value. The buzzer is sounded ( at LCD screen updates – 1 Hz) when the voltage is at or below the set warning value while the “flight data” screen is displayed (see below).
