Category: sad project pile

probably dead or dead inside

The Decommissioning of the Quadrotor Project

chorl4 Comments

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.

The Once and Future Ballcopter

chorl4 Comments

First off, some minor updates on the not-Land-Bear-Shark (a.k.a the quadrotor, deathcopter, and myriad other pet names I and my peers have assigned to it). I’ve tuned the Z-axis rate controller some more such that now the yaw rate is much more controlled and the servos less twitchy. Powering those fans on injects massive amounts of mechanical noise into the sensors, so much that I’ve begun to consider coding more robust discrete-time filters in the software to target the vibrational frequencies that the fans so readily emit. I was ready to move onto testing the pitch and roll control software, though, when the problem suddenly became a little less virtual:

Oh boy. When you hear the scratchy-fan sound and look up to see a fan rotor hanging halfway out of the duct, it’s time to stop hovering. I guess this is why cheap ducted fans are cheap.

The entire motor mounting face seemed to have broken off; luckily the motor was held in by its power leads, otherwise there would probably be a hole in the ceiling somewhere. I’m not sure what plastic the casing of the fan is made of, but it does seem quite brittle. With the motor mounting face being the focal point of all the stresses the fan rotor imparts on the system, any manufacturing defect (like voids or local shrinkage) or increased loads (like from an off-balance rotor) would make the area prone to failure.

This fan is the most unbalanced of the entire set that had their shafts replaced, so I’m not surprised it was the first to go. However, it’s still a bummer – luckily only $40 lost and not $400 (then again, perhaps a better made fan would have never failed or been off balance). Otherwise, it’s also a hassle to have to replace the whole thing – the rotor is also well-trashed by being ground against the housing at a few thousand RPM. Fortunately, I have a spare (the very first one tested, in fact).

Now, I naturally gravitate away from projects as they enter the software-only stage. During the coding of the yaw controller, I was also thinking of distractions to embark on so I have an excuse to not write code. With this thing temporarily out of mechanical service now, I’m going to take a little break to recharge my code-monkey-pacitor with a project that only requires more software.

I knew I couldn’t leave Ballcopter alone for long. Despite its parts now having taken two and a half weeks to get back to the East Coast (still having not managed it as of right now… seriously, USPS?), I do have enough parts back here at base to independently build version two. Not that I would want to do that, since I did order an entire new radio for the thing…

So what’s different about BallCopterTwo? Hopefully it will be 1000% less terrible. What ultimately failed on the first design was my complete failure at creating control surface linkages. Airplane parts and building methods are still weird to me, which is part of the reason why Chuckranoplan hasn’t moved much from where it was in May. For the new design, I had intended to move to 8 independent, direct-driven flaps, mixed in software, such that there were no linkages involved, but figured that would negatively impact the vehicle weight. However, it took a new video of the original Japanese ball drone design for me to seriously pursue the 8-servo route. Here’s a screencap from the video.

Those sneaky bastards. Well, you can only get spiral deflection of the flaps like that if each one is actually independently driven. Two can play at that game:

Other changes to the version 1 design are a sleeker center column thing which should reduce weight even more and control flaps that aren’t way oversized. Because processing 4 channels of radio control into 8 servo channels needs software, I’ll probably whip up a quick board that carries an Arduino Nano and an IMU module – basically a condensed version of what’s on the quadrotor, stripped to the bare necessities. As long as I have a microcontroller onboard, it will be gyro-stabilized using the gyros on the IMU – I have plenty of practice now from making the quadrotor yaw controller.


Remember kids, don’t cut foamcore on the laser cutter.