Archive for the 'Ballcopter' Category

 

Return to the Copters: Global Flying Things Update

Jun 19, 2012 in Ballcopter, Chibicopter, Project Build Reports, Tinycopter

Whoa, this site still exists.

I’ve been primarily working on a Silly Media Lab Vehicle project for the past 2 weeks or so, in the spirit of me having done so during all 4 years of my undergraduate career, which is why I haven’t been posting anything. It was actually kind of refreshing to work on a silly vehicle for someone else again. Since it’s not really my project to publicly expose all the fun innards, I’ll refrain from doing so for now. It’s not that fancy, however.

Anyways, with that project squared away for now, I’m gonna take a bit of time off… by returning to my rag-tag fleet of flying things. Whatever happened to Chibicopter anyway? The last update on that was like… mid-April. So it’s on first:

Chibicopter

Chibicopter was the project I settled on to complete for the Media Lab’s DIY Manufacturing class. Admittedly, as I usually tend to do, I treated the project far more as a personal project than a means to take the class seriously, and this was reflected in the reviews I received at the end of the class.  I ended up half-assing or straight up skipping several of the assignments at the beginning because I was far more interested in seeing it work. If anything, having to do it for class made me take it less seriously – it’s an interesting psychological effect that I see in many project based classes at MIT, where once your own stake is reduced in the project, you begin turning away from it or needing to push yourself through it.

Seeing several of my undergrad peers push themselves through the same project classes this past year that I went through (namely 6.115 and 6.131) with high aspirations at the beginning of the final project push made me realize one of those everything-in-moderation things: that if you try to do an epic project for a class, you probably will end up getting sick of it at the end, because the agenda is no longer fully yours to keep. My 6.115 and 6.131 projects were rather tame in scope by comparison, and my most “epic” class project, Segfault, was actually 90% done already by the time the class started, and I pretty much only built the analog PI controller.

But that’s besides the point. The real point is that Chibicopter is gonna need alot of rethinking before it will actually fly.

Here’s essentially what it ended up as:

Previously, I had appended a FTDI header for easier (okay, possible) programming – never really having explore the wireless bootloading any further. I’m also unhappy about going with XBee control now, because it limits the command input interface to something which can talk to an XBee – which i took care of with XBYPASS this time around, but that’s unrealistic for a product or even for my own amusement in the future since it involves two $20 pieces of hardware (XBees are expensive!). And then, in the middle of term, Hobbyking, as always, came out with a solution to my problems:

Well then.

This thing seems to work fairly well – it acts as a WiFi access point, so you literally connect to its network and transmit packets with an IP socket. It already had its data format decyphered, and another enterprising MITERS member therefore wrote an iPad app which used the iPad’s internal accelerometer to control a quadrotor using tilt alone (the stock Hobbyking provided app using virtual touchscreen joysticks which were kind of annoying to use). So really if I were to revamp Chibicopter (for another product design class?) I would just lob one of these things on it.

Feeding control inputs to it was never really the hard part. I had feared that the system dynamics of Chibicopter, being so tiny, will be faster than what I could stably control with only 50Hz command refresh rates (the servo pulse repetition rate). As a result, I “overclocked” the Arduino servo library to 100hz, the maximum speed that it can do with 4 servos.

The reason it’s limited is because the servo library starts each pulse sequentially – one has to finish before the other starts. Other approaches such as the KK Multicopter controller (which Hobbyking has a version of and which most of the MITERcopters use) start all the pulses at once and end them according to desired pulse length. This is how they achieve up to 495 Hz control – a 2000us pulse has a frequency of 500Hz, and a very small dead time is used between pulses. It’s a more complex approach and needs two timers on the ATMega chips, so you pretty much only have to be making a flight controller for it to make sense – maybe not a general-use Servo library.

I think 100hz is fast enough for Chibicopter, but the rest of the problem was mechanical. The arms are really floppy – Shapeways’ “White, Strong, and Flexible” sintered nylon is really all three of them. The props are also not very balanced, and because they are so small, were hard to balance. As a result, Chibicopter tended to resonate strongly, which was most likely overwhelming my IMU.

Oh, did I mention I soldered the IMU directly to the board, which is mounted directly to the frame? From past copter experience, I really should have seen this coming as very bad news from the start. Even worse was that it was soldered at one end so it was really its own stiff pendulum – if there is one thing your inertial measurement unit should not have, is its very own not-very-inertial dynamics.

