Archive for March, 2012


The Seedlings are Growing

Mar 31, 2012 in Electric Vehicle Design, MIT, Bostoncaster, Cambridgeshire

Every year in the great buildoff that is MIT’s 2.007 Design & Manufacturing I class, there are several ‘pack leader’ students who, whether through some prior experience (e.g. in FIRST Robotics) or their own build-driven volition, demonstrate exceptional robot designs. It’s a relaxing break from the usual crowd of bent sheet metal and plywood servo ants with too much weight on the nondriven caster which, while important to newbie builders (and everyone, including me, builds one eventually when they start out), is just kind of painful to watch. It shows well that the caliber of design execution is affected more strongly by your knowledge and prior experience with tools and methodology than just the quality of parts you get in a box. Because honestly, the stuff in the robot kits aren’t first-class at all – plastic-geared motors (though they’re quite interesting), continuous rotation servos, and god those horrible derpy caster wheels. But really, is it any more effective to give coreless Maxon gearmotors to people who barely knew what a motor was before this class?

Anyways, some examples of Nice Bots from the past few weeks have been compiled below:

There will surely be more examples as the final half of the semester (wait, really? Crap…) wraps up!

Now, how’s my own “undergraduate victory garden” of seedlings doing? I’ll post an update on the Electric Vehicle group soon.

Chibicopter: It’s Reached “That Stage”

Mar 29, 2012 in Chibicopter, Project Build Reports

…you know, the stage of all my projects where they become stuck in software hell.

For Chibicopter, oddly enough, it’s not been the actual operation code which has stumped me, but the process of getting it there. As previously described, Chibicopter’s only means of code uploading after the ATMega328 has been turned into an Arduino is through wireless bootloading. This has been done successfully many times. In the Chibicopter board schematic, I included components intended to use the Adafruit Method, and a similar arrangement is used on the Gravitech XBee shield for the Arduino nano and on the 2.007 Nano carrier. So it’s gotta be pretty bulletproof, right?

Well, kind of. Here’s how shit went down.

First off, I had to make one last wire jump for everything to stand a chance of working. The reason is because I connected the RTS pin of the FTDI cable (through the wonderful Adafruit XBee adapter) to DIO8 on the XBees:

(Don’t mind where it says “DIO12″ – that’s because Sparkfun’s XBee footprint is weird, or something – it’s actually DIO8 according to the manual)

I chose DIO8 instead of DIO3, the usual choice, because it was much closer to the appropriate pins of the ATMega based on component placement. It would have been less of a topological acid trip to route the trace there. The only problem with choosing DIO8? It’s not a thing. As in, DIO8 turned out to be only DI8 when I tried to configure it in X-CTU.

Hmm. Well that’s disappointing. Wire jump time:

I performed a Little Purple Wire jump, after cutting the DI8 trace, to DIO6 across the other side. Conveniently DIO6 was also the XBee’s default RTS pin. However, in the interest of following instructions for now, I configured the pin as standard digital input (on the transmtiter side) and a default-high digital output (on the receiver side). Now, I’m assuming there’s pretty much no difference at this point between setting it as instructed or setting both sides to “RTS FLOW CONTROL” for this pin, but I could be wrong.

The fix was promising at first – I could upload blink programs of various durations with no problems through Arduino, getting to the “Done Uploading” stage every time. But as soon as I tried uploading a bigger program, it would quit – usually after only a few seconds (short enough to transmit a blink program, but nothing much else). The activity LED would turn off, whereas if it were transmitting, it would be on pretty solidly.

Scoping the TX/RX pins and the DIO pin associated showed that the reset pulse was making it through (as my hack D13 LED did flash) and at least something program-like was being transmitted. However, it would randomly shut off, and the process would abort with avrdude-in-Arduino complaining that the programmer was out of sync.

I thought it might have been a mild baud rate mismatch problem (and still suspect it to some degree), so I hardwired Tx and Rx straight to eachother on the XBee adapter board:

Of course this arrangement worked. The blame now lay square with the XBee, and at Shane’s behest, I reset both XBees to factory default, wiping every setting I might have changed, and then changed things back exactly as instructed. (The transmitting one came out of the defunct RazErblades glove controller and the receiving side came out of…. hell if I know where)

It worked.

But only sporadically. I’m in a position now where some uploads will complete, some will totally fail within the first few seconds, and others will seemingly fail and cause Arduino to wait forever in the “Uploading…” stage until finally terminating, usually a full minute later, with an out of sync error.

Weeeeird. Well, at least I can upload some code:

I’ve since balanced the propellers much better (the whole thing doesn’t really resonate any more, though it’s still not in perfect balance) and have cut and paste enough code from Pololu’s MinIMU9 library to read all the sensors and process them. I’m not sure how you’re supposed to use their library, by the way, so I just copied and pasted the important I2C register-setting code from it and never looked back. Are you supposed to… instantiate a new instance of each sensor or something? It didn’t compile in Arduino 1.0, and the provided AHRS code was of little help since it had such lovely high level functions such as “Read_Gyro();” without explanation of where they came from, and which I couldn’t located in all the linked .h files anyway.

Anyways, Chibicopter is some more code and tuning away from flying, which is to say it will probably sit in a box for the next few weeks. If anyone from the Arduino hacker community has any idea why my code uploads are spotty, I am open to suggestions. My number one suspicion is still the 57.6Kbps baud rate mismatch now that other inconsistencies have been eliminated.

The next step is to revive XBYPASS and glue it back to my transmitter since for some reason I decided on making this thing talk over wireless serial. That step, however, has been done before. Wow, finally a legitimate use for XBYPASS that is not trolling the anti-Arduino crowd?!


A Productive Spring Break

Mar 25, 2012 in MIT, Bostoncaster, Cambridgeshire, Stuff

…with the GT Invention Studio crew. MITERS cordially invited emissaries from Bizarro World MITERS over for a week of tours, visits, and randomness. Randomness ensued indeed:

The IS crew: Jamison (Variable Constant), Xo (Geek Shave Feelings), Aaron (bot3000).

Chibicopter Episode II: The Prototyped PCB Menace

Mar 22, 2012 in Chibicopter, Project Build Reports

Poor Chibico….oh, hold on, it hasn’t quite gotten there yet. That should come in a few days after I crash and rebuild it like 10 times!

After the previous expository update, I finished designing the central carrier board for the ESCs, XBee, and IMU module. It’s easily the smallest and densest thing I’ve had the joy of routing:

Doesn’t look that small, right? That’s because the whole thing is at like 5x magnification. The outer dimension is 1.25″ square, and the mounting holes are on a 1.1″ square. What also made it difficult was the fact that the components weren’t all in a neat line like my motor controllers usually ended up being, but rotationally distributed, necessitating (relatively) long wire traces.

Also, remember how I said I would never, ever use SMT components smaller than 1206? Well…. uhhh… I still never will, but I had to use 0603s on this one because 1206 parts are so damned huge.

Notice that the IMU and ESC connections imply that they are vertical. Well, they are going to have to be – I spent a long time trying to cram four of those controllers, the IMU, the XBee headers, the ATMega chip, and all the random little passives into a 1.25″ square area using only 2 layers, and kind of failed. Rather, I gave up and decided it was less painful to just make vertical footprints for the same pins. We’ll see if this bites me in the ass.

I sent these off to Advanced Circuits (saying 4pcb would be ambiguous now) using their Bare Bones service which gets me something only marginally better than if I had etched it myself, but allowed me to punt working on it for several days instead. So a few days ago, I got this back:

Hey, boards! Sweet….. wait a minute.

So the first picture of the routed board is actually the latest version, created after when I found out that in fact I did have space for a bunch of blinky LEDs.

