2Tiny2Troller!

chorl1 Comment

First, if you’d like to see what the aftermath of a ducted fan nibbling on my arm is, here’s a picture. Be ware, it’s fairly bloody, so if you’re not the kind of person who regularly receives small injuries or who is into Internet gore, it would be better to pass  it up.

Anyways, it’s here! The updated Tinytroller signal board from a few posts ago has materialized from MyroPCB’s mysterious printing facility somewhere in northern Tajikistan, or so I believe.

Well gee, it looks the same as the previous panel. I’ve gotten into the habit of buying boards in quantities of 4 or 6, because Myro’s panelization fee is paltry and I just send the entire panel as one “part”. As long as it stays under 30 square inches for their entry-level service, I can has more boards. At the rate I’m killing Tinytrollers in beta, this is probably beneficial.

The board is actually a little different. While I only moved one resistor on the power board (circuit otherwise remaining the same), I’ve replaced the first iteration electrolytic logic power capacitors with all ceramics. This is partially an experiment – all ceramic buscaps can have extremely low ESRs, ESLs, and be more reliable (being solid state) than electrolytics. While it’s totally not warranted for a non-precision app like a motor controller, I did find a pile of 1210 package, 22uf 50v ceramics on eBay for cheap. This means the potential for 88uF native on the input, more if I abuse the footprint and use the caps sideways or just pile them on top of eachother. The output capacitance remains the same at 66uf (22uF, 16v ceramics in parallel).

I also shifted the signal board headers leftwards a few mils such that they actually clear the power input capacitors.

I spent the evening putting the boards together – these are the last six 3107s that I can just reach out and grab, so I hope this actually works. I’m also out of Arduino Nanos – more from the mysterious eBay electronics cloud are coming, but they’ll take a while.

The downside to a totally new board is totally new debugging cycles. I spent a while chasing down a dead short on the signal board. It was in fact so dead that it took jumping 5 amps around and feeling which traces heated up several times before I cornered it to a clearance-related issue which was literally right under my jumper wires…which explains why I ended up somehow pumping that much current through the “board” without doing damage – I might as well have twisted those wires together.

There is an area near the top row of headers where I grouped the 5v and GND lines together a little too closely (less than 3 mils) and it looks like Myro’s etchwork might not have sufficiently caught the gap.

It was dispatched with some knifework. The rest of the circuit seems to be unchanged and sound. I ran this board on the “sit and PWM into thin air” cycle for a few minutes to verify the gate drive and logic power operation – anything drawing more power than it should would be noticeably hot by the end.

Here it is… looks kind of the same as before, right? The little wire jump on the right is to make up for the fact that I had to cut the errant 5v trace.

There are some Arduino pin definitions that have changed on this board, but tomorrow I will re-upload the current control code and modify it to run on this version of the board. I should be able to read all three phase output voltages as well as the DC bus voltage. Then it’s one step LOTS OF SOFTWARE away from SENSORLESS TINYTROLLER!!!!

I’m thinking of putting this Tinytroller in melonscooter. Not only because I want to try running my own equipment for once, but because Tinytroller has demonstrated proficiency at variable regenerative braking with Straight RazEr, and it’s even survived the Radu Test, where Radu floors your creation around everywhere (it’s a rite of passage for MIT Random Small Vehicle Team creations). Melonscooter also has the capability of drawing far more amps, and the Turniby C80/100’s extremely low inductance and resistance means the current control has to be very robust.

Also, I’m fairly sure this thing can commutate faster than 550 Hz.

 

 

 

The Decommissioning of the Quadrotor Project

chorl4 Comments

I bet everyone forgot about this thing!

I almost did, anyway. After the last test some time in July ended in one fan cracking its motor mount, fortunately not resulting in catastrophic failure, I lost my enthusiasm for flying objects and literally hid it under my cart of parts and stuff – as in, it fit perfectly between the wheels. I pledged that one day I will once again have a quadrotor boner and return to finish it off, since I did have a spare fan and all.

Well, I figured Thanksgiving weekend was as good as any. This year, MITERS seems to have accumulated a fair number of freshmen and newbies with quadrotors (and trirotors). The pressure was on to just finish it once and for all. It was a roughly 1 hour job to pull the damaged fan casing out and mount the spare, including printing a replacement tailcone.

noise isolation

