Something Like Flight

After a day of tweaking control loop settings, I've been able to fly 4pcb for at least several seconds at a time before crash landing or hitting a wall. I tried out two different control loop styles, PD control and nested angle/rate control. It's hard to tell from the video which one looks more promising. I want to say the PD control led to longer, more stable flights, but that was also earlier in the day and I was a bit hyper from coffee, so that may have had an effect.

Proportional-Derivative (PD) control would be my first instinct for stabilizing a quadrotor, since it deals directly with the two physical quantities at hand, angle (P), and angular rate (D). Each term gets multiplied by a constant, or gain, and then the sum is sent out as a command to the relevant motors. For pitch angle, the front and rear motors are used. For roll angle, the left and right motors are used. The control structure is straightforward:

The proportional term acts like a virtual spring, pulling the quadrotor back to zero angle (or whatever reference angle the joystick commands). The proportional gain (Kp) is like the spring constant, setting how stiff the virtual spring is. The derivative term acts like damper, resisting motion in either direction. The derivative gain (Kd) sets the damping constant, how viscous the virtual damper is.

With proportional gain only, the quadrotor (which has rotational inertia) will oscillate like a mass on the end of a spring. With derivative gain only, the quadrotor won't know what angle to go to. But with both, it returns to the proper angle and settles there with minimal oscillation. Choosing the exact right gains is often a matter of tweaking. A lot of tweaking.

If there is a net external torque on the quadrotor, for example due to an off-center C.G., it may also be necessary to include an integral control term that ramps up the motor command over time. With this, one motor would spin faster even when the quadrotor is level, canceling out the net external torque. Then the structure would be that of a full PID controller. I've left the integral term out for now.

There's another subtlety: because the motors and props have inertia, they can't instantly spin up to the commanded speed. The sensors, microcontroller, and ESCs also have built-in delay. So, if the gains are too high, the simple model breaks down and the quadrotor will just oscillate. This type of oscillation tends to be faster and twitchier than the proportional-only mass-spring oscillations. So yes, even more tweaking.

After tuning the PD controller for a while, I got a tip from David B. about www.openpilot.org. Now, I'm usually more of a do-it-myself-and-ignore-everyone-else's-version person, but the quadrotor loop tuning guide on openpilot is truly excellent. The video especially is really, really well done. Props (lolpun) to the creator, who can also be seen here demonstrating my ultimate goal for 4pcb, a frisbee launch.

The openpilot control loop uses a different structure, which I would call a nested or inner/outer control loop. The inner loop controls (angular) rate, and the outer loop controls angle. Both the inner and the outer loop contain a proportional (P) and an integral (I) gain, but for simplicity I will leave out the integral term.

What happens in this case is that the angle error gets multiplied by a proportional gain, Kpo, to create a desired rate. The desired rate goes into a second proportional gain, Kpi, to create the motor command. There  integral terms would come in at each step, one in the outer loop and one in the inner loop. Though the documentation suggests using only one of the two possible integral terms. (In the video, both are explained.)

So, I tested this loop structure as well. In both cases, I left out the integral terms and I tweaked the gains until I was satisfied that I was getting the most stable flight I could. The values I get for PD control were Kp:1.2 and Kd:0.4. The units are a bit funky. Starting from degrees or degrees per second, these gains give you a motor command from 0 to 255. So, a 10º error would give a motor command increase of 12/255. A -20º/s error would give a motor command of -8/255. 

For the nested loop, I settled on Kpo:4.0 and Kpi:0.5. Kpi has the same units a Kd from the PD controller. Kpo, though, is now in (deg/s)/deg. Confused? Well then now might be a good time for the plot twist.

They're actually the same thing.

When you ignore the integral terms, anyway, the two different control structures are actually equivalent. Kpi is Kd and the product of Kpi*Kpo is Kp. I didn't know this while I was testing, so the fact that I settled on slightly different gains (0.5 instead of 0.4 for Kpi/Kd and 4.0*0.5=2.0 instead of 1.2 for Kpi*Kpo/Kp) is probably due to the coffee. Interestingly, the gains I settled on are not far from the suggested gains on openpilot, when you convert to their unit scheme.

