This is the third iteration of my Ardupilot Mega to Hitec telemetry adapter. Adapter no longer requires modifications to APM itself, but instead connects to telemetry port of APM and it has a pass through connector for telemetry transmitter. I made PCB this time using SMD parts for smaller size:

It's possible to have the device automatically display different information based on airframe type. Currently shown vario and airspeed readings are not that useful for hexa, but for example heading might be. I just got my hexa so I've yet to decide what to show. Unfortunately compared to previous versions, it's not anymore possible to show "mAh used" reading since to my understanding that information is not sent in any mavlink message. When using different types of batteries, that information would be more useful than percentage remaining reading. Should we add mavlink message for it?

For more information about the device and sources, see http://antibore.wordpress.com/2013/02/28/showing-apm-telemetry-data-on-hitec-auroras-screen-3rd-edition/

Now if I only could get my hands on some different telemetry capable systems, I could try to make this adapter universal one...

Yesterday I took my new 3DR hexa outside for the first time. Weather was nice and sunny with brisk -7°c temperature. Even though everything worked well when testing, I immediately ran into problems outside. After connecting the battery all of the ESCs started beeping rapidly (two times per second) and refused to spin the motors. I took the hexa inside for a while to warm up for a while and the problem went away and everything seemed to work fine. Unfortunately as we all know, the assumption is the mother of all fuck ups.
I hovered the hexa, but each time I tried to land motors sped up suddenly and the whole thing flipped over faster than I could react. After breaking two props I started investigating further. There was a couple of helpful threads, one offering working solution to calibrate ESC at low temperature.
What I think what happened is this: Pwm value that ESC reads from APM changes a little with temperature. If we assume that lowest value in room temperature would be 1000, in -7 degrees it could be say 990. Now during calibration esc has saved value 1000 as the smallest possible value. When it reads value 990 at cold startup, it decides it’s not a valid value and refuses to start and starts to beep as a warning.
The real danger is in situation where ESC has started successfully, but the temperature goes down. At low throttle pwm value goes under the min limit and ESC turns off as a safety measure. Since not all ESCs do this at the same time, what happens during the flight is that APM tries to compensate this with other motors resulting an immediate flip.
Working solution seems to be to calibrate the ESCs at the lowest temperature you are going to fly. After doing that I had no problem flying outside. I think this would be important thing to mention in the wiki.

I thought to share with you this display mount I designed for Hitec Aurora controller for FPV flying. The part is made from single piece of aluminum and it's very compact and stable.

More pictures and cad files can be found here: http://antibore.wordpress.com/2012/12/21/display-mount-for-hitec-aurora/

In my previous post I described how to show APM telemetry data on Hitec Auroras screen. The code has now been updated to support APM2 board, though APM1 is also supported. New firmware also adds support for GPS coordinates. Only thing still not supported is GPS date and time since APM internal date format is yet to be decided.

More info here: http://antibore.wordpress.com/2012/05/10/showing-apm-telemetry-data-on-hitec-auroras-screen-revisited/

Simulated charging arrangement. Always use fireproof container for the batteries when charging!

I updated my charged to balancing one a while ago, but for some reason I didn’t buy one of those new multichargers, which pack a number of separate chargers in to one device. I use two 3S battery packs in parallel configuration on my plane and I have three sets of those. After a day of flying, charging six 3S packs separately is a long and laborious task. Since my charger can handle 6S packs, I thought why not to make an adapter cable to charge two packs at once. Since all the cells are rated the same capacity, charging 2x3S packs in essentially same than charging one 6S pack.

The following cables were build:

First adapter combines balancing leads from two packs to one connector. If you look closely, you can see that the ground wire is a little wriggly. When soldering the cable I did not think it all the way through and connected ground wires from both connectors together. When I connected the batteries, one of the ground wires vaporized with a loud pop. So be sure to leave second ground wire unconnected (pin 1 of the 2nd connector).

Second adapter is more obvious, it just connects the two packs in series. I suggest to number the battery connector which ground wire goes straight to the charger with number one and also the balancing connector which has ground wire connected as number one. These numbered connectors should be connected to same battery.

After connecting the batteries, set your charger to double voltage that the rated pack voltage (22.2v in this case) and charging current to the same as the rated charging current of the pack. It does not matter whether the packs are as empty or not, since the individual cells get balanced (although if there are big differences, balancing seems to take time at least on my charger). All that matters is that both packs have the same capacity and can handle the same charging current.