Basically, what it comes down to is needing to totally redesign the thing for easier communication, more stiffness, and higher bandwidth. The final “test video” has already been out for a while – I got it to a condition which I was satisfied with for now in time for the end of term:

As can be seen, it’s pretty much fundamentally unstable at the moment, tending towards divergent oscillations. But it’s very cute while doing so.

I might not rebuild Chibicopter immediately, but when I do so again, I think it will move towards an all-PCB construction like the other very small copters that exist now. I’ve purchased a different style of motor which has real mounting holes (not like the mounting sticks of the 2 gram HXT motors).

tinycopter

Poor tinycopter.

Tinycopter has actually been remarkably reliable, though in various states of disrepair, since its last update in February. It doesn’t have much test video past that unfortunate first video because I would usually just fly it around without thinking about it. It’s been to several demo events since then, and is very stable and easy to fly.

One of the things I wanted to change about the design was the fact that the entire board was sitting on a giant block of memory foam. This seemed to be a great idea until the foam started disintegrating where I had glued it to the frame. I had to compensate by adding more CA glue, so eventually the foam became a stiff block in places. Usually you’d put just the IMU on foam or other shock-mounting substance. Another undesirable trait of the foam block was that if I crashed for any reason, the whole thing might shift angularly because one bundle of wires was pressing on a corner more, or something, the end result being that Tinycopter never really flies the same way twice. It was a bit unpredictable and the trim angles changed constantly.

Near the end of term, it was also starting to fall apart – the glue joint on the crossed Lincoln-log carbon fiber rod frame was coming apart, I had broken off one of the standoff landing legs, and one of the motors was temperamental. So I decided to rebuild the frame this past week and roll up all of the changes I wanted to make.

I decided to construct the frame using 3D printed joists for carbon fiber tubes (heeeeeeeeeey, that reminds me of something). The center cross piece holds the long tube and two short ones in an X shape, and allows me to clamp tightly on them with bolts. The outer ‘landing legs’ are intended to bolt through the motors’ mounting flange and use it as a giant meta-washer.

Here’s the frame fitted together, without any other hardware yet. I’m hoping this build isn’t going to be heavier than the current one – while the 3DP plastic adds a bit of weight, there are many other places on the current iteration which can afford to lose some. I ordered smaller (6A) controllers which will save a gram or two each, and alot of the big servo cable wiring will disappear, as will the chunk of dense foam.

Beginning the decommissioning of the old frame…

I decided to go for a more integrated wiring approach this time. Underneath the board is a ring of wiring that distributes battery voltage to the four controllers, with the control electronics in the middle. The IMU is now on a little block of foam (which has been made into a “foam flexure” through selective cutting, not really visible in the picture). It will be wired using tiny 30ga wirewrapping wire to further isolate it from vibrations.

Signal side wiring complete and board installed… See that there’s only one connector for each controller?

That’s why. I put the power and R/C signal wires next to eachother on a header so I can keep the wire lengths short and have one thing to plug in. The ESCs are of a much better form factor this time, and mount cleanly on the sides of the frame, secured with a zip tie through the board mounting standoff slots. The motor wires exit at the place they are needed.

I like this arrangement alot – pretty much only full integration of the ESCs onto the board is better for wiring cleanliness, but if I do that, then Tinycopter becomes a 5pcb.

And it’s back! Now with landing lights!

Besides accidentally wiring the motors up sideways (rotationally confusing which motor was which), I had to do relatively little tuning to get it flying again, since the hardware is pretty much the same. The gains were turned up some, since these ESCs appear to exhibit much better linearity than the previous ones.

Now to remember to take more video before I blow it up again – I’ve already succeeded in busting off all 4 landing leg things at least once each (but don’t worry, they are both gluable and easily remakeable!)

ballcopter?

I’m getting an urge to try this thing again. The previous attempts ended in dismal failurenearly a year ago (what actually happened at the end of that post was it not working at all and then biting Shane’s finger). These things are probably being mass produced by Sony now, or something, and have been built many times by other model hobbyists. But I still want to try my hand at it since I haven’t been able to produce a working one yet.

Since last year, I’ve figured out that my control approach was incorrect. I was trying to control the angle of tilt of the thing using the upper flaps. Really angle is controlled by the lower flaps and the upper set is used for translation. All flaps are used for rotation. It came to me that this was the proper method after I watched one of Ryan’s Giant 3D Foamies do a… I don’t know what you call it, but statically hover point straight up, like an airplane burnout – something planes should not be doing, but anyway.


Excuse the…uhhh…. bloodstain?

