pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

This looks really nice and clean! I'm eager to get a closer look at some crab pods at Nats... I have a couple questions about this design... First, how heavy is this pod, as shown? Second, what motor are you using to rotate the pod? Third, are you combining the rotating of the pods in any way? (i.e. each independently; fronts together, backs together; right side together, left side together, etc.) Congrats on the design, hope you guys can put it to good use!

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

The design allows several options to rotate the module. This year we will be direct driving the front two modules with the globe motors and we are pinning the rear two in place (I was overruled for full crab). This years robot can operate in basically two modes that the driver selects via joystick button, single/dual stick tank or true Ackerman. My plan is to test all possible modes after this season is complete. I'll post details when I return from Peachtree.

Note: I have a pretty sweet Ackerman vi that I'll post soon.

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

This is an awesome design. I have a question though, I have been designing some of my own crab modules, but a problem I have run into is wiring. How are you going to prevent the wires from getting wrapped around when your modules are turning?

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

Many solve this problem by limiting the rotation of the module, either through software, hardware, or both.

If I remember right from another picture of this module the silver piece on the left side of the bottom circle of the module is used as a a hardware rotation stop.

EDIT: Found the post here. The piece is indeed a hardware stop limiting the module to 320 degrees of rotation.

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

Although there are a few ways to optimize turning without ripping out wires, you never need anything over 360 of motion, it is overkill.(I'm not saying it might not be useful 1% of the time, but it dcertainly isn't necessary.)I've talked to teams including my own that don't even see it necessary to have much more than 180.

Many teams don't like coaxial swerve because of bevel gears and things, but coax is one way to avoid spinning wires.

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

"anything over 360 of motion is overkill"
not at all, you get a much better response time with full rotation, since worst-case for full rotation is 90deg (you can always find the closest goal within a max of 90deg), whereas the worst-case for non-full rotation is twice that.
also, with non-full-rotation, think of the situation where you're approaching the limit from one side. as you pass through the limit, the module has to turn 180deg (or however far), which makes for really weird driving. this problem doesn't exist with full rotation

for wire wrap, in 07 and 08 (when we did non-coaxial, with cims in the modules), we simply kept track of the number of full rotations, wrote them to the eeprom (persistent across reboots), and had a software limit in the number of rotations. the "unspinning" happened either on button press or automatically during idle time (no joystick inputs).

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

The other option is to go to a coaxial setup (unlimited physical module rotation with no wire rotation limits) using absolute encoders. This will allow you to spin to whatever you like, whenever you like, with no worries.

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

The whole reason I went coaxial was so the programmers couldn't break the drivetrain by spinning too far lol
with coaxial they can send whatever commands they want at it and all that would happen would be a bunch of random spinning at worst

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

yup, can't trust those programmers ;)

Re: pic: FRC-34 2009 Swerve Module w/CIM (Front View)
 

Oh, those silly programmers...It's always a code problem

But then again, without code, the robot is just a door stop...