I neglected to update the Gerber files, of course, and sent out the version with no LEDs instead.


But look how tiny and cute they are!!

I added a single layer of heat shrink tubing to the stick mounts of the motors, since the holes for mounting them in the frame were a little bigger than intended.

Here’s the frame with all four motors mounted. The mounting scheme is just some thick CA glue. Nothing fancy here…. but anyways,


I threw this whole pile on my crack miniature scale to get a weight so far. I estimated initially that Chibicopter will weigh about 50 grams or less, with 50 grams being kind of the real “ididitrong” figure. I am confident it should end up well under.

I’ve now moved onto adding parts to the board. And indeed, the decision to make the IMU stand-up is coming back to haunt me. The height of the right angle standoff and the board combined is in fact longer than its own landing legs.

Hmm. Well at least I know Chibicopter will never feel inadequate. But, it does present a problem. The solution was to cut off the black header block thing, which gained me another 2.5mm, enough to clear the landing legs.

Putting on the ATMega was quite an experience since the board was unmasked and I only had 0.5mm solder. Luckily the tip was small enough so I could make a solder blob on it, partially wipe it off, then use the remainder to “reflow” the joint. Shady, but they all worked out in the end.

The high-rise parts now go in. About this point was where I realized that the battery plug and the reset button were both between two very tall motor driver boards and would be  difficult to reach. Chalk it up to Revision 1.0 – now, wouldn’t I have looked silly if I tried to Kickstart this?!

第二个fail: Forgetting that SOT23 is not the same as SOT223.


I “remembered” that I had some SOT-23 small FETs left over from making the Skatroller to handle the level shifting between 3.3 and 5v. In this design, one is used to buffer the XBee so it can properly reset the ATmega so the Arduino bootloader can run.

Well, it turned out that they were indeed SOT223. And that extra 2 matters alot, since SOT23s are small and SOT223s are definitely not.

To bypass this, I chopped the leads off a TO-92 packaged 2n7000 signal FET and contorted it into position.

The board mounts in the body cavity like so.

I both realize the cavity doesn’t need to be as big as it is, and think it needs to be bigger so I can fit these damn boards all lay-down style… So many things to try for version 2.0, and I haven’t even finished version 1.0 yet.

Sounds normal! In this picture I’ve also prepared the single 240mAh 20C lithium cell with a matching JST connector.

Now with more XBee.


With everything installed, even the little extension harnesses I had to make for the motors, Chibicopter weighs in at just 31 grams!

But that’s without the battery. Once I drop the 240mAh cell on top, with its length of wire lead, the total weight becomes 36.6 grams.

And I assume that once I add the program in it will be more like 37 grams, right? Isn’t that what happens when you upload code?

nondeterministic PCB layout

Chibicopter’s version 1 board isn’t without its faults. For one reason or another, I had to make three little wire jumps to get everything to work.

Normally in my schematic  captures, I explicitly put a “dot” junction on EVERY connection from part to net, or between wires, etc. I’ve been bitten by Eagle’s mysterious reluctance to connect two wires before. This time it seems like I let my guard down – there were 3 entire nets which visually appeared to be connected in the schematic, but none of it ported over to the layout!

This kind of pissed me off alot. Part of it was, admittedly, my fault for not double checking “hey, wait, why is one of my servo signal pins not connected to anything?” and “why are 2 of my ISP header pins empty?”, caused at least in part by routing this board at 5 in the morning.

I also slipped into a different grid spacing at least once by accident during schematic drawing, so who knows – maybe it’s some weird Eagle thing that caused wires not to connect to component pins.

Whatever. The 3 wire jumps needed, the transistor hack, and the lack of LEDs in the board revision I mistakenly sent out meant that I didn’t feel bad at all writing off $40 of boards.

These will serve better as door decor for MITERS. I can do better than this pile of crap.

To come: actually programming the damn thing. I’m hedging the whole project off the fact that the Adafruit wireless bootloading method (Adabooting?) will work as described – my XBee hookup is pretty much identical to that guide.


The Post Where I Update Everything Ever, Part III: What’s Smaller Than Tinycopter?

Mar 14, 2012 in Chibicopter, Project Build Reports


The game is on. I’m out to build a quadrotor smaller than Tinycopterway smaller. This isn’t anything that new or groundbreaking – it’s been done before, and even smaller than my 2.5 or 2″ prop size, but this is my project, dammit! I have never thought of anything on the scale of where fractions of grams will matter, or where the control bandwidth is potentially far above the maximum refresh rate of R/C based controllers. Either way, this is going to be one hell of a challenge.

And furthermore, I’m doing it for the Design for DIY Manufacturing course (MAS.963) at the Media Lab. So, once again, a chance to pimp all of those rapid prototyping tools I have come to love so much. Now, there’s some issues with the whole “Charles builds something for class” thing which historically have caused problems, such as me focusing way too much on the build and not enough on the class, but I think it will work out in the end.

This project has actually been running for about a month now. I started in February by designing the airframe:

That cutout in the middle is an XBEE. That’s how small this thing is. The airframe is designed to be one piece SLS 3d printed in nylon – this is not a technology that is available here, so I have to farm it out. No matter – I can’t get the frame light enough while still adhering to the minimum feature size requirements of FDM printing. The frame weighs only 8 grams in this image, but later on I reduced some dimensions and wall thicknesses and got it down to 7.1. It’s still a bit “chunky” looking, and I’m sure with MOAR SCIENCE I can improve the rigidity of the arms even further and make them even narrower, but unlike some MechE designers who insist on characterizing and justifying every single aspect of the design by analysis and simulation (Deterministic Design™), never actually getting around to building the damn thing, I strongly favor just forging onwards with something that looks good and later on analyzing why it worked or didn’t work.

The underside is essentially all hollow – a single board will be mounted in the middle which will carry the XBee, an embedded ATmega328 microcontroller with required peripherals (since I can’t stuff any kind of Arduino module on this), and four 1S, 3A ESCs from Hobbyking which will be partially embedded on board by virtue of hanging off via headers. A Pololu miniIMU will also be mounted on the board. The all-up weight of this thing ought to be under 50 grams. The motors were selected to be 2 gram outrunners from Hobbyking, and I also bought a few 240mAh and 160mAh single Lipoly cells for the battery, which will probably just be parked on top of the Xbee.

Now, let’s fast forward 2 weeks after Shapeways finished producing the frame in their magic SLS printer (probably an EOS Formiga or similar). The airframe only cost $13 to print, by the way, because the material use is so little.


Wow, this is smaller than I imagined. Also, the frame really is kind of flexible – they weren’t kidding when they said white, strong, and flexible. Part of the flex comes from the completely open bottom and non-closed arms – I was originally intending to route wire inside the airfoil-like arms, but I really didn’t need to make them all the way open on the bottom. That was a slight design derp, but while the frame is bendy by hand, my hand also exerts far more force than it will ever see on its own.

It’s also fixable with a chunk of balsa wood and some super glue.


Yeah. Also, in other news, Tinycopter still exists – it gave a full day of flying demos at the MIT Museum recently, which surprised me since 1. it worked the whole time and 2. I flew it the whole time, somehow.

I got the outrunners and other parts just the other day. This thing is just going to be a ball of cute. The outrunners are 8mm in diameter, and the stator is like, no more than 5. How the hell do you even put that together? The 2510 props just press right onto the 1mm shaft. No prop collets or savers or anything.

Here’s a 240mAh cell. I might downgrade to the 160 if weight presents a problem, but the 240 is nice because it fits within an XBee’s footprint. I’ll probably just end up patching a JST-ZH or similar miniature terminal onto the end of this thing.

The next step is to whip up the single board and have it fabbed ASAP – I’m running quickly into the “midterm” project demo due to everything else that’s going on.