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.
This release is for Mavlink changes in ACM 2.9.1. The message location of the number of GPS satellites has been changed for ACM. Ardustation II 2.0.16 will display 0 GPS satellites with 2.9.1.
I’ve also added an additional antenna range/bearing as suggested by James Masterman. He reported antenna pointing issues at long ranges at his location in Australia. This algorithm seemed to fix his problem. I’ve tested both algorithms using a simulation and the results seem to be very close. I’ve left the default algorithm originally provided by 3DR but you can select the alternate algorithm by pressing the center button on the pad while on the antenna range/bearing display. The display will show ALG 1 for the new algorithm and ALG 0 for the old.
I’ve tested the software with my quad on ACM 2.9.1 and an APM 2.5. I have not tested this software with Arduplane 2.7, but I expect it to still work and appreciate any reports of problems by users.
Please be sure to download the zip file to a empty folder and to only use the library folder contained in the distribution. Do not merge this library folder with either the ACM or APM library folders. This software should be compiled with Arduino 1.0.3 or Arduino 1.0.1. Do not use the earlier versions as indicated in the Ardustation wiki.
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.
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.
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
Arducopter, Ardustation, and readymaderc.com Tilt/Pan Antenna
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:
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.
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’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).
