Based solely on that title, you can probably guess that no it’s not working yet. Tinycopter has been reduced to a case like all of my controls projects: in software limbo. Unlike mechanical things, which either work or don’t, debugging software requires me to be a bit more methodical. It’s definitely almost there though!
To get Tinycopter flying before my Hobbyking order for small ESCs arrived, I decided to chop and repackage some larger controllers. They’re the 18A Turnigy Plush common on medium sized copters.
They weigh about 20 grams or so with heavy 16ga wiring, the thick shrink wrap, and the aluminum heat spreader plate. Because I was going to use them for all of 3 amps or so, all of this was chopped.
With 20 gauge wires, thin shrink, no heat spreader, and a shortened servo cable, I got the boards down to 12 grams, which was good enough for now!
Given that the ESCs are roughly half the starting weight, I piled 2 of the stock ones onto Tinycopter to get an idea for final weight. It looks right on target – 200 or so grams with a massively oversized battery. Once the 370mAh ones arrive, it should be around 175-180 grams.
With everything fitted out, I took off the props first and began constructing the stability controller. I compartmentalized as much as I could and tested as I went along making sure every stage of the code was functioning. This pretty much took a whole day. Unlike Edgertoncopter, it wasn’t banged out quickly with inline functions and shady loop timing.
But Edgertoncopter works, and unlike Edgertoncopter, Tinycopter didn’t.
The result of the first free flight was immediate instability and explosion:
Well, at least it wasn’t as bad as the last instability resulting in explosion.
After a whole evening of prop changing, loop tuning, and optimization, Tinycopter is pretty well scarred.
And it still doesn’t fly stably – it enters a slow but increasingly divergent oscillation, almost as if something is lagging or being too slow in responding. This resulted in a few hours of tearing my hair out trying different gains.
But I know exactly why now, and I’m going to fix it first thing tomorrow. This time, I actually did the software correctly, and the real problem is far worse.
the real result of this experiment
Here, have a look at its version 1 sketch. Note that this will not fly anything yet – there are some fundamental issues in the code, but…
The real result of this whole build is that Tinycopter does not use XBypass.
As quickly as I threw together that hack, it was superceded. Tinycopter uses, instead, the pin change interrupt and timing method first outlined in the XBypass post, but augmented by commenter beak90’s code contribution. I implemented the PinChangeInt library version 1.3, and am glad to say it works extremely well. The resolution given by the built-in timer (micros()) is 4 microseconds, which is reasonable for controlling things, giving approx. 250 discrete steps in the R/C servo pulse width band.
I will probably recommend this method over pulseIn() for all but the most basic servo reads. It’s easy to set up, does not require caressing the ATmega328 manual, and works great.
The overhead introduced by my code and the PinChangeInt’s natural overhead seems to be around 25 to 30 microseconds, which… honestly, taking a 60us chunk (one falling and one rising edge for subsequent channels) out of the code periodically every 1000 to 2000 is much, much better than several tens of thousands. My control loop code seems to complete in about 900uS – I set a pin high when it starts and low again when it falls, and it forms a neat almost-50% square wave at 500Hz. It takes a while because of the dozen or so floating point operations it has to shove through.