Swerve Rotation Control

[aldaeron]

With the number of swerve designs and built swerves increasing, I am curious about older designs like the Wild Swerve (http://www.team221.com/viewproduct.php?id=93). In this design the motor rotates with the module, meaning that without care, the wires would get tangled and could break. I have not seen many great slip rings (yes there are some) for this type of design.

My question for those who have built swerves: For a design like this can you keep track of the total rotation angle since initialization and manage it in code? The steering motors seem like they can be geared to move quickly. An example would be that the robot has rotated +680 degrees and is still for more than one second, so the steering motor rotates two revolutions in the opposite direction to unwind to -40 degrees. This is the same heading, but the wires are much less wound now. Another scenario could be where you are at +1400 degrees and the command you give requests the module to rotate to +1440 degrees. Instead the module rotates a little farther the other way to +1080 degrees. Again - same heading, but less wound.

Would something like this be practical on a swerve? Seems like the module would only take a few more milliseconds to turn when taking "the long way" to unwind.

Would robot inspection allow this to pass (assuming a sufficiently long piece of flexible wire that cannot bind)

Thanks!

-matto-

[SteveGarward]

My question for those who have built swerves: For a design like this can you keep track of the total rotation angle since initialization and manage it in code?

Yes, you can and should. Going too far is obviously going to get you in to trouble, and as you've discovered, it's now a matter of tradeoffs. If you allow it to go past 360, how far do you allow? Rotation speed is important, as is knowing when to go back the other way or when to keep going. Encoder choice is important - absolute encoders run no risk of damage, but you have to track how many rotations you've done. Pots have an end point and you risk damage especially if they slip, but you can get a longer range. Having a mechanical stop if you wanted to for ultimate endpoints is hard with multiple rotations allowed.

This was exactly the decision we had to make when redesigning this year. I was happy to accept limited rotation - say either 270 degrees (and change drive direction when necessary), or 720 or so (enough to be useful most of the time). In the end, I saw the advantages in continuous rotation outweighed the small added complexity of limited rotation and the risks that can bring, especially to your cabling. (Of course it's all possible, but this was the choice we made.) It also gave us an opportunity to do something new (for us), for little extra effort.

The steering motors seem like they can be geared to move quickly.

This is the key I think. If you have an endpoint due to limited allowed rotation, you have to be able to spin them quickly. Driving full speed, making a slight heading change, and having your wheel modules unwind themselves while traveling 10+fps could be interesting to watch. :) Waiting until you have stopped may not always be practical. Imagine doing large circles on the field while maintaining robot orientation - how many circles can you do before having to unwind?

It's tricky. It can all be done, but like most things, it's all tradeoffs.