The ballcopter is exactly a small plane, flying straight up hard enough to offset its own weight, in a little hamster ball. Like how planes pitch up and down with the elevators on the tail, so ballcopters tilt and roll using their lower flaps. A ballcopter flying horizontally should reduce to the case of two orthogonal little planes.

I still have like 20 square feet of foamcore, so I might just go for trying the old design again with my New and Improved Control Solution. I’ve been recently more favoring carbon fiber hoops for a frame with 3D printed joists

and one more thing

No, that’s not actually a Cinestar 8.

In the Interest of Future Flying Objects: XBypass

Dec 30, 2011 in Ballcopter, Emergency Quadrotor, Project Build Reports, Reference Posts

Despite losing the Spruce Goose of Quadrotors to an unfortunate semi-controlled flight into terrain where I was the terrain (from which I’m still recovering… the square area of skin has recovered by more than 75%), I haven’t quite given up on the prospect of building a flying thing yet – but for now, they will be smaller and more easily batted from the sky. For instance, I’ve figured out why Ballcopter never worked properly. The very last update left it in a state of limbo, which I can sum up in one sentence: No, it didn’t work, but more on that later.

Eventually, Ballcopter was scrapped as its foam structure was slowly eroded away by virtue of existing in MITERS.

But there will be a day.

In the mean time, I wanted to satisfy one of my persistent self-stabilizing-flying-thing itches: how to pass control inputs from a handheld  radio to the flying thing in question without having it process several consecutive servo pulse lengths. For the most common & simplest Arduino-compatible balancing algorithms, this limits the maximum control update frequency to 50hz, since the microcontroller has to actually measure 10 milliseconds of pulse commands (for, say, up to 5 or 6 channels) out of every 20 milliseconds. The remaining time is often taken up by software floating point multiplication and division.

The reason it takes so much of the loop time is because the abomination that is Arduino’s pulseIn() command. It’s a “busy wait” loop that sits and increments a counter while the pulse is being detected. It’s neither interrupt based nor uses the hardware timers (the loop is timed empirically). So while taking in a servo pulsewidth, the microcontroller can literally do nothing else. A little inefficient, in my mind.

More sophisticated ATmega based flight controllers like the Ardupilot use the chip’s hardware timers and internally generated interrupts. For instance, as far as I can tell in the Ardupilot, Timer 1 is constantly running (counting) and overflowing (resetting to count more), and pin change interrupts on the input pins are used to capture snapshots of the counter status, and the resultant pulse width is just the difference between the values when the pin changed from low to high (pulse started) and from high to low again (pulse ended). And if the counter overflowed while the pulse was high, no problem: just add the max possible value of the counter to the pulse width variable and keep counting. Yes, I spent a few hours reading Ardupilot source code to figure that out.

And no, I’m not going to steal it and use it, because it’s written all in straight Atmel C, and so it might as well be gibberish to me. I can read and  understand it, but hell if I’m going to write it.

One method around the onboard servo processing problem is completely bypassing hobby radios as an interface medium, which people often do with joysticks (with or without tethering to a computer). For example, there is the Arbotix Commander, which is essentially an XBee and Arduino in a completely unergonomic, overpriced package which seems to have functionality problems based on a few reports from my peers – I had the displeasure of dealing with the first version personally. Shane tethers his USB Playstation controller to a laptop, but that means the laptop has to be deployed whenever something has to be operated (The upside is infinite debugging and telemetry ability, which a plain R/C radio doesn’t give you).

So really what I would like is the ability to replace the transmitter-air-receiver-servo_pulses interface with something much more direct – like serial over wireless; something that just takes the transmitter inputs and pipes them directly to my vehicle, where it can be buffered and read at will. XBees make the serial over wireless problem very easy to solve. The result would be an XBee using a cheap R/C radio as a brainless “trainer box”: most radios have a “trainer port” over which servo pulses can be sent (over a cable) to a master radio, for situations like when you’re actually training someone who is utterly clueless about flying things (me) and want to take command of the vehicle if anything bad should happen. If this pulsetrain is read and parsed at the transmitter, then I effectively offload the overhead of processing servo pulses from the vehicle – allowing it to process much faster (hundreds or thousands of Hz) and making closed loop control less granular. My inputs would still be updated at 50hz, of course, but I doubt I can react to an event as fast as 0.02 seconds anyway. The vehicle can keep itself stable much faster.

Anyways, that’s exactly what I built. An Arduino Nano, reading the pulsetrain from a transmitter trainer port, and piping the read values as bytes over to an XBee.