When you add in the integral terms, though, I think two control structures do have important differences. I couldn't exactly tell you what they are, but it's an interesting thing to think about. Since the main problem I'm seeing now is drift, integral control might be an important part of making it fly better. So that will be one of the things I'll be testing next. Along with that:

• Landing gear. As suggested by Max H., I'll be trying out some nylon standoffs on the four corners. If nothing else, it will help keep the quadrotor level during takeoff. It also might minimize the motor damage on slight-to-moderate crash landings.
  
  
• x-configuration. I've been using +-configuration, where forward is in line with one of the four appendages of the quadrotor. But when I think of a quadrotor, my mind sees x-configuration, where forward is halfway between two appendages. I don't know why. Also the openpilot video demonstrates x-configuration. The only possible technical advantage I can think of is that all four motors are involved in both pitch and roll, so perhaps any individual motor anomalies will be averaged out more. Or that might just be total BS.
  
  
• Flying with a gamepad instead of a joystick, as suggested by Ryan A. Reaction time and precision may be improved with something more closely resembling a normal RC transmitter.
  
  
• Supply voltage offset correction. I'm not sure if this is actually a problem or not, but the analog-to-digital converter references all signals to the supply voltage. If there is some deviation in the supply voltage under load, the zeros may drift. The gyros have a reference voltage that can be measured to correct for this offset, so I may at least test that voltage to see if its ADC value is varying under load. If it is, I can scale the other signals to compensate.

I would eventually like to be able to fly it in a small room. Whether I get there by tweaking the control or by practice, I don't really care...

Hurricane Special: Navbar Updates + 4pcb's First Hops

I'm camping inside today due to the remnants of Hurricane Irene, which came up to the Northeast this weekend.

Isn't this what Boston looks like normally?

Anyway, it's a great time to make some major long-overdue navbar updates. 

Most importantly (seriously) I added a bit of dynamic content that tells me if the large brushless motors (codename: melons) have come back in stock at Hobby King. It should be right around here -------------------------->

Turns out Hobby King  has a web API that you can use to do everything from check inventory to pull up tracking numbers for specific orders. I've been habitually checking the site every day to see if any new motors have been released, because they are out of stock on almost every motor larger than 55xx. I think they're working on a new line of motors that will replace things in the 63xx size range, like the ones on tinyKart, but I also have hope that the 80xx (melons) will return. So, rather than scrolling through the site every time, I can take a quick glance at my navbar to see if any are in stock! I made a static page with the melon checker as well.

I've also added new links to other awesome project sites right about here --->

I hadn't updated my links in such a long time that I feel bad for leaving out so many awesome blogs, such as that of Transistor Man and fellow battery abuser Dane Kouttron, combat robot and electric vehicle builder extraordinaire Jamison Go, and potentially (lolpun) the most frightening underclassman ever Tyler C. of TC-Engineering (or does TC stand for Tesla Coil?).

Lastly, the project pages have been shuffled and updated:

• Since there are now two electric go-karts, Cap Kart and tinyKart now share a new high level page. I don't know if I'll ever build another electric go-kart, but just in case, I now have a project category for them. (Or maybe, now that I have a project category, I have to build more...)
  
  
• I added DirectDrive to the Motor Controllers page.
  
  
• I actually populated the Self-Balancing Things page which has been a dead link for several months now. I've determined that the internet is an infinite Segway sink, so I can keep making silly balancing robots/vehicles and people will actually want to see them. Not sure why. But anyway, now there is a page for them.

That's it for the administrative updates, on to more interesting things:

PCB Quadrotor!

I'll admit, I rushed through this build without posting any updates, so this will be a little on the long side. I got the board from Advanced Circuits (www.4pcb.com) early last week. It's $33 for a two-layer board with silkscreen and soldermask, routed to any shape you want (including quadrotor shape). The first thing to go on was the Toshiba TB6588FG sensorless driver chip:

It's not the easiest chip to solder, but it can be done by hand. I managed not to put it in backwards. I decided to solder up just one ESC and its supporting passives so that I could test it with the tiny 5g motors to see if it would even work. I had to also put on the Arduino Mini before I could do so, but that didn't take very long.

Very quickly I ran into one of the problems that I was expecting: the TB6588FG datasheet mentions a commutation frequency limit of f_osc/(3*2^11) in the context of a protection feature that shuts down the drive if you exceed this limit. But, it doesn't mention what happens if you turn off the protection feature. I figured the possibilities were either that (1) it would work, (2) it would limit the frequency, or (3) it would explode. The actual answer was (2):