During the testing of the Z-axis yaw rate control loop last time, I noticed a fair amount of mechanical noise coupling into the gyro readings. The gyros are mounted facing the same axis as the fans, almost in plane with them, and essentially on the end of a long carbon fiber stick. While the filtered readings were clean with stationary fans, they would become very erratic as soon as any power was applied. This was clearly visible in the test videos where the fans are jiggling quickly almost like they’re loose. The noise was of the same order of magnitude as the signal I was trying to get from the gyro – as a result, the filtering was not very effective. That was number one thing I was out to address before I moved onto the other axes of control.

I elected to remount the center Arduino Nano carrier board using memory foam – a tip I picked up from tricopter-nick, which is in fairly wide use.

With all 4 fans functional again, I was able to find out that the noise coupling was significantly lessened. It was still causing some trouble, but only when fan speeds were significantly higher than before – the “barely-touching-the-ground-hover” was mostly erratic jitter-free. Refactoring the yaw rate control code to not pre-scale the gyro readings also made the control less granular (and consequently even less shaky), and I also implemented a 2nd-order filter instead of a 1st-order. As a result, I was able to increase the loop PI gains by 2 times to yield a faster response to stick inputs. A little bit more driving on the ground like a doped-up robot on ice confirmed that the updates worked.

So now I was at the same external functionality I was 4 months ago. Yippee.

The only way I could get more data and test if the filtering and shock mount actually mattered was by continuing with the rest of the stability code.

how i killed the giant quadrotor

I hit the reset button on the Arduino. Actually, to be more specific, I left the controller calibration code in and then absentmindedly hit the reset button on the Arduino.

On occasion, I’d notice the fans peg off to one side and not respond to rudder stick inputs. They would some times recover again, but usually it required a power cycle to fix. I have a sneaking suspicion that my 2.4Ghz FHSS transmitter and the 2.4Ghz FHSS Xbee modules I had as a data link were Frequency Hopping over eachother’s Spread Spectrum at times.  Regardless, my usual rigorous procedure is to completely power down the electronics and then restart them.

The number one mistake was not commenting the calibration code out after the first time. After I temporarily decommissioned it the first time in july, I had “borrowed” one of the Turnigy 100A controllers for melonscooter. With melonscooter having moved onto greener melon vine patches,  I returned that controller to quadrotor duty, but it had to be recalibrated again.

The calibration procedure for these R/C controllers is full-stick within 1-2 seconds of powerup (2000uS pulse width), hold, then neutral stick (1000 or 1500uS, depending on your type of stick). This has to be done within 2 seconds of powerup, or else the ESC initializes and waits for command. The problem is when 2000uS is commanded after the ESC is already on and initialized, that means gun it.

For reasons I can only explain as “meh”, I elected after testing the yaw rate controller for the last time and seeing it lock up to just hit Reset on the Arduino to clear all the readings and start over, without powering down the ESCs. About 1 second after I did so, the stunning realization of idiocy hit me – along with the entire thing.

I only really remember leaping back as it flew upwards and sideways towards my head – keep in mind stabilization code wasn’t even written yet – and batting it out of the air with my left arm before ducking and turning around. It did a powered somersault over my head and crash-landed on top of a substantially more solid vehicle, and consequently shattered into many pieces.

It took me a second or two to realize what had happened, upon which I leapt for the big red key switches of main battery disconnection. The two remaining fans were still spinning – a consequence of me knocking over the radio – but luckily only slowly.

Pieces of fans were being collected from across the room afterwards – this destroyed rotor was found a few feet away with motor still attached.

I didn’t escape without damage. Batting the Deathcopter from the sky, I was grazed by what must have been a ducted fan leading edge:

In what is probably the luckiest near-miss I’ve ever been in, I’m only missing about 3 square inches of skin from my left forearm where the fan scraped it off. There’s 3 very evenly spaced cuts where I presume a rotor dinged me while disintegrating, but none were deep. Bleeding was slight, so the damage was cleaned, bandaged up, and ice-packed. It could have gone way more wrong in many possible alternate scenarios.  I’m still periodically testing my left hand fingers and wrist for full motion just in case.

What’s the lesson for other quadrotor builders who use RC controllers?

Well, besides don’t be a total dumbass and violate your own safety procedure,

calibrate the motor controllers once and cross it out of your code after.

This accident was totally avoidable if I wasn’t trying to rush to get to writing the stability controller.

Nevertheless, with 2 fans completely destroyed and the other two now in unknown condition possibly with structural damage, and the frame in many pieces, I think this project is done. Maybe I will instead concentrate on other flying things, or maybe I’ll build a more normal quadrotor or a tiny and cute one I can swat without worry.