You can also make the same kind of adapters for 2S batteries, or even for the batteries more than 3S. The only limiting factor is that how many cells your charger can support at one time.

You can find schematics to adapters from my blog: http://antibore.wordpress.com/2012/02/02/charging-two-3s-li-po-packs-at-the-same-time/

I’ve been wondering, what would be the easiest way to route telemetry and commands from APM to Internet. Using 3G modem, would provide almost unlimited range (I know there has been some discussions about this in DiyDrones forum. Here in Finland the GSM network is very covering, but due the way the cellular towers are optimized, maximum altitude where the connection works is probably less than 200 m.)

In theory, list of required hardware is not long. One just needs to receive messages from APM and encapsulate them to UDP packets and send via 3G modem and vice versa. Unfortunately handling PPP communications is too large task for simple microcontrollers. I ended up using BeagleBoard for the sake of easy development and since I had one at hand. I realize that BeagleBoard (which essentially is full computer by itself) is an overkill, but it’s not very heavy and fits easily inside Maja’s fuselage. Basically any embedded system, capable of running linux and acting as an usb host would do. Maybe in the future I figure out some additional tasks for BeagleBoard to do.

The setup works quite nice now. Unfortunately I haven't been able to do much flight testing. Weather constantly sucks this winter here in Finland. As you can see I already installed skis, but there's not even snow, even though it's almost new year.

I wrote more detailed post to my blog, with link to sources: http://antibore.wordpress.com/2011/12/28/routing-apm-communications-to-internet/

I while ago I was asked to keep a small presentation about my plane in the workplace event. Here’s the slide set that I made for the presentation. Feel free to use the pictures to your own purposes, as long as you credit me.

• PDF-Slides: Maja presentation.pdf
• Keynote presentation: Maja presentation.key

Every now and then it's good to pack light and leave the laptop at home and just enjoy flying. Running out of battery at inconvenient time is however a concern of mine. I just recently finished a project to display telemetry data from APM on Aurora's screen. I'm not particularly proud of the technical side of the implementation, but this seems to work fine.

Hitec's Optima receivers interface with "Sensor station" via I2C, receiver being the master. APM has I2C-bus and it should support multiple masters, but I could never get it working reliably. My solution was to use ATMega88 to receive data via SPI from APM and relay the data to forward by answering queries send by the receiver. The circuit itself is really simple, just the avr, two resistors and a decoupling capacitor.

All the information that could be get from the sensor station are emulated from the data from APM, even including fuel meter, which tells how much mAh are remaining from the rated capacity of the battery. Only thing that I haven't implemented is GPS position and time, since they are not really useful without a map. One nice thing is that on Aurora, you can rename temp and rpm labels. I'm using rpm-1 value for mAh's used and rpm-2 for airspeed. Temp-2 is used to show the current throttle (0-100). Temp-3 and 4 are still left for some other data.

I'm really happy to get this working, since all the important data is available from transmitter screen with one glance and since the APM sends the data via xbee, this is a nice to have backup feature.

If somebody wants to use this too, I can provide sources and schematic later.

br,

Janne

I recently received my Ardupilot mega, but I could not find instructions on how to get it working on airframes like Twinstar, which have separate servos for each aileron. One related blog post here in diydrones mentioned, that feature is being implemented (although I did not find an open issue about it) but I was too impatient to wait for proper fix.

Here's my ugly fix for this:

1. Disable aileron mixing from transmitter and make connections to ardupilot as you would do on 1-servo aileron case.

2. Connect 2nd aileron servo to ardupilot output 5

3. Open ardupilot sketch in arduino ide and open "Attitude" file

4. Insert these two lines to place marked in picture:

g.rc_5.radio_out = g.channel_roll.radio_max.get() + ( -1 * (g.channel_roll.radio_out - g.channel_roll.radio_min.get()));       

APM_RC.OutputCh(CH_5, g.rc_5.radio_out); // send to Servos

5. Compile and upload

Remove "-1 *" part, if 2nd servo does not need to be reversed compared to 1st servo.

Note!

Since failsafe mux only operates on first four channels, on event of failure, 2nd aileron can't be moved.

I hope this feature will be implemented properly in the near future, but this should do at least for now and at least for me. Hope this helps others too!