It’s not nearly as epic as I made it seem to be, seriously.

I have two cheap 2.4ghz transmitters, one of which I got ages ago for Cold Arbor, and another one I picked up over the summer for Ballcopter. Which really means I have 2 of the same radio. They are both made by FlySky, but the right one is a Hobbyking rebadge. These things cost $28 brand new, with receiver, and some of the consequences of that cheapness show through – for instance, they don’t come with external servo reversing switches like every other radio, but the holes and pads are present internally to use them and if you mount your own switches the functionality is even there in the microcontroller, but no we will absolutely not spent 20 more cents to install those damned switches.  They have a 4-pin mini-DIN (also known as S-Video) connector on the back which is a trainer port.  And as usual with small Chinese gadgets, there is a community devoted to hacking them. It took me all of 10 seconds of Googling to find the pinout of that trainer port.

A little scope probing of pin 1:


The PPM pulsetrain


And zoomed in further.

The biggest difference between this “PPM” signal and the servo-style “PWM” (which isn’t even “PWM” but pulse-duration modulation… which collection of idiots agreed on these terms?) is that

  • It is falling edge driven – the time between falling edges of the square wave is actually the duration of the “PWM” pulse. When the receiver detects one of these falling edges, it will stop outputting the pulse on one channel and immediately start it on the next.
  • As a result, the actual “High” time of the pulse only goes between approx. 600 to 1600 microseconds on my radio
  • The low time is fixed duration at 400us. Makes sense – the minimum pulse lengths on the servo side, then is roughly 1000 to 2000us as it should be.
  • It “idles high” – meaning the gap between signal is +5v.

So I’d have to come up with a way to distinguish a signal pulse from the long idle pulse. Arduino’s pulseIn() doesn’t even allow in-pulse timeouts. It allows pre-detection timeouts, so you don’t wait forever for a pulse if it never comes, but it does not have “hey, this pulse is over the length I care about… let’s move on with life”. I’d have to get around this by throwing away the first update and “syncing” to the rest of the pulses, since I know how many there are and about how long they should be.

The first step of the hardware hacking was disabling the internal radio. As I found out while building the Deathcopter, 2.4ghz radios will tend to step on eachother. I didn’t want to permanently take this radio module out, however. Leaving myself the chance to return this radio to ‘normal’ duty if I ever figured out something better, I just added a pin header connection to the power supply wire. It would be left disconnected when I’m using my hack.

Next was throwing the hardware together on a perfboard. This little arrangement costs way more than the transmitter ($17-34 for an Arduino Nano and $22-25 for an XBee regular 1mW), so I really hope this isn’t the terminal solution. It’s also way underutilizing the Arduino right now, since I only have Tx and Rx pins connected, and one other digital pin hooked up to the PPM output. The transmitter provides 5 volts from the trainer port, so this board has no other power supply.

The XBee is mounted on an Adafruit XBee Adapter.

And that’s it.

Yeah, I didn’t even bother trying to source a 4-miniDIN for this. At least, not until my Digikey order arrives – until then, it’s wires jammed into sockets.

I took a few minutes hours to write the single pin read, serial write software for the Nano. The hard part was, again, thinking my code does one thing but really having it do something different – just logic errors, all caused by having to differentiate the long idle pulse from the servo pulses. But at the end of it:

There we go. I’m only piping back 5 channels out of 6 here, but this was successfully done over the air between 2 XBees. This is all done using Serial.print(), which converts everything to ASCII and thus has unnecessary overhead. When commanding a vehicle, I’d just send the raw byte values because I’m fairly sure my vehicles are not literate.

So how do I test this contraption? With someone elses’s flying object, of course.

4pcb became the subject of a few transmission tests and a whole lot of floor whomping, as seen in the test video:

While not the most economical option, it does work, and it does solve the problem I wanted to solve. I’ll probably look to refine this board or permanently mounting it inside the transmitter, possibly with a plain ATmega chip by itself so I at least don’t have to buy even more Arduini. Otherwise, creating a dongle using Arduino USB host shields and an XBee would open the floor up to using just about any gamepad or joystick as a remote.

The “XBypass” sketche as used on 4pcb is here. The general idea was to wait for the first time the 9ms long timing pulse was received, then immediately start taking in n channels, storing them, and then processing them into single-byte values (for transmission convenience as well as because 4pcb takes such single byte commands).

BallCopterTwo: Just the Software….Again

Jul 27, 2011 in Ballcopter, Project Build Reports

