I’ve been flying various incarnations of software on my almost 3 year old Arducopter and never felt comfortable enough to trust flying it by video signal alone – until now. The inertial positioning in horizontal and vertical is really good and feels rock solid under fpv. The “return home feature – rtl” is also very reliable now and I trust if I loose video signal, I can get home. I flew 12 flights totally under fpv the weekend of 7/13/2013 and had great success. I invoked multiple rtls – at least one every flight and a total of 15 or so over the weekend. I was also using a beta iPhone app to watch flight values and battery condition with voice warnings of low battery etc. Here is video of one of the flights at my in-law’s farm:
Tag Archives: Arducopter
Ardustation 2 2.0.18 Released – Adds Low Aircraft Battery Voltage Warning
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.
New Version of Ardustation 2 – 2.0.17 Compatible with Arducopter 2.9.1
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.
The software is available at the usual spot:
Ardustation II Google Code Repository
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.
New Ardustation 2 2.0.15 Mavlink 1.0 Support
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.
Modified Ardustation 2 Software Now Available
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
My EEWeb (Electrical Engineering Community) Featured Engineer Interview
Thanks to EEWeb for posting my featured engineer interview.
Using a Remzibi OSD with Arducopter 2.0.x Beta, Ardupilot Beta and Mavlink
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)
My Arducopter GPS Hold Issue – MediaTek MT3329 GPS resetting in cold weather
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):
My New Arducopter
A great flying quad-copter:
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.