Speed limiting at about 800Hz (3 pulses per cycle).

The tiny 5g motors are actually very, very fast. Not only do they spin at about 14,000rpm, but they have 16 poles, so the electrical frequency in Hz is 14,000/60*8 = 1,867! Under load, I thought I might need at least 1,600Hz. So, I tried overclocking the chip by changing its oscillator resistor from 20k to 10k. This bumped f_osc from 5MHz to 10MHz.

And the speed limit goes up to 1,600Hz (3 pulses per cycle).

This seemed to work just fine. It will also double the PWM frequency, but I chose the lower of two options, so it's no worse in terms of switching losses than the higher case with 5MHz. I'm not sure how much more you can push f_osc, but it would be an interesting experiment to try. Other than that, the ESCs work well. The start-up routine is dubious, and seems to be designed for much slower motors. But they seem to be able to find sync on these motors even starting in the run state. Once spinning, they are able to change speed quickly and smoothly.

Confident that the Toshiba chip would do the job, I filled in the remaining three and then mounted the motors:

Copy-paste, copy-paste, copy paste.

Motors mount with 2-56 machine screws.

The motor leads are just long enough to reach the pads.

And when all the parts are together:

The total weight, including a 7.4V, 500mAh LiPo battery, is 125g. This is just a bit over what I predicted, but then again I was using a slightly different battery for that estimate. Each 4x2.5 prop should be able to generate at least 50g of thrust, so it can still fly. The yellow electrical tape is for balancing the props, which, for $0.40, were not very good to start with. It also helps for visibility and avoiding finger contact.

I put together some quadrotor control software (yes, in Arduino..) based heavily on the previous quadrotor project I was involved with. It uses a complementary filter on each axis to calculate pitch and roll angles from accelerometer and gyroscope signals. The angle and rate then go into a Proportional-Derivative (PD) controller that attempts to keep the quadrotor level and stable. Yaw is handled by a simple proportional controller that applies a differential signal to the counter-rotating props. The input for the control is done through my stock RC solution: a USB joystick and XBee radio modules.

Once I had something close to flyable, I did a few test hops:

You can see the control loop still needs a good amount of tuning. But the test hops also revealed a few other problems that I'll want to fix as well. For one, it could really use some landing gear. And I'm not just saying that because it currently crash lands on its LiPo every time, I don't really care about that. But taking off is actually the most difficult part, because it's not very stable in ground effect. Having four solid points of contact would help a lot at keeping it level during take-off, I think. Right now, the only real solution is to gun it and get it off the ground as quickly as possible, hoping it stays level enough to fly.

The other major problem I encountered was that, even though the props survive crashes very well, the motors are not as durable:

After several hits, the cans started to detach from the faceplates of a couple motors. They are held on only by a press fit with a short interface. Once the can comes off, the motor locks up. To attempt to fix this problem, I've been adding superglue to them as they come off. It would also help if I would stop crashing it.

Mostly, though, I think the flight can be improved with control loop tweaking. I'll be playing around with the P and D constants, to start with. The control loop is currently running at 100Hz, which should be fast enough to stabilize the system, but it's possible that there is some unaccounted-for lag in the motor control or sensors. The tradeoff seems to always be between oscillation and drift. Higher gains cause more overshoot and oscillation, but do a better job of holding it level. Lower gains are more stable, but it flies away in one direction or another. Finding exactly the right combination is frustrating, since it also depends on your ability to trim and fly it. So, hopefully with more tweaking and practice, I'll get it to the point where I can legitimately call it "flying".

tinyKart: Round 5

tl;dr tinyKart works:

It ran outdoors for the first time at Swapfest, our de-facto vehicle debut venue. This time, tinyKart and Charles Guan's Straight RazEr were revealed to the world crazy swapfolk. It took a while to get there, as evidenced by the greater-than two week gap between tinyKart posts. But here's where I fill in that gap. When we left off the kart was mechanically complete, minus the steering wheel.

Problem solved.

