Arduino HexBridge Shield v2.0

This is what I meant to do the first time.

Recap: I have lots of motor controllers. Some of them work, others do not. But they are almost all based on a combination of MSP430 microcontrollers and a totally isolated, totally modular gate drive solution. Recently I've been feeling the pressure to create a more...populist...solution, which basically means putting it on an Arduino shield. So that's what I did.

Even though v1.0 was a total failure, it gave me a chance to refine the design in ways other than making it not go crazy as soon as it was under any load. I had some extra time to sit around and think about exactly what I would want in an Arduino-based motor controller. Well, not what I would want, but what one would want...you know. ;) Here is the important functionality that I was targeting:

Six semi-independent MOSFET half-bridges. I say semi-independent because each set of three shares a single PWM output. So, at most it can control two motors. But these could be brushless (3-phase) or brushed motors (H-bridge). You can also put channels in parallel for higher current capacity. There should be a simple state selection for each bridge: PWM, low, or float:

This leaves a ton of flexibility, and only occupies one I/O pin per phase, plus the two PWM pins. The "float" state is important for BLDC control or for disabling a phase entirely. I talked about some of the possible configurations in the previous post. On to the new board:

The FETs are the same (IRFS3107 or IRFS3207 or any other D2PAK), but they are arranged differently this time. All the high-side FETs are on the top, and all the low side FETs are on the bottom. This let me move the entire power section out off the side of the board, away from the Arduino and the logic. To conserve horizontal space, I switched to 12-13mm vertical capacitors. They can face up , or down into what will likely be dead space next to the Arduino main board.

Speaking of dead space, I stuffed the DC/DC converter input and output capacitors in the gap between the arduino USB port and power jack and moved everything out of the way of a potential ProtoShield above the whole stack:

Tetris win. Isn't the Arduino supposed to disappear now or something?

Also, the whole board is 2.1" wide now...the width of the Arduino main board. So it is much more compact than the original version. Here's what it looks like all wired up:

Form factor aside, DOES IT WORK? I made some major changes to the gate drive, switching over to the IR21844 integrated half-bridge driver. This is a wonderful chip that automatically handles synchronous rectification with shoot through protection. It also has separate signal and power grounds that can float within ±5V of each other. Because of this, I abandoned optical isolation of the PWM signals for the first time in two years. This worried me, but it seems to work just fine. The ancillary benefit is that the old gate drive, which cost about $15 per half-bridge, is replaced by a $2.50 chip.

To execute the truth table I specified, it needs a bit of supporting logic, in the form of AND gates, comparators, and inverters, but these are dirt cheap. The cool part is the high-Z detector, a window comparator that checks to see if each selector pin is being driven:

If the input pin (which enters from the top of that schematic) is not being driven high or low, it will be pulled to 2.5V by the matched resistors. This is between the threshold of the window comparator, so the output will indicate the high impedance state, and the gate drive for that phase will be disabled. To get to this state from the Arduino, you just set that selector pin as an input.

I started by testing it as an H-bridge with a low-current DC motor, but I quickly got bored and scaled up:

 

This is the SepEx configuration that I described in the previous post. Three of the six outputs are tied together to power the high-current armature winding. Two of the remaining outputs are configured as an H-bridge to control the field. Reversing the field changed the direction of rotation, so the armature need not be reversed. The test motor is from the Cap Kart, which is getting a makeover soon. It's a wheels-up test, so the loads are fairly light (20A armature, 10-15A field current). None of the FETs got warm over the course of testing. If I had a legitimate way of doing current feedback, I would actually put it on the ground and drive it. But for now it's just a demo to show the flexibility afforded by having six output channels.

So, since I have no intention of making more or selling these it's up to you to make them! Here is probably everything you need:

HexBridge Shield Design Files (ZIP, 779kB)

In that folder you will find the schematic, EAGLE files, bill of materials, Gerber files, state table, and sample Arduino code for running the SepEx motor. I would especially like to see a brushless motor controller next...and I have a feeling it will happen very soon.

Arduino Hex-Bridge Shield: Concept and v1.fail

So, I guess I am finally coming to terms with living in a world where Arduino rules. If you've been living under a rock, an Arduino is an AVR-based microcontroller development board with an array of peripherals, a huge library of code, and a large user base. They have become a staple of DIY projects and "Arduino compatibility" of DIY hardware is now a legitimate concern.

I'm faced with two options, then. One: I could continue to rant about how I designed most of my current TI MSP430-based hardware to do everything the Arduino does, but better, and how the Arduino is not a replacement for learning how to design circuit boards and program microcontrollers directly. Or, two: I could drink the Kool-Aid and make something useful that also happens to sits on top of an Arduino.

Cue the Hex-Bridge Shield. (Scientific name: Large Arduino Switching Shield with Field Effect Transistors.)

Here are some pictures of v1.0, a failure for reasons which I will discuss below:

Hex-Bridge, Top Side: MOSFETs.

Sidecap.

Hex-Bridge Bottom Side: Gate Drive.

Okay, so calling it a shield is a bit of a stretch. It doesn't really sit on the Arduino so much as the Arduino sits under it. (Can you see where?) It's pretty compact for what it is, though: six semi-independent, high-power MOSFET half-bridges, with all the gate drive circuitry included. Each bridge was a version of my modular half-bridge design, which I've used in every motor controller I've built for the last two years.

The gate drive is based on a design we originally did for the Cap Kart long ago. Each FET gets its own 2.5A gate drive optocoupler (HCPL-3120). An optocoupler passes a signal through an LED and photosensor (packaged in a single chip) to electrically isolate a circuit, which is useful for protecting the microcontroller from high power switching noise. These particular optocouplers are designed to drive the gate of a MOSFET, on when the LED is on, off when the LED is off. By arranging two LEDs in anti-parallel and including a low-pass filter, passive shoot-through protection for each bridge is achieved.

One high-level half-bridge schematic.

Notice how the LEDs are arranged so that only one can be on at any given time. Also notice that the low-side gate drive optocoupler is fed by an inverted signal. This creates synchronous rectification, mirroring the PWM on the low-side to minimize diode losses and allow regenerative braking. This is just a high-level schematic, leaving out details such as the shoot-through delay filter and the gate resistors and protection components. But it should give the general idea. One down side of this method is that it requires a separate high-side supply. This makes it expensive (about $15 per bridge for all the gate drive components, which is more than the FETs themselves). Integrated half-bridge drivers such as the IR21844 provide a less expensive solution. v2.0 will use these.

The MOSFETs are IRFS3107 surface mount packages. They have a typical Rds of 2.5mΩ. (For reference, that's about the same as one foot of 14AWG copper wire.) These are monstrous 75V FETs that can, with proper heat sinking, probably handle "high-double-digit" currents. Throw a fan on and I don't even want to speculate how much current you could pass through it.

IRFS3107 Output Characteristic. 

0.2V at 85A...way better than an IGBT.

Everything on the board is sized for an input voltage of 18 to 48V. On the input, there is 990μF worth of 63V electrolytic capacitors. (These could easily be replaced with 50V or 35V capacitors of higher capacitance for lower-voltage, higher-current applications.) An LM2575HV switching regulator provides 15V @ 1A to power the Arduino and the gate drivers.

An here's where the failure comes in. Take a look at an Arduino. (I know you have one.) All of the digital signal pins are on the top row of headers, but the +5V, VIN, and GND pins are on the bottom row. I made the horrible mistake of running lone +5V and VIN lines from the LM2575 and the logic ICs, around the entire high current switching board, to the bottom headers. Bad bad bad bad bad bad. I can't even describe how bad it was.

By eliminating those traces and running an external connection for +5V, GND, and VIN, I was able to eliminate at least the most dramatic of the failure modes. While in this hacked state, it was able to run 20A continuously through a single phase with just natural convection. The resulting FET temperature was about 90ºC. Extrapolate as you see fit for a current rating with paralleled FETs, heat sinking, and/or fans.

So it has the potential to work, but in terms of a board design, this one is total scrap. Version 2.0, which is already in the works, will be better in every way. (Smaller, cheaper, better mechanical and thermal layout, easier to stack additional shields on.) But since I have nothing much to show for it yet, I can only tell you the design intent:

It would be great if the Arduino had six completely independent high-resolution PWM channels like some chips do. Then you could control two brushless motors. You could even do sinusoidal field-oriented control! Well, maybe not. But anyway, it would be cool if this shield could be used to control two brushless DC motors using square wave drive, at least. With six phases to play with, that should be possible. The trickiness is in multiplexing the PWM signal from Arduino pin 9 and 10 out to each set of three phases. Thinking about NAND gates makes my head hurt, but fortunately I got some help in coming up with a creative solution using an analog switch:

Chuxxorplexer

Actually, the real key is using one selector pin to completely control each bridge, including being able to disable it. This is where tri-stating comes in. If the selector pin is driven high, the relevant PWM from pin 9 or 10 is ANDed in and the bridge executes synchronous rectification. If the pin is driven low, the low-side FET is steady on, grounded that phase. If the pin is set as an input (high impedance), neither FET is on and the phase floats. This allows full four-quadrant control while still preserving the "off" state. Don't ask me how the analog switch accomplishes all that in one shot...but it does. Just stare at it until it make sense. That part totally works. This is what comes out of the magic box:

Digital pins 2-7 are used to select a state for each of the bridges. The bridges are labeled {A, B, C, U, V, W} from left to right. Each bridge can have one of three states:

• When its state pin is written HIGH, the bridge executes synchronous rectification based on the PWM present on pin 9 for A, B, and C, or pin 10 for U, V, and W. This means the high side FET will be PWMed with a duty cycle set by analogWrite(9 or 10), while the low side FET does the opposite.
• When its state pin is written LOW, the low side FET of the bridge will be steady on and the high side will be off. This is effectively like grounding that phase. The PWM does not matter.
• When its state pin is set as an INPUT using pinMode(), it will turn off both FETs and the phase will float. This is useful for disabling the controller or for the undriven phase in BLDC control. Note that even in this state, diode flyback can occur.

Unfortunately, the Chuxxorplexer won't make it into v2.0, which uses a different gate drive configuration entirely, but the functionality will be preserved using a much less elegant brute force set of logic chips. The important thing is that the three-state control in the table above will be preserved. This is, IMO, the cool part, giving almost complete flexibility of bridge configuration for one or two motors.

Here are a few examples:

 Monster H-Bridge

The monster H-bridge can be achieved by setting {A,B,C}={1,1,1} and {U,V,W}={0,0,0} for forward, or {A,B,C}={0,0,0} and {U,V,W}={1,1,1} for reverse. This parallels three bridges to make a super half-bridge, then combines two super half-bridges to make the full H-Bridge. This gives the highest current reversible control with regenerative braking.

Dual H-Bridge

The dual H-Bridge, also known as the drive controller. This can be used to drive the left and right sides of a tank steer robot. Since each bridge only uses one FET per leg now, the current capability is lower than the single monster H-bridge. To get this configuration, {A,B,C} = {1,0,X} or {0,1,X} for forward and reverse and {U,V,W} = same idea. X means that the unused phase is set as an INPUT, left floating. Hey, why not use the two unused phases to make a third H-bridge? Because there are only two PWM channels. Sorry. But the next one should be obvious...

Hey now...

The dual-channel BLDC controller, something I've seen before somewhere. Basically, you would cycle through every permutation of {1,0,X}, one phase driven, one grounded, and one floating. Except now you're on your own for how to achieve electronic commutation. One idea would be to use the floating phase and an analog pin to do back EMF-based sensorless control. Another idea would be to use Hall effect sensors and interrupts.

Monster Half-Bridge

The monster half-bridge, also known as the weapon or spin controller. It can only go in one direction, but it parallels all the MOSFETs for the highest possible current capability. This is actually not a "safe" configuration, since it is possible (and likely) to shoot-through from ABC to UVW if the PWMs are not in sync. To get this configuration, use only one PWM, 9 or 10. Set the other as an input and tie them together with a resistor. If you don't do this, instant destruction will occur. Along the same vein, there is also a monster BLDC controller configuration that ties A to U, B to V, and C to W.

Lastly, my favorite configuration: the SepEx controller:

SepEx Controller

This combines a super half-bridge with a regular H-bridge. The super half-bridge controls the high-current armature winding of a separately-excited DC motor. (By the way, don't bother reading the description of the SepEx motor's regenerative braking method on that page...it's totally wrong.) The smaller H-bridge controls the low-current field windings, allowing the field to be varied and reversed. Now, I don't want to pretend that this controller is powerful enough to drive a D&D SepEx motor under full load...it's not. But conceptually it can be configured for the SepEx by using {A,B,C} = {1,1,1} and {U,V,W} = {1,0,X} or {0,1,X}. Actually, don't I have a SepEx motor somewhere that I can try this with?

Oh right, there it is.

I'll leave off with a teaser for v2.0:

 Can you spot the layout improvements?

Pirate Radio Control: HK123's and Field Weakening

It's nice out, and I'm done with finals, so I took out the RC car again and made a few improvements. Then I crashed it and undid some of those, but don't worry it's not too bad!

First, I changed the batteries. I had been using A123 26650 cells. These are LiFePO4 cells that are most abundantly found in 36V DeWalt drill batteries. In fact, since they are virtually unavailable to the general public, the cheapest way to get them is actually to take them out of drill batteries. I'm sure there are significantly more 36V DeWalt drills than there are batteries for them at this point. Each pack contains 10 cells, and can be found on eBay for roughly $100, so about $10 per cell. Wasteful...and still expensive.

A less expensive solution is lithium polymer. Sites like Hobby King sell these pouch-like batteries for more like $5 per cell, for an equivalent capacity. They're 3.7V nominal, instead of 3.3V, and they come in prismatic packs, so overall they have a higher energy density than LiFePO4. The 30-40C discharge versions are comparable in power density as well. The one downside is that they tend to burst into flames when abused...

A compromise, then. Hobby King also makes LiFePO4 prismatic batteries. (We call them HK123s now.)

HK123

For $70, you get 12 cells. That's just under $6 per cell. Now, these packs are decidedly hit-or-miss, based on the reviews. They might arrive with one or more cells completely dead. In fact, the one I ordered had two dead cells. :( But since I was going to cut it open anyway, I wasn't too upset. Taking the packs apart is a real pain, but I don't imagine it is significantly harder than taking apart a DeWalt battery. One snag I ran into was that the positive terminals are aluminum crimped to nickel tabs. I ripped off the nickel, not realizing its importance, and had to resort to aluminum soldering to connect the cells. (Yes, you can solder aluminum.)

Questionable soldering job.

I rearranged the cells into 6S1P, same as the old RC car pack. Putting it together is easier than putting together cylindrical cells, which almost makes up for the difficulty of taking it apart. All the balance and power leads come out of the same side, and it makes a nice compact package that is easy to heat shrink. Or, if you don't have any heat shrink, caution tape...

Notice the size difference.

The cells themselves are almost the same weight as A123 cells. (They should be, being the same chemistry and capacity.) So I only saved 122 grams (6% of the total car weight), mostly in packaging. But since they are prismatic, they stack nicely and take up much less volume. I measured their internal resistance to be about 13mΩ, which is a little higher than an A123 cell but not much. I fully expected it to be able to handle the 40A peak current on the car. Here's what it looks like on the car:

 

 

Step two in the RC car upgrade was implementing field weakening control. Setting up the full explanation of field weakening would take one or two whole posts, so here I will just get straight to the point. The car uses half of my 3ph Duo brushless ESC, which is a fully functional AC controller that treats everything as a vector in the rotor frame of reference. The voltages applied to the motor are balanced three-phase sine waves, which leaves only two degrees of freedom: magnitude and phase. 

Under normal operating conditions, the controller sets the phase wherever it has to to place the current vector right between the magnets, using feedback control. This is the point of optimum torque production, the least amount of current for the most amount of torque, and varies with speed and load due to inductance. The magnitude then just sets the magnitude of torque.

In field weakening, the controller sets the phase ahead of the normal operating point. There are many ways to think about what this does. In one way of thinking, part of the current vector is now opposing the permanent magnets a little, weakening the field that the other part of the current vector interacts with to produce torque. This reduces the back EMF of the motor, allowing it to spin faster at a given voltage magnitude, but with less torque. It effectively changes the motor constant, almost like an overdrive gear. Hey now, where have I seen this before?

I wish I could provide a more thorough analysis of the field weakening capabilities of this controller, but in all honesty it gets a little messy. For one, the unit frequency that the controller uses to do all its calculations is the PWM frequency, which is 14.5kHz. With the motor now spinning at 45,000rpm, or 750Hz, the resolution of everything is shot. Furthermore, lag in the measurements starts to become significant and the rotor frame may not even be in the right place anymore. This controller was designed for direct-drive scooter motors that spin at 1,000rpm...so I'm happy if it doesn't go unstable at this speed.

Time for testing! Here's the baseline, a normal "full-throttle" acceleration with no field weakening:

It gets from 0-30mph in 1.9 seconds, pushing about 34A (peak) to the motor. The top speed is 34mph and the peak power output (to the ground, m*a*v) is about 200W. Notice that by the time the motor has hit top speed, the voltage phase is a full 42º ahead of where it would be at no load. This keeps the current right between the magnets, lined up with the back EMF, for optimum torque. At this phase angle, the power in to the terminals of the motor is about 330W. So from the motor terminals to the ground, a system efficiency of 61% at peak load.

Now with field weakening:

The acceleration profile up to 30mph is identical, taking about 1.9s. Then, at 30mph I hit the "boost" button. The controller tries to put some current on the axis that fights the magnets (negative d-axis). It does so by advancing the phase to 75º, sacrificing current on the q-axis (torque producing current) to get there. So, the acceleration slows, but it can get to a higher top speed of 44mph. Maybe you just need to see it:

 

That ant-looking thing is the car. The sound is probably the more useful measure. With this kind of motor, field weakening is fairly limited, but a 30% increase in top speed without changing anything other than software is still much appreciated. That is...until you hit a pebble at 42mph...

Unfortunately, I do not have video of the crash, but I do have the car's last transmission:

Black box.

Clearly I had half a second to attempt to slow down and regain control. I probably needed another half second to do so, though, because it still hit the curb at 27mph. This time, something happened to the radio before the battery came out. (You can tell because the voltage never drops.)

Yep, antenna got ripped out. 

 That might be fixable with some solder. The brand new battery did indeed fly out as well, landing several feet away. Here's the aftermath:

Not right.

But even the bashed-in cell is okay.

That's a big check in the durability box for the HK123's, if you ask me. The only thing that really broke was a tab on one of the cells. And it wasn't the aluminum solder joint; the tab just sheared off completely. Good thing I have four spare cells from the original pack.

The car itself was totally fine.

So in summary:

• HK123s are a viable and fairly rugged LiFePO4 solution, if you don't mind disassembling and reassembling a pack. More compact and less expensive than A123.
• Field weakening is cool, until you hit a rock.
• I should find a wider test location.

Super Mean Well: The Scooter Fast Charger

Disclaimer: Do not try this unless you are very comfortable with the concepts and dangers of battery charging. I am pursuing this as an experiment, not advocating it for general use. Attempt at your own risk.

A while ago, I had the idea of repurposing large LED power supplies as battery chargers. The premise is that both use the same output characteristic. That is, they will apply a constant current or a constant voltage, whichever is lower. For batteries, the constant current is applied first and supplies most of the charge. Then, when the applied voltage reaches a certain threshold, the voltage remains constant and the current ramps down. If you don't understand how this works, you probably don't want to work with batteries anyway.

Mean Well makes inexpensive 100W LED power supplies (presumably for commercial lighting) under the PLC-100 line. They are roughly the size and weight of laptop power supplies and are available in a range of voltage outputs, up to 48V. They have a constant-current and constant-voltage trim pot that allow adjustment within a limited range around the nominal output. They retail for about $65 and are available from several electronics distributors including Mouser.

I have been using the PLC-100-36 to charge the batteries on the BWD scooter for some time now. The scooter battery pack is lithium iron-phosphate. (Note that these are generally safer than other lithium-ion chemistries, which is why I am more comfortable using a non-standard charger.) It's a 33V, 4.4Ah pack (equivalent to two 36V DeWalt drill batteries). I set the constant current to 2.2A, so it's a C/2 charge, meaning it would take approximately two hours to fully charge the pack.

There is obviously no balancing circuit (though I did try to make one). It's important that the cells be well-balanced before charging and that the voltages be monitored in case one starts to peak early. Cell voltage monitors are widely available, for example this one and this one that also balances. They will not automatically cut off the charger, though, so constant observation is required. (Generally a good idea for battery charging anyway.) For general use, an integrated charger/balancer such as this takes care of all the monitoring and cutoffs. The downside is that for most of these RC chargers, you still need a bulky front-end DC power supply.

Though it is compact, inexpensive, and plugs directly into the wall, the 100W Mean Well supply falls short of the RC chargers in output power. So I was very glad when I came across the new HLG-240 line. This is a 240W version of the Mean Well LED power supply that retails for about $130. It comes in a compact (but dense) aluminum enclosure with wires already attached. Here's the HLG-240-36:

And for scale, here it is next to the scooter:

It's not as light as the 100W version, but it's still something you could see carrying in a backpack. And just like the 100W version, it plugs straight into the wall. This particular model has a voltage trim range of 33.5-38.5V and a current trim range of 3.3-6.7A, a good match for the scooter battery pack. Other models offer other ranges. (Be careful: Only the model with the "A" suffix are adjustable!) And here it is doing its thing:

With a maximum output current of 6.7A, this supply can now charge the scooter pack in about 45 minutes (~1.5C). Whether or not this is practical or necessary, I don't know. I've never had a case where I absolutely needed to charge it in less than an hour. But it's interesting to know that the capability exists for about the same cost and size as a laptop power supply. (Okay, this is a little bigger than a laptop supply.) I still don't recommend it for casual use, since it doesn't implement balancing or voltage monitoring. But if somebody made an small adapter that did these things, I could see it being a good, inexpensive solution to small EV charging.

Twitch, the part where I try to build something.

Twitch (or, Twitch, Jr., since the original Twitch was much bigger) is finally underway. (I decided it would be a good idea to finish writing my thesis first so I could graduate.) It should be a relatively quick project, especially considering that I got most of the important parts sent out for water jet cutting.

Mail-order robot.

Actually, this is the first time I've tried to make a drive like this, with so many moving parts. Here's a quick reminder of what it should look like:

Both sets of diagonal wheels are coupled by parallelogram linkages. The two wheels on each side can also be coupled by a cross link as well, though with two linkage drive servos this is not entirely necessary. The most critical pieces are the bearing blocks that support each wheel and motor module. These are made from Delrin for low friction and ease of machining. There are a total of eight, for four wheel modules:

Four identical wheel modules, mounted in the corners.

The bearing blocks sit on aluminum posts, hopefully aligned correctly between the top and bottom plates. With the two diagonal linkages in place, the wheels can be moved in pairs. Normally, both pairs will be moved together to switch between the "long" and "wide" orientations.

 "Long" orientation (top) and "wide" orientation (bottom.)

Besides these two orientations, there are other possibilities. One is to put all four wheels at 45º. Another is to put one set "long" and one "wide." Since they are omni-wheels, either of these would be capable of full 3DOF movement. If the cross links are used to couple the two diagonal sets of wheels, the range of intermediate wheel positions is more limited. Needless to say, this project will become an exercise in input mapping and control at some point.

For now, though, there are still a few mechanical details to work out. After the first assembly, it's clear that there is a bit too much friction in the wheel module bearing blocks for the servos to drive the linkage. They were made to be fairly tight, for stiffness, but after seeing it in real life I think I would trade a little slop for less friction. Unfortunately, this linkage gives the servo the least amount of mechanical advantage at the extremes, so if the bearing friction is constant, the servo sees the most torque at these points. I'm crossing my fingers that it's actually the wheels, driving against each other during the transition, that can create the torque for overcoming this friction. (Again, why does everything converge to a controls problem?!)

Next step is creating hubs for the Vex 4" omni-wheels that allow them to attach to the gearmotor shafts. Then, wiring and programming. Okay, so it wasn't quite a two-week job, but it's progressing.

2.00thesis

Design and Prototyping Methods for Brushless Motors and Motor Control

Actually you should read James Mevey's thesis instead.

Twitch, Jr.

Guess what? I'm actually going to build something that isn't a motor or a motor controller. It's been a long time since I actually built a robot, but seeing a fair number of 2.007 robots coming to life makes me want to execute a good old-fashioned two-week robot build. Okay, so I'm not really going to build a whole robot, just a drivetrain. That's all I was ever good at, anyway. I've built many different types: 2WD, 4WD, 6WD, skid-steer, tank treads, mecanum wheels. But I've never built a linkage drive! What is a linkage drive? It's this:

This is the drive from FIRST Team 1565's 2008 robot, "Twitch...the missing link(age)." I am not affiliated in any way with Team 1565; I just think their linkage drive is awesome.

It doesn't have complete...uh oh time to make up a word...holonomicity? In other words, it can't go in any arbitrary direction at any time like mecanum wheels or a swerve drive. But it can rapidly swap between two perpendicular directions of travel, which is very practical. It has omni-wheels, but only just to allow it to turn and swap axes smoothly without skidding wheels sideways. Consequently, it can coast into turns as it swaps axes, which I think makes it incredibly fun to drive.

So, I'm going to make a (small) linkage-drive robot. Here's a quick video of the linkages in action:


 

Sorry for the awkward cropping...click the full-screen icon for a slightly better view. For a sense of scale, those are ~4" wheels. (They are really these awesome Vex omni-wheels, but I'm too lazy to add the rollers into this existing wheel model I found.)

Top View

The four identical wheel+gearbox+motor modules are mounted in plastic bearing blocks that rotate on upper and lower posts. The two long, diagonal links do most of the work, linking opposite corners to each other so that diagonal wheels are always parallel. The short links (one of which is redundant) couple the two sets of diagonal wheels in a strange and somewhat frightening way. (Frightening in that it comes kind-of close to singularity at the extremes.) That's why I left open the option of using two servos to drive the two diagonals independently. But in theory the entire mechanism has just one degree of freedom.

The gearmotors are 36mm, 20:1 BaneBots planetary sets. The controllers (shown as nondescript green blobs) are Pololu Trex modules. The structure is mostly an aluminum sandwich, with the plates and links being cut with an abrasive water jet. And yes, I sent the parts out despite the fact that MIT has seven waterjets on campus now. Cue rant: Of the seven, only one is open for general use and it's not currently working...plus sending it out is fairly cheap, believe it or not. (If you don't happen to go to a school or work at a company that likes to spend money on underutilized and difficult-to-maintain machine tools, here's one good place that will cut your cool robot parts quickly and cheaply.)

Future robot.

More parts arrive this week, so I should have a robot by next week. If you're wondering about the control...I have no idea how to do it yet. But I'm not really worried. I'll write it in Visual Basic just to annoy everyone. Shouldn't take that long. (Really.)

I just feel like there's something else I'm forgetting to do...oh right my thesis!