Receiver v3 sketching

In the end of my last post I mentioned that I was working on yet another revision of my receiver. The main reasons being the lack of hardware PWM support in the v2 revision as well as the difficulty of making the boards for a v2. Receiver v2 was designed for DIY manufacture of the PCB, which meant that it had to be possible to build without plated vias. This then meant that I couldn't have vias under components, and again that the boards had to be relatively large. To combat the boards becoming excessively big, I decided to split it to a two board design. This was a huge improvement on the v1 though, which was a three board design.

The biggest issue in the v3 is the hardware PWM. The processor used in v2 (the Atmel ATMEGA168) has only two hardware PWM channels capable of reasonable resolution servo pulses. This is the reason why v2 does the servo updates with bit-banging in software. Now, I could've just gone with some other processor which has at least eight reasonable PWM channels. However, as the ATMEGAx8 family of processors have worked well and since I'm quite familiar with them, I wanted to find a solution which allowed me to continue using them in the receiver.

As I am clearly exceeding the capabilities of the ATMEGAx8 processors, I do in fact need a new IC on the board. I was planning on using just a simple cheap analog multiplexer, namely the venerable 4051, which is a 1-to-8 bidirectional analog mux and costs around 0.20 €. As a servo pulse is high for a period of 1-2 ms every 20 ms and low the rest of the time, I can multiplex multiple servo channels on a single 16 bit hardware PWM channel. The idea is that while one channel is outputting its pulse, the other channels are at their low state. This is very similar to the pulse position modulation used in old analog RC transmitters and receivers.

Outputting 8 channels gives me 2.5 ms (= 20 ms/8) per channel. In other words, each channel has 2 ms time allocated for the actual pulse + 0.5 ms setup time. During the half millisecond we just need to run an ISR, which selects a new channel on the mux and loads the appropriate pulse width for it. It is a simple thing to do with a huge amount of time to do it. This means that the servo update requires almost no CPU time. Also, by adding a second mux and using the second 16 bit hardware PWM channel, I could trivially get up to 16 channels. 

The board is not really that big of an issue. Companies like ITead Studio provide PCB prototyping services, which give you 10 boards for 10 dollars. For that price it really doesn't make sense to do inferior quality boards at home. Of course I only need two or three boards, but it's still quite a reasonable price for those. The size limitation for the cheap boards is 5x5 cm, which should be easily achieved as the v2 boards already fit the limit. The multiplexer takes some additional space, but I'm confident the space saved by being able to use a more efficient board layout will more than pay it back.

I'm still alive!

It's been a long time since my last post. After becoming a father, it has been increasingly difficult to find the time to continue with my RC hobby. In fact, I've gone flying only a perhaps half a dozen times after my last post.

Plane lost

In my last post I talked about the possibility of implementing an autopilot in my receiver using the AHRS I've been working on. I implemented the autopilot as described in the last post, and tried it out for the first time in December. It didn't seem to work, as the plane would always just turn away and fly west when the autopilot was engaged. I was almost coming in for a landing, when disaster struck. I guess the melting snow shorted out the SPI lines, through which the processor and radio talk. This left me without control, which in turn caused the receiver to go into fail-safe. In this case it meant activating the autopilot. So the plane turned west, flew over a small forest and crashed somewhere. We searched for a couple of hours, but couldn't find the plane.

It wasn't until April this year, after the snow had melted, that some people walking in the woods found my plane and contacted me. The plane was in surprisingly good shape, considering it spent most of the winter outdoors. All the larger mechanical parts were intact, even the propeller wasn't damaged. Two servos were dead, both showing signs of overheating with melted plastic gears inside. I suspect the control surfaces got stuck against something, and the servos were stalling until the battery ran dry. Damage was also caused to the small 808 #11 keychain camera I had on board. It had its USB port ripped out, perhaps due a yank on the power cable as the plane hit a tree. The memory card in the camera was undamaged though. The only other casualty in the end was the flight battery.

I carefully washed and dehumidified all the electronics I had on board, and to my surprise all of  them came back to life. In the future, I plan to put a conformal coating on all of my electronics. This should not only protect against glitches due to water seeping in, but also prevent corrosion in the case the electronics do have to spend some time exposed to the elements.

I put the video from the camera on YouTube: two last minutes of the flight and whole flight with telemetry.

Air crash investigation

So the primary cause of the crash was the lost radio connection, and I could deduce that the problem was at the plane end. But why didn't the autopilot work? Why did the plane fly west? I suspected a programming error, so I started going through the autopilot code. However, I couldn't find any problems there. I soon realized that the telemetry I had recorded on my laptop before the radio failure, contained most of the parameters the autopilot based its decisions on. The only parameters it didn't include were the home coordinates the plane was flying toward.

I set up a simulation. I took a guess that the home coordinates were the first coordinates the telemetry contained. This is how the code should have worked. The first valid GPS fix after power on was supposed to be set as the home location. In the simulation it turned out, that the recorded roll angles were completely different from the target roll angles the simulated autopilot was producing. This was initially very strange.

When flying, I had noticed the autopilot caused the plane always to head west. So I tried simulating the autopilot output using home coordinates that were set a kilometer west from the flying site. This time the output matched the recorded values very well, and it became clear that the autopilot was working correctly, but it just didn't know where home was. I still didn't understand how the home coordinates could have been wrong. The code that set them seemed trivial, and it didn't seem very likely that the problem was there.

Since I didn't have a second set of hardware, it wasn't until I got the plane back, that I could connect a debugger to the system to figure out what was wrong with setting the home coordinates. It turned out that the problem was indeed not with the autopilot, but with the AHRS board. Due to a small bug, invalid GPS data was fed to the autopilot and labeled as valid. The autopilot would then sometimes take the invalid data and set it as the home coordinates. The plane would then of course try to fly to the fictional coordinates of something like one million degrees northern latitude and one billion degrees western longitude.

Now what?

The problems above are now all taken care of, and yesterday I finally flew the first quasi-successful test flight. It seems the autopilot still requires some tweaking of the controller parameters, as it sometimes goes into a catastrophic oscillation.

I'm also in the process of developing a new receiver. There are mainly two reasons for this:

1. Currently used software-only servo updates are inaccurate (3us resolution at best) and prone to jitter. The new version will have support for 8 hardware PWM channels at 0.13us resolution and (hopefully) negligible jitter. This will come at the expense of a multiplexer IC.
2. The current board is designed for DIY PCB manufacturing, which makes it quite large at 5cm x 2.5cm, and is a two-board design. The new version will be a small single board design, which I will order professionally made from ITead Studio.

I hope to write more on this new receiver quite soon.