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