Return to the Copters: Global Flying Things Update

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 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).


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!)


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.

Chibi-Everything, Part II: Copter

Poor Chibicopter.

So I’m proud to announce that I’ve found a solution to the XBee over-the-air code uploading problem. The only catch is that…

…it involves chopping an FTDI cable header onto the board.

Yeah, not groundbreaking or world-changing. But, at least I’ve gotten over my software-induced project fear stage and now have a workable, if slightly convoluted, procedure for uploading code and debugging! The hookup for the FTDI is essentially that of the Sparkfun Pro Mini, but instead of DTR I have RTS from the standard FTDI cable going into my reset isolation capacitor thing.

I really should have just done this like two weeks ago.

Anyways, here’s a picture of me triple wielding XBees in order to get this thing to work. The current signalling protocol is:

  • The Xbee connected to my transmitter (in bypass mode) is address 2, the XBee on Chibicopter is address 1, and my debugging/base station is address 0
  • XBee 2 only transmits to Xbee 1 (ATDL = 1 ATMY = 2)
  • Xbee 1 only transmits to Xbee 0 (ATDL = 0 ATMY = 1)
  • Xbee 0 transmits to the nonexistent XBee #3 (ATDL = 3 ATMY = 0) in order for its serial transmissions to not appear on the others
  • Therefore, my radio transmits commands to Chibicopter, which in turn transmits debugging data to the base station where it appears on my screen.

To reprogram Chibicopter, I remove the Xbee from Chibicopter, disengage the base station XBee adapter and jam the FTDI cable onto Chibicopter. I have to take the XBee onboard out first because there is no selection/domination circuitry which allows both XBee and FTDI cable to use the serial lines at the same time.

It’s quite an overloaded process, but it has at least gotten me to the point of…

…being able to finally read the pulsewidths from my radio. All four of the ones I care about. The Serial buffer reading code needed a bit of tweaking – I had to flush the serial receive buffer after every read or else it would desynchronize because more packets appear as the procedure was executing.

Sadly enough, there is no more Serial.flush() in Arduino 1.0, the functionality having been removed. I wondered why briefly before just writing a dumb serial buffer clearing loop.

Anyways, the good news is that I transferred enough core functionality over from tinycopter such that Chibicopter’s props respond properly to suddenly orientation changes! That means it’s just some tuning of gains away from actually flying.

The bad news is that through some irony of fate, two of the tiny 1S-lithium motor controllers have ceased to function. Just in time, right? I’m uncertain as to why they failed. One possible reason is that since the board has absolutely no logic power supply at all (everything running off the 3.something volt battery) that 5 volts from the FTDI cable was enough to destroy the weaker ones.

Now, I’m also wondering why it is that there is an option for 3.3v-compatible logic but with 5 volt VCC (power supply). If the point is to use it with a 3.3v system safely, isn’t this undesirable?

No matter – I have more spares on the way, but they’ll still take a few days to arrive. In the mean time, I might make a little pass-through board or something which down-regulates the 5v USB power to 3.3v.

and then it will fly I swear guys



Okay, Internet, tell me more about wireless bootloading.

One of my perennial bad electrical engineering habits is black-boxing electronics and software – not making much of an effort to understand how a (usually software) system works, just accepting that a solution is available and not extensively exploring it unless needed. Historically, I did this to electronic hardware too, coming from a more R/C hobbyist background (I don’t really consider the battlebots to be “robotics”) where things like “Receiver” and “Motor Controller” were considered atomic components as much as screws – they could not, and should not, be decomposed further. I’ve gotten a bit better at that, what with making entire motor controllers and all, but embedded programming is still one of my sour spots.

This is part of the reason why I like Arduino so much – it’s easy, reasonably well featured, and I don’t have to think about diddling registers and setting bits – 6.115 taught me to never do that again if I could avoid it – just to toggle an output pin. It makes the software experience just a little more like high level application programming, the kind I did before getting into hardware and actually all through high school (Did you know that I was CS before I was EE or ME?). Convenience is of the utmost importance, absolute code efficiency and running speed less so. Probably because I just haven’t done a complicated enough motor controller yet, or a flying thing with enough axes. Granted, I’ve also gotten slightly better at that, since there are just some things which are easier to do, like changing the PWM frequency of analogWrite(), by breezing through the manual and just doing the annoying bit shift thing, or enabling a regular interrupt so some part of my code runs with a fixed delta-time for control calculations. In summary, I favor trying and modifying existing solutions first in order to solve the high level problem of make thing work. Which is another great thing about Arduino and the general OSHW community – someone has probably done it already. Including build a smaller quadrotor, but that’s besides the point.

But I think I’ve reached the end of reasonable high level probing, because Chibicopter is not wanting to program wirelessly at all.

Here’s the rundown. I’m using the Adafruit Solution for wireless code uploading to the ATmega328-turned-arduino. There are some differences between my exact circuit and the “community solution” in this case – I’m running 3.0v logic power and my reset line is coming out of D6 instead of D3. The Little Purple Wire hacks are documented here. Otherwise, the level shifter/buffer circuit (which I feel isn’t really necessary) is the same, and for the first few attempts, the settings for my XBee Series 1 radios were also exactly the same as directed.