Since ballcopters come together quickly, this will be a quick update. I assembled the foamcore puzzle from last time, and with my package of parts having finally arrived (just in time!), BallCopterTwo is now all assembled minus the code that makes it do the copter thing.

….which I will finish. I promise.

Here are the 1000% less shitty control flaps, attached directly to mini-servos. The servo “horns” are custom 3d-printed affairs that have a 5mm side channel into which the foamcore panel slips and is retained with hot glue. This arrangement is so much more response and just… better than the previous failure of a linkage. This alone will probably make the difference. However, given that all the flaps are independent, they will need to be software controlled.

And the bottom side. The hinge is just Kapton tape wrapped around the structural carbon fiber rod. There is one catch, though – I attached a small section of Kapton tape, sticky-sides together, to the center of the hinge so it can move without sticking. Otherwise, the tape wrapping around the carbon fiber would make it too stiff.

The puzzle piece fully assembled.

I did alot of this on what amounts to autopilot (heh, autopilot), so I forgot to take pictures of the battery installation as well as the super-slick 12-servo (4 inputs, 8 outputs) interface board I whipped up using some perfboard, an Arduino Nano, and a Sparkfun 6DOF Razor IMU; but they are forthcoming. That contraption has been tested for basic functionality and mounts immediate above the blue servos. For now, though, Ballcopter is mechanically and electrically done – not electronically yet, since there’s codes to be written.

The final all-up weight is 19.5 ounces or 550 grams. Much heavier than the J-pop ball drone (350 grams), but this thing is also bigger and has 8 chunky miniservos (14 grams instead of 5 or 6) and a massively oversized 1Ah battery. Yes, I’m still used to sizing batteries up for electric vehicles.

The Once and Future Ballcopter

Jul 25, 2011 in Ballcopter, Emergency Quadrotor, Project Build Reports

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.

 

Ballcopter!

Jul 09, 2011 in Ballcopter, Project Build Reports

Hello everyone, I am pleased to introduce Ballcopter.

It doesn’t work.

But it sure is cute, though. Look at how cute it is!

Ballcopter was inspired by a recent Japanese experimental ball shaped drone which made the rounds on the Internets about a month and some ago (though it appears to have been in development for a year or more). Here’s some more test videos:

Needless to say, I was instantly enamored with the spherical design. It’s so much simpler than a multirotor machine (like A Certain Emergency Quadrotor) and appears to be even more agile. And being Japanese, infinitely cuter. Having no details about how it was built besides just staring at videos, I sort of mentally reverse engineered it and designed one, but did not go about actually building it.

…until two weeks ago.

visiting the other coast

I was extended an invitation to visit Makani Power, an airborne wind turbine (AWT) research and development company based in Alameda, California, by MIT alums affiliated with the company. Lots of MIT graduates (and recently, MITERS alumni) end up in the San Francisco Bay area for some reason, and I found the environment at their shop/facility very much reminiscent of what I’m used to here. While I’m not someone who is enamored with wind power, I did take the opportunity to talk to the engineers and learn a bit more about aerodynamics and wing design, and also tried my hand at laying up carbon fiber.

Those two things can only result in more desire to build flying objects from me, so I’m not sure if the outcome can be considered positive or negative.

But I also built a ballcopter. I spent a total of 6 days at Makani, and while not discovering that carbon fiber fabric actually does deform and change shape (I had wondered how on earth smooth CF surfaces were made before), or looking at how composite airfoils were manufactured, I whipped up a design for Ballcopter, ordered parts (and had them overnighted to the facility), and used the shop to cut out the frame and finish it up. The parts cost was  about $150 including the whole overnighting thing, and the total time of build from start to finish was only about 60 hours.

And it kind of shows….

This is a picture of the first few hours of design. Again, there is absolutely no science to this at all – it’s a crude visual pirating of the vehicle shown in the test videos – I just sat down and started CADing. The frame was designed to be made using foamcore (stiff polystyrene foam overlaid with heavy paper), also known as posterboard, foamboard, etc..

I’ve added the control flaps here. The way I guessed that the JSDF drone worked was using the upper set of flaps to control direction (tilt and movement in XY, or I guess in this case XZ) and the bottom set as a rudder (spinning about the polar axis). Opposite diagonals of the upper flap set move with eachother, and all the rudder flaps displace the same relative angle. I was intending to just use a stiff tape as the hinge, which seems to work out for most small airborne implements. The servos are 9 gram miniservos, and the propeller mockup is standing in for a 10 x 4.7 inch prop.