The angular butterfly design courtesy of Max H. fits very nicely with the overall aesthetic of the kart, plus it's all 1/8" aluminum plate welded to thin-wall aluminum tubes, so it weighs less than a pound. For various reasons I can't quite say how this nice thing came into existence. But did you know that Amy Q. is awesome? Just sayin'.

The steering wheel is very important on tinyKart. It holds all of the driver inputs; there are no pedals. The two front disk brakes are controlled by cables which go to a really awesome double pull lever I found on Amazon. We had some issues stemming from unequal length brake cables (different amounts of friction). But a trip to the bike shop for two new 48" cables solved that problem. The throttle is a trigger from an RC car controller, and it really does work like an RC car. (Pull to go, push to brake, push twice to reverse.)

One interesting consequence of having no pedals is that you can put your feet wherever you want...

...

One other minor mechanical detail came up during the week: the drive pulleys which attach to the motor shafts had been bored out to 10mm, but that left very few threads for the set screws. As a preventative measure, I took the four prop adapters that came with the motors and pressed them into the even-more-bored-out pulleys. The Frankenpulleys are held together only by a 0.003" press fit and large quantities of retaining compound, but I still think they're better than the stock ones.

Before attaching the pulleys to the motor shafts, I filed small flats on each side for the set screws to grab. The other side of the pulley attaches to a 10mm aluminum idler shaft that runs in a bearing in the outer plate of the drive module. This way, the pulley is supported on both sides and motor shaft incurs less bending moment, all of which helps my MechE side sleep at night.

And with that, all that remained was a crapload of electronics work. The first step in that process was to mount the batteries and the motor controllers. Up until we thought about it hard enough to realize that nobody should sit in between two 3lb LiPo batteries, the plan was to put them along the sides of the kart. But it turned out that the two batteries and the controllers fit nicely in some space behind the seat. To isolated them from mechanical shock, they are attached to a separate 1/8" aluminum plate floating on left-over BWD wheel urethane:

But weren't BWD's wheels stupidly hard?

If you feel the seat warmer kick in...GTFO!

This is the second time I've used giant "long pack" LiPos on a vehicle. The first was Pneu Scooter's maiden voyage in Singapore. To be honest, they scare me...and I am not easily scared by batteries. I am used to the potential for 1,000A short-circuit currents and the precautions that go with that. I know how to monitor cell voltages and protect the pack from damage. But all I can think about with these is how far away I need to be if the battery starts spewing flame in all directions.

Tangential thought: I think I will spend some time in the near future making a 12S3P A123 pack for tinyKart. To keep the same weight while switching from LiPo to LiFe, some capacity must be sacrificed (273Wh instead of 333Wh). But I could make a couple of packs and swap them. And as much as we fret over the safety and liability of having loose cells and homemade battery packs lying around, I still feel safer that way than with these giant LiPo bombs that I can buy freely on the internet.

Finally, a good load test for eBay Hack Charger #7,523. Set at 41.0V cutoff and 5.0A, it would take almost two hours to fully charge the batteries. They arrive about half-charged, so this was a good one-hour full power (200W) test of the Vicor brick power supply I built. Seems to hold up just fine. And no fiery LiPo death yet.

Thank you,  Cell Loggers, for giving me at least some peace of mind.

With the batteries and controller mounted, the wiring could begin:

The wiring for this kart wasn't nearly as bad as Cap Kart. For one, the primary wiring could be done with double 10AWG instead of single 2AWG. So, the hammer crimper was not required for this one. Each battery gets its own 60A fuse. Then, the two positive wires come together inside a master switch, which has a precharge circuit bypassing it. Chris C-T. decided to put all of this inside the master switch, because that's just what he does.

A switch within a switch...

The master switch needs to be easily reachable by the driver, so it is attached to the right 80/20 frame rail:

The rest of the primary wiring was easy. Well, I shouldn't say that, because it turns out that the 5.5mm bullet connectors on the batteries are not that same size at the 5.5mm bullet connectors I bought... So, a couple hours of tense giant LiPo connector surgery were necessary. But other than that it was easy. The signal wiring, on the other hand, took a very long time.

Cue wiring montage...

