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


8 thoughts on “Chibicopter: It’s Reached “That Stage””

  1. What kinda caps are you using for decoupling the power rail for the atmega?

  2. Mismatching bitrates are of course never a good thing, but without a full trace of what went in on one side and what came out on the other that might be a bit difficult to catch. Now, I have to make it clear that I’ve never worked with either XBees or Arduinos specifically, but another nice way to lose data would be the blissful lack of flow control the whole Arduino bootloading process seems to be using.

    By principle, on a “blind” data-only channel such as a UART one does never know if the other side is still ready to receive data if continuously fed (just a matter of time until it probably won’t) – hence, the idea of flow control. Arduinos seem to rely on sending no more than 128 bytes before waiting for a confirmation, and the fact that the Arduino can at any moment buffer at least that much. That, however, says nothing about an XBee always being able to do the same thing. Which it normally does (it seems to have a buffer of ~200 bytes or so), but who knows…

    You might want to try a much lower (~9600) baudrate on the PC side (and the PC-side-XBee, of course), that would give more time to the XBee to do its thing and less of a chance of pileup (the actual RF baudrate seems to be around 250Kbit anyway though); you might also want to configure DIO7 as CTS on the PC side XBee, and look at it during the transfer. If if toggles at about the time you lose connection (or at any time at all indeed), you probably have a buffer overflow. You can try the same thing on the other end of course.

  3. Got an uno or a duemilanove or something? Try hooking up the TX and RX pins of the receiving xbee to that, and see if you can program that. Use all the same pins that you use on your board.

  4. Weird. Maybe your XBs are just screwy and have crappy resonators. BTW, i was on hobbyking and can’t find most of the orange turnigy motors> Have they revamped their product line.

  5. also, where do you buy your A123 cells. I’m looking to make a rideable suite case and want to use them for the batteries.

  6. We get our cells from A123 The Company – they’re an MIT spinoff, so there are nice little donation and free stuff quirks. Sorry – by agreement, we can’t give them out or sell them to other people. Hobbyking is one place to look for authentic A123 and inauthentic LiFePO4 cells which also work just fine. is the most legit shady battery dealer I am aware of.

  7. legit shady-guessing chinese. Whatever, if they have A123 it’s good for me.

  8. I was just there, looks very very shady but does have the new kind of A123 cells-lower Rs and higher capacity.

Comments are closed.