The design progresses a little more with the addition of the… Tropic of Capricorn? The wide band adds structural rigidity to the outer shell and also acts as a crude duct to funnel air over the rudder flaps.  I have no clue what they actually do, but J-ballcopter had it too!

Because the timeframe was so short, I pretty much just went downstairs and heaved foamcore on the laser cutter and went for it.

Wait, foamcore on a laser cutter? Now, MIT’s rules have always said that cutting foamcore on a laser is an instant death sentence followed by permabanning from everything ever. You won’t even be allowed to use the shop in Hell, even though it’s already on fire and people are already dying around you. Foam tends to melt and burn, then drip and burn more, until a serious fire develops. I was not entirely convinced that the rules were founded on technical barriers, just peoples’ stupidity, so I elected to experiment with foamcore cutting settings on a foreign laser cutter.

And you know what? Like I suspected, it worked just fine. The key is to use many passes of a low power cut with very high head speeds so the laser never parks long enough on one spot to burn the foam. I ended up finding that 4 passes of 20% power (on a 150W system) and “30%” speed made for a very clean cut in 5.5mm foamcore, with the last pass just barely breaking through the paper backing on the far side, resulting in a good ‘puzzlebot’ sheet part. These settings are for a Universal Laser ILS1275, so I don’t know how that translates to Epilog or any other manufacturers.

Disclaimer: if you’re an MIT student, DON’T EVER CUT FOAMCORE ON THE LASER CUTTER!

Instant ballcopter. Just add hot glue! Notice that one side panel has been left off so I can actually service the thing.

And the parts arrive. I got all of these from Hobbypartz.com, which seems to be a U.S. variant of Hobbyking (you know, the one that isn’t Hobbyking’s U.S. office). I used to see them spammed all over the place, but hey, they’re legit. The lineup includes a shady 6 channel 2.4ghz radio (functionally identical to the 6 channel HK radio I bought for the robots last year), eight 9 gram miniservos (because they’re like 2 bucks), a 28mm outrunner with 25A controller, a 1Ah 3S lipo battery, and a few little linkage parts.

The one thing which I could not get because it was out of stock, and which I couldn’t find at the local hobby shops because they were useless, was a propeller hub for the motor. So I actualled machined something (!) and made one. It’s based around a short 1/4-20 bolt that was drilled out and had a set screw added. Stock locknuts and washers take care of the fastening of the propeller. Sure, it’s heavier than an aluminum prop collet, but could I find an aluminum prop collet?

A laser-cut buffer plate made of plywood secures the motor to the frame. The servos were also given little laser-cut mounting plates because let’s face it – foamcore is just not structural.

And here it is!

Notice the small carbon fiber rods spanning the the upper flaps in an attempt to get them to synchronize.

The word “attempt” is key across all aspects of Ballcopter here. It really didn’t work, and after a bit of head scratching (and “duh” moments), I concluded that…

  • Those flaps are just too rigged and horrible. I ended up using electrical tape for the hinge material because it was in front of me. Protip: Electrical tape stretches. Instead of rotating the flap about the hinge when the servos moved, it was more liable to just displacing the flap without much rotation.
  • The servo linkages were not well thought out at all. In fact, they weren’t thought out – just built on the fly. The linkage is a 45 degree bell crank of sorts. While all aircraft control surfaces seem to rely on the small angle approximation, this only works if there are not like 3 different small angles involved and one of them isn’t based around displacement from 45 degrees. This arrangement is clearly seen in the above photo. Basically the servos were more yanking on the flaps sideways after only a few degrees of rotation. The same goes for the rudder flaps, where 2 flaps were actuated by a servo between them.
  • As soon as the prop started and the vehicle took off, those sad little linkages and hinges just collapsed and the result is not very much flap displacement at all. The vehicle was therefore barely controllable, and tended to just run away in one direction (or run away while twirling if I applied any rudder control)

The JSDF drone is gyro-stabilized, too, and mine was totally and utterly open loop.

So over all a great execution of Cheap Chinese Imitation that would probably have worked if it wasn’t crudely reverse engineered and then even more crudely reassembled. I do want to try my hand at this again some time, though – direct drive flaps (no loose and bendy links), real hinging, reducing weight a little (there is really no need to carry a 1Ah battery on something this small), and adding some intelligent stabilization using IMUs.

It’s so cute that I have to try making it work. Before I left, I stripped down Ballcopter back into parts, and hopefully those parts are en route to me in Boston. The frame was left mostly untouched and would make a great lamp or something.

Onwards ボールコプター!!