Each Kelly controller needed a total of 12 signal connections: 5 for the Hall effect sensors and 7 for the throttle, brake, reverse, and diagnostic signals. The Hall effect sensors ride on a laser-cut acrylic mount (a la Pneu Scooter) that holds them just off the motor can, at the proper electrical angle. The cans on these motors are thin enough that the magnetic field is easily picked up from outside; no need to bury the sensors in the motor windings. The acrylic mount is tangentially adjustable so that the motor timing can be fine-tuned after finding the proper combination of wires. The process by which this happens is a matter for another entire post, but generally it's sufficient to set them for minimum current at a given throttle position.

Throttle, brake, and reverse are controlled by a sophisticated central vehicle processor Arduino that intercepts the throttle signal from the RC trigger and decides what to do with it. The Arduino reads in the trigger analog input and generates four PWMs which are low-pass filtered, buffered, and set out to the throttle and brake sensor inputs on both Kelly controllers. Ted G. and Catherine C-T. set up this fancy throttle interceptor to capture the brake/reverse function of the trigger, but also because we want to implement steering angle-based differential torque on the two motors. Future feature, once the steering potentiometer is installed. 

As it turns out, regenerative braking will also have to wait for some minor modifications. The Kelly controllers can use an analog brake signal, but apparently they still need their digital brake switch pulled low at the correct time for the braking feature to work at all. So, there will actually be 8 signal wires for each controller, one of which may not be zip-tied to the nice wiring harness that was already made.

After a week of wiring, we finally got a chance to test drive it this weekend. Here are the two videos:

8/20/11- Maiden voyage in N52.
8/21/11 - Outdoor testing at MIT Swapfest.

So, one year to the day after Cap Kart v2.0's first successful test drive, and three years after Cap Kart v1.0 first touched pavement, we made it back out to our favorite strip of trackside delivery road. This time, though,  we didn't need four people and a pick-up truck to get there. One person can easily tow tinyKart with two wheels on the ground, and two people can carry it for a long distance. It also fits in elevators and through doors.

d'awwwwww

The test drive validates some of the mechanics of tinyKart: The 17mm aluminum wheel axles seem okay, the brakes and steering work as they should, and the frame holds itself together. In the video, you can see that the chassis does flex, a lot. You can feel it in the seat. But it's not the kind of flex that will break things - more like an airplane wing flapping a bit because it's just an aluminum truss. Interestingly, it keeps all four tires on the ground.

There are definitely still some weak points, some of which we knew about and some of which were revealed in this test drive:

• The left side motor can is loose and has a tendency to shift axially, once to the point of binding so hard that the entire rotor shifted, changing the motor timing. The only question is: repair or replace?
  
  
• Both controllers exhibit a well-know problem of cutting out under heavy load (80A?). This seems to be common with RC outrunners running on Kelly's. I've seen it at least twice before. Since I pretty much spend all my time debugging motor controllers anyway, I can probably find a quick fix. If not, there is a higher PWM frequency option for Kelly controllers that could be worth a try. (The inductance on these motors is so low that the current ripple at 16kHz is still large.) If nothing else works, tinyKart may some day be merged with DirectDrive...
  
  
• The weight.

The current weight is just under 55lbs. To get down to the target of 53lbs (less than one of Cap Kart's old lead acid batteries), we will have to do a bit of trimming. The current weight already represents the first major cut - the side seat mounts that Max put so much effort into had to go. We were worried about whether the rear seat mounts by themselves could handle high cornering forces, so we did a quick 1G turning test:

Removing the side seat mounts only saved 0.85lbs, though. To cut an addition 2lbs, we will have to take small bits off of several places. Some easy targets are the belt tensioners, the front of the frame, and a few of the lateral 80/20 braces which could be swapped for lighter box extrusion. After that maybe we'll drill some holes in the LiPos to reduce weight...

In the meantime, a bit more test driving may be in the near future. Also, exciting news: We will be bringing tinyKart to NY Maker Faire in mid-September. Look for it there!

4pcb: A Printed Circuit Board Quadrotor.

I know I have too many project tags open right now, but this is one that I just couldn't resist:

Lately I've seen a number of things that almost fly, and they reminded me of a project idea that I put in the queue a long time ago: a printed circuit board-based quadrotor. Fiberglass, like the FR4 used in PCBs, is actually a pretty nice structural material - lightweight and stiff. So why not integrate the electronics and the structure into a single printable frame? I named it "4pcb" after the URL for Advanced Circuits, where you can go to print your very own. (Though now that I think about it, Myrocopter would have been a cool name, too.)

I've actually helped with a quadrotor before:

It was built by high school students as part of the Edgerton Center summer engineering class in 2010. You can see the details in this Instructable, the first and for some time only Instructable on how to build a quadrotor. (Credit goes to June K. for the write-up.) This one has a pulltruded carbon fiber frame and is built mostly from Hobby King parts. It uses 7" props, two right-handed and two left-handed, and is controlled by feedback from gyros and accelerometers. 

The nature of the control system is what appealed to me about building a quadrotor, and I pretty much drew it up from scratch the way I knew it would work. The internet does have a lot of good and bad information on the topic, all of which I skipped over. But if you're new to this game you might want to read some of the following:

• The basic idea, and why you need counter-rotating props.
• My surprisingly well-traveled white paper on the angle estimating filter.
• Sensors and filtering sections from my other Instructable.
• Code and tuning sections from the quadrotor Instructable.

Props to Welkin U. for translating my ranting into workable code for the Edgerton quadrotor - it did in fact fly stably, if only for about 10 seconds at a time. I think with a bit more work on the yaw control, and a lot more pilot training, it would have been almost easy to fly.

Anyway, now I want to build a small one.

I settled on a 4" prop (4x2.5) and pretty much the tiniest motor that Hobby King sells, the HXM1400-2000. Despite its size, this is a 12-slot, 16-pole brushless outrunner.

Yes, 16 poles!

And it is an incredibly nice little motor. The build quality seems a lot higher than other tiny motors I've seen, including the ones from our last quadrotor. For example the can does not feel like it's going to separate from the motor and fly away under load. The prop adapter that it comes with actually fits the prop, and the whole assembly (motor and prop) weighs only about 10 grams. With the 4x2.5 prop and a 7.4V supply, reviews suggest the thrust will be about 50 grams.

And I've somehow made it several paragraphs into a post without talking about motor control yet. Well, I can fix that. I was browsing for a piece of enabling technology: an integrated sensorless control IC. There are plenty of cheap, small brushless ESCs on Hobby King and elsewhere, but what's the point of a PCB quadrotor if I still have to zip tie ESCs to it? Also, there's a fundamental bandwidth limit with RC ESCs due to the ~20ms gap between servo PWM pulses. We definitely battled with this limit on the Edgerton quadrotor, and a smaller quadrotor will need an even faster control loop.

So, I was very happy to find this:

It's part of Toshiba's line of small, integrated motor control chips. The TB6588FG is the brushless version. They contain both the power and the signal electronics, so it really is almost like having an ESC on a chip. You do have to add a few passives.

Okay, a lot of passives.

But still you get a sensorless ESC in about a 1"x1" PCB footprint with no wasted weight for packaging or heat sinking. It has some features you wouldn't get on a cheap RC ESC too: analog speed input (very high bandwidth), adjustable frequency PWM, adjustable timing, over-current protection, and some others. But there are also a few drawbacks: It's designed for higher voltages (7-42V), so running it off a 7.4V battery is borderline. It also may have issues with the extremely high electrical frequency of these motors. The datasheet mentions an optional commutation frequency limit, but doesn't say what happens when you turn the limit off. Only one way to find out.

Since I'm working in EAGLE, I have to live within the constraints of the 100mmx80mm board size limit. That's one of the reasons I put this project on hold originally - I figured I might have to go back to FreePCB or some other layout program to do it. But recently I remembered that the board size limit only applies to placing components. The free version of EAGLE will definitely let you create a board outline (dimension layer) and even traces that go outside the limits. So, I just had to place all the components in the 100mmx80mm dashed rectangle in the title picture, which has the origin at its lower-left corner.

After laying out a single ESC block, I just had to copy-paste three times and - oh right, this is EAGLE, FML.

As it turns out, even the already convoluted process of copy-pasting a group of components and wires in EAGLE is not enough to get you through this one. If you do so in the schematic, an unorganized batch of new components inserts itself into the bottom-left corner of your board. If you try to do so in the board, it just yells at you. A combination of Googling and random screwing around got me to a workable solution:

1. Close the board file. This breaks the link that automatically inserts new components into the board when you copy-paste schematic groups.
   
   
2. Copy-paste the group in the schematic. If you don't know how to copy-paste groups in EAGLE, you might want to figure that out first.
   
   
3. Open the board. It will now yell at you because the board and schematic are not consistent.
   
   
4. Copy-paste the group on the board. Make sure the board group contains exactly the same elements as the schematic group. (Same components and nets.)
   
   
5. If you have not re-named any nets, or used any power supply nets, then you are probably done. If you have, go on to Step 6.
   
   
6. Power supply nets and user-named nets copy properly on the schematic, but not on the board. On the board, GND becomes GND1, VCC becomes VCC1. USERNET becomes USERNET1, OTHERNET1 becomes OTHERNET2. It either appends the number 1 to the name, or if there already is a number, it increments. Depending on your intentions, you may have to change the net name on either the schematic or the board. Usually for power supply nets, you'd be renaming the board nets to GND, VCC, etc. But for user nets, you may actually want the automatic number incrementing. In that case, you can update the schematic net names appropriately. The ERC shows the inconsistent nets. Once you have cleared all these, you're done. Unless...
   
   
7. The numbered nets (N$1, N$2, etc.) should increment properly on the board and the schematic when you copy-paste. But, I found that if you have extra nets on the board that are not present on the schematic, it offsets the net numbering on the board. For example, the 20 motor mounting holes I had were numbered N$25 through N$44. They were not represented by anything in the schematic. So, to avoid the problem, I had to rename all the nets associated with these isolated vias so that there were exactly the same quantity of numbered nets on the schematic as on the board. Only then could I successfully execute Steps 1-6. So maybe this is actually Step 0.

And after all that:

Three hours to copy-paste three instances. WHY!?

Now that I know how to do it, it would probably only take me five minutes or so to copy-paste a block of this complexity in the future. And I'm not sure I can blame EAGLE, since it does do a reasonable job of re-syncing net and component numbers, or at least telling you when it makes a mistake. But dammit, there must be a better way!

After that adventure, routing the few remaining signals was easy. I opted for an Arduino Mini this time, just due to the space constraint. The sensors are on a Sparkfun Razor 6DOF IMU, which I would link to but Sparkfun seems to have discontinued it within the last day or two. I've got a few buffered, but it does bother me that they're ditching the only analog-output 6DOF board, and that I will have to rework the documentation for this and other projects that relied on this part.  >_<

For wireless control, an XBee radio module is hidden on the bottom layer. These have become my standard for custom RC, one of the building blocks I can rely on to just work. The XBee link has several advantages over normal RC Tx/Rx systems. First, it is not constrained by the 20ms servo PWM  period, so the control bandwidth can be higher. It can have bidirectional data transfer, which is useful for debugging and real-time data visualization (virtual quadrotor!). And since the other end of the XBee goes to my laptop, I can control it with any USB HID controller.

The full layout is in the title image above, and in high-res here. Lead time on the boards will be about 10 days, so the next update will be in a couple weeks. Back to tinyKart...

tinyKart: Round 4

I've been preoccupied with Robocon, the International Design Contest which this year is hosted at MIT. But somewhere in the past week we found some time to complete the rolling chassis on tinyKart. The tires came in, so this was the moment of truth for the custom aluminum frame. And as you can see in the video above, it actually rolls (past the unfortunately copper-deficient LOLrioKart). The chassis itself weighs only about 40lbs, so we were quite happy to see it handle the full weight of a driver and not simple bend in half.

The tires are 8"x2" pneumatics with tubes from ElectricScooterParts. They're certainly not for racing, but they are remarkably light, which is the point in this case. They are high-pressure (70-80psi) so they roll very well, though the ride may be a little rough outside. We will probably run them closer to 60psi since we have four points of contact with the ground and they're normally used on scooters with two.

Other than that, the only addition here is a Vise-Grip steering wheel. That will soon be replaced with a custom job. One interesting thing about tinyKart will be the hand-based throttle and brake (no pedals). More on that to come when we install them, but I think it will be incredibly fun to drive. 

A few more pictures of the substantially completed chassis:

Slackermann steering geometry at work.

More 80/20 for the steering column support.

Thin as a razor blade...

Convenient storage position.

Next up: Electrons. Thousands of them. Actually thousands of billions of billions of them...per second.