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.