So here’s what’s been going on:

The Symptom: The remote reset always worked, but the program transmission itself has a success rate of maybe 5 to 10% at most. The most common symptom is hanging – the RSSI LED on the transmitting Xbee goes out, and the ‘Uploading” stage of the Arduino IDE never completes until it times out with an Out of Sync error. A few times, I’ve had programs make it all the way through and complete, but only once or twice, and then it becomes completely up to chance again. The successful attempts seemed to require uncorrelated “adjustments” such as exact location in room (possible radio bad spots or WiFi interference) and orientation of radio, which at such close range I find implausible to be the problem.

The fixes:

1. Complete hardware swap. I ordered more XBee Adapters because my one remaining unit was clearly showing reliability problems – I had to seat the XBee in the headers in a specific half-out fashion to get the power and associate LEDs to turn on, so to rule out the possibility of bad contacts or intermittent power, I made some new boards up. This did not result in any appreciable change in the operation – the vast majority of uploads still failed.

2. More radio power and XBee swap To test the interference theory, I borrowed Shane’s XBee Pro units which transmit at something like 150mW, which tends to outpower every 2.4ghz device around it. This did not affect the success rate of upload, but in this process one of my transmitting XBees was found out to be damaged. It was replaced with another of my radios (the one which had been handling LandBearShark’s load cell reading telemetry), to no appreciable change. I then borrowed two brand new radios, also to no appreciable difference.

3. Reduction to Tx/Rx only with stock XBee settings I removed the reset circuit’s digital I/O pin function so the pin did not toggle. The programming was then done just by hitting the reset button while uploading with only Tx and Rx active. This got me 2 or 3 consistent uploads (variations of Blink.ino), but after that, it once again become unreliable. I completely refreshed the settings a few times, changing only the baud rate to 57600 8-N-1.

4. Possible undervoltage operation problems The XBee is rated to operate between 2.8 and 3.5 volts. I’m running 3.0v, technically not really “3.3v”, so it could be that the XBee is being underpowered. Testing on real 3.3 volts provided by a bench power supply, using variations of Blink.ino only resulted in the discovery of the “uncorrelated adjustments” like Shane standing 5 feet to my left vs. next to my right, or using the back half of MITERS vs. the front, and turning my wireless LAN/Bluetooth off on my laptop vs. on. I do not believe any of those environmental factors are truly the cause of the problem.

5. Power Supply instability. Xbees, being high powered digital devices, draw current in bursts. I have very little 3.0v capacitance, so maybe little dips on the power supply was causing problems such as when the receiving end sent back start/stop flags. I piled a ridiculous amount of caps on the XBee pins directly during the above power supply runs, to no appreciable gain.

6. Trying a known working board. The 2.007 Nano carrier can wirelessly program using the “community solution” or using bone-stock settings on the XBees and manually pressing the reset button. This was demonstrated several times by Shane, but I could not get any of my hardware to reliably work with it either! This was eye opening, and pointed me to the fact that the problem may not lie with Chibicopter’s board. The full battery of tests – my Xbee adapter with both my radios and his radios, the XBee Pro, his own XBee USB dongle… none of them worked reliably if my computer was involved!

7. Messing with virtual COM port settings I tried the established solution (SET RTS ON CLOSE) with no other changes, changing the baud rate explicitly to 57600bps, and even installing a fresh, new FTDI cable to talk to the XBee adapter (thus installing an entirely new virtual COM with no possible previous changes). While the latter change appeared to result in success (4 reliable uploads), it stopped being reliable again thereafter. So promising ;-;

8. Literally trying wires. Hooking up transmitting TX to receiving RX, and vice versa, with GND bridged. This was literally plugging wires in and out of XBee sockets, and it worked without issue every time. This means the issue lies strictly between how the XBees interact with my computer and with eachother – once I literally bridged the connection, there were no communication problems.

Possible explanations we gathered:

1. Some hardware level difference between computers. While this seems to be a stretch, Shane’s Dell notebook can program Chibicopter with much higher reliability such that the random interference, voltage dip, and noise explanations begin to be plausible, and the Nano carrier essentially flawlessly. My HP DV7 can do neither. I’m not up to date on integrated computer peripheral hardware, but I do want to try the exact same parts on a Macbook – if it works on a Mac, then that would explain why there are so few complaints about it, given the Arduino and OSHW community demographic…

2. I am actually missing something very fundamental and stupid. Given that the uploads are so reliably unreliable, this seems almost like the most plausible explanation. Did I really forget to ground something? Are my traces actually soldered? They must be, because I can definitely program the damn thing over 3 wire serial! Are my XBees just cancerous? They’re both  Series 1 whip antenna types with the latest 10ED firmware now.

I’m willing to rerun some of the tests and provide more verbose error message logs, as well as COM port settings and XBee settings. But what the ass?







Chibicopter: It’s Reached “That Stage”

…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?!


Chibicopter Episode II: The Prototyped PCB Menace

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.