I bet everyone forgot about this thing!
I almost did, anyway. After the last test some time in July ended in one fan cracking its motor mount, fortunately not resulting in catastrophic failure, I lost my enthusiasm for flying objects and literally hid it under my cart of parts and stuff – as in, it fit perfectly between the wheels. I pledged that one day I will once again have a quadrotor boner and return to finish it off, since I did have a spare fan and all.
Well, I figured Thanksgiving weekend was as good as any. This year, MITERS seems to have accumulated a fair number of freshmen and newbies with quadrotors (and trirotors). The pressure was on to just finish it once and for all. It was a roughly 1 hour job to pull the damaged fan casing out and mount the spare, including printing a replacement tailcone.
noise isolation
During the testing of the Z-axis yaw rate control loop last time, I noticed a fair amount of mechanical noise coupling into the gyro readings. The gyros are mounted facing the same axis as the fans, almost in plane with them, and essentially on the end of a long carbon fiber stick. While the filtered readings were clean with stationary fans, they would become very erratic as soon as any power was applied. This was clearly visible in the test videos where the fans are jiggling quickly almost like they’re loose. The noise was of the same order of magnitude as the signal I was trying to get from the gyro – as a result, the filtering was not very effective. That was number one thing I was out to address before I moved onto the other axes of control.
I elected to remount the center Arduino Nano carrier board using memory foam – a tip I picked up from tricopter-nick, which is in fairly wide use.
With all 4 fans functional again, I was able to find out that the noise coupling was significantly lessened. It was still causing some trouble, but only when fan speeds were significantly higher than before – the “barely-touching-the-ground-hover” was mostly erratic jitter-free. Refactoring the yaw rate control code to not pre-scale the gyro readings also made the control less granular (and consequently even less shaky), and I also implemented a 2nd-order filter instead of a 1st-order. As a result, I was able to increase the loop PI gains by 2 times to yield a faster response to stick inputs. A little bit more driving on the ground like a doped-up robot on ice confirmed that the updates worked.
So now I was at the same external functionality I was 4 months ago. Yippee.
The only way I could get more data and test if the filtering and shock mount actually mattered was by continuing with the rest of the stability code.
how i killed the giant quadrotor
I hit the reset button on the Arduino. Actually, to be more specific, I left the controller calibration code in and then absentmindedly hit the reset button on the Arduino.
On occasion, I’d notice the fans peg off to one side and not respond to rudder stick inputs. They would some times recover again, but usually it required a power cycle to fix. I have a sneaking suspicion that my 2.4Ghz FHSS transmitter and the 2.4Ghz FHSS Xbee modules I had as a data link were Frequency Hopping over eachother’s Spread Spectrum at times. Regardless, my usual rigorous procedure is to completely power down the electronics and then restart them.
The number one mistake was not commenting the calibration code out after the first time. After I temporarily decommissioned it the first time in july, I had “borrowed” one of the Turnigy 100A controllers for melonscooter. With melonscooter having moved onto greener melon vine patches, I returned that controller to quadrotor duty, but it had to be recalibrated again.
The calibration procedure for these R/C controllers is full-stick within 1-2 seconds of powerup (2000uS pulse width), hold, then neutral stick (1000 or 1500uS, depending on your type of stick). This has to be done within 2 seconds of powerup, or else the ESC initializes and waits for command. The problem is when 2000uS is commanded after the ESC is already on and initialized, that means gun it.
For reasons I can only explain as “meh”, I elected after testing the yaw rate controller for the last time and seeing it lock up to just hit Reset on the Arduino to clear all the readings and start over, without powering down the ESCs. About 1 second after I did so, the stunning realization of idiocy hit me – along with the entire thing.
I only really remember leaping back as it flew upwards and sideways towards my head – keep in mind stabilization code wasn’t even written yet – and batting it out of the air with my left arm before ducking and turning around. It did a powered somersault over my head and crash-landed on top of a substantially more solid vehicle, and consequently shattered into many pieces.
It took me a second or two to realize what had happened, upon which I leapt for the big red key switches of main battery disconnection. The two remaining fans were still spinning – a consequence of me knocking over the radio – but luckily only slowly.
Pieces of fans were being collected from across the room afterwards – this destroyed rotor was found a few feet away with motor still attached.
I didn’t escape without damage. Batting the Deathcopter from the sky, I was grazed by what must have been a ducted fan leading edge:
In what is probably the luckiest near-miss I’ve ever been in, I’m only missing about 3 square inches of skin from my left forearm where the fan scraped it off. There’s 3 very evenly spaced cuts where I presume a rotor dinged me while disintegrating, but none were deep. Bleeding was slight, so the damage was cleaned, bandaged up, and ice-packed. It could have gone way more wrong in many possible alternate scenarios. I’m still periodically testing my left hand fingers and wrist for full motion just in case.
What’s the lesson for other quadrotor builders who use RC controllers?
Well, besides don’t be a total dumbass and violate your own safety procedure,
calibrate the motor controllers once and cross it out of your code after.
This accident was totally avoidable if I wasn’t trying to rush to get to writing the stability controller.
Nevertheless, with 2 fans completely destroyed and the other two now in unknown condition possibly with structural damage, and the frame in many pieces, I think this project is done. Maybe I will instead concentrate on other flying things, or maybe I’ll build a more normal quadrotor or a tiny and cute one I can swat without worry.
Get well soon, and don’t give up on flying vehicles — I am still looking forward to your ekranoplan :)
Unfortunate way to end it. I hate to hear that it hurt you, luckily not too bad. I love the blog and finally, !!!Ballcopter!!! you did it once. Make us proud! Either way thanks for sharing.
Hmm, interesting to think about how to safely test one of these things. The easiest way I can think of is to get some rope and tie it in a couple spots to something large enough that there’s no chance in hell the quadrotor can lift it, but with enough slack that it can still move up like a foot or so. That should at least make it fairly easy to dodge in case anything bad happens.
Bwahahahaa. I get amusement from your pain. :D