Some things to keep in mind-
A crab/swerve drive is not the only kind of omni-directional mobility base. The following is taken out of an email I sent to my team during the 2008 season.
(Note this email was sent in 2008: carpet was present and we could use any wheels we wanted. CAUTION: HEURISTIC REASONING BELOW. Do not flame me for inadvertently "attacking" a design of yours.)
"Omni-Directional chassis are really cool
Mecanum
http://www.chiefdelphi.com/media/photos/30101
1. Easy to build, one motor on each wheel.
2. Accelerates slowly, wheel slippage can be a problem
3. Has trouble climbing ramps (have heard reports of slipping to weight-biased when climbing an incline)
4. Straight strafing is a function of even weight distribution upon each wheel.
5. Can be pushed around easy due to minimal traction
Verdict: I dislike them. Defensive robots will have trouble with the wheel slippage and offensive bots are easily defended against on these wheels.
Holonomic
http://www.chiefdelphi.com/media/photos/29534
1. Easy to build, one motor on each omni-directional wheel
2. Accelerates well, no wheel slippage (in the inline direction)
3. Seems like it only works on flat surfaces. I doubt they could climb ramps with any substantial incline.
4. Uneven payload distribution on robot seems like it would not affect strafing as much as it does on the mecanums.
5. Can be pushed around (852 coded an anti-pushing response on their robot though.. but there's only so much that the motors can do to compensate.
Verdict: I like them in every way except the fact that they can be pushed around.
Swerve/Crab
http://www.chiefdelphi.com/media/photos/31078?
1. Hard to build, must construct individual swerve modules, a motor power plant, and a mechanism to steer the pods two by two.
2. Accelerates well and perfectly straight! (all four wheels are powered simultaneously from the same power plant)
3. Can climb ramps just as well as any other four-wheel chassis (assuming ground clearance is high enough)
4. Will always strafe straight assuming the steering motors are calibrated correctly.
5. Will stand fast in the face of being pushed. No omni-wheels are needed, robot always has good traction.
Verdict: It's the proper emulation of an omni-directional chassis. I like every aspect of it except it's complexity.
Take a look at the link of the swerve chassis. The entire frame is made from stock. We could, theoretically, configure our own stock chassis and have meadows (our machine shop) only machine the powerplant's gearbox and individual swerve modules. The machined parts will be considerably smaller, but more intricate. How does one of the swerve modules work? http://www.chiefdelphi.com/forums/showthread.php?t=64824&highlight=tumbleweed"
AGAIN: that's soft logic above! I have never worked with a holonomic or a mecanum drive-train before, so do not quote me on anything.
These thoughts stem from the perceptions of a somewhat-astute observer.
After you're through digesting that, consider my team's design of a crab/swerve drive this year:
http://www.chiefdelphi.com/media/photos/32573
The four wheels are all driven from a single toughbox (that's not ideal because there's no differential). Steering is done by two different motors. The front wheel modules are steered separately from the rear two. This allows the robot to make turning arcs, like a "warthog car" if the wheels twist in opposite directions. If you sync the twist rotation of the rear steering motor with that of the front steering motor, "crab-like" control is available. The robot will face a singular direction while "strafing" around. In this game, crab mode allows the robot to "orbit" the trailer.
Our experience with this told us that assembly was the easy part - control gets really complicated.
For instance, forget about TWO steering motors if you can't close a position loop around them. Without a proper feedback system they will turn at different rates - which isn't good when you want to sync the two motors for any sort of integrated control at all - warthog car or crab.
Also, decide whether or not you want the wheel modules to twist indefinitely in any one direction. If you do, then you disallow the use of a potentiometer to sense your rotation because they have a twist limit. You're going to have to use a rotary encoder (or something) instead - which brings up even more problems, like alignment. The encoders that AM gives us are not absolute encoders (they don't know what 'forward' is), so a separate sensor system may have to be implemented to position your wheels straight. You can simplify this a little by using absolute encoders which can give you a displacement from a zero point, but software may still get funky if you choose to change your sprocket/pulley/gear/whatever ratios between your steering motor and your wheel module.
What's the point? Control gets difficult. Again, this is what I have observed on my team - I'm not saying that you will run into the same suite of problems we ran into, AND I'M CERTAINLY NOT SAYING THAT YOU MUST SOLVE THESE PROBLEMS EXACTLY LIKE WE DID.
Just note that fabricating the drive-train is only half of the challenge, controlling the drive-train is something that is often over looked like red-blooded mechies like myself.
A taste of software development:
http://www.youtube.com/watch?v=3w00MbJMeIw
I think it's great if your team wants to try something new next year (getting locked into a routine design isn't stimulating... and it's not FIRST), but you would really manage your risks if you prototyped the thing - both the mechanical scheme and the control scheme. For design guidance: I suspect most users on Delphi would point over to CraigHickman and his posted CADs.
Best Regards,
Sam N.