Different Swerve Drives

[CalTran]

Having read this as well as the pleathora of other threads explaining the pros and cons of swerve, and the 1625 whitepaper on their swerves through the ages, our team would like to pursue creating a swerve drive as an out of season project. No, this does not mean we are going to try and design a swerve drive for the 2013 season.
We are designing a swerve system so that our team will, should the need arise in the future for a swerve drive, have some first hand details on how to pursue a competition swerve drive.

That being said, we had a few questions that I figured ChiefDelphi would be able to answer.

The first and foremost question is the wheel modules and independence of each. As far as we know, there are some basic types of module. independence:
Chain all 4 modules together
Chain each side together
4 Independent modules

If we had to make the decision right now, we would chain each side's module together. Our reasoning behind this is because we believe this iteration is the "simpelest" method of swerve while maintaining some amount of maneuverability. As far as we have been able to tell, the added complexity of 4 independent modules for the added driving tricks added are not worth the time or research.
Is this the right decision? If you could provide personal examples or logical reasoning as to why independent modules are a necessity vs. keeping sides tied together than that would be appreciated.

Secondly, at CTTD this weekend I was fortunately to get a first hand look at 3928's revolutionary swerve drive modules. Between using their modules as a basis for design and buying a WildSwerve module from Andy Mark to use as a model (Blanking on who I saw that did this; been reading too many threads on swerve to remember what came from where) which would be suggested? I am leaning towards using 3928's swerve as a basis for design because it seems to somewhat help with keeping the weight of the modules down.

Thirdly, wiring. The obvious implication of swerve modules are that they are not infinitely rotating, due to the twisting of the power wires. What we would like to know is if it is possible to make one that would be infintely rotating, and how one would design for this. If not then how does one ensure that the position and rotation of the wheels are correct?

If this thread could be kept purely to the physical aspects of swerve that would be appreciated. There are plenty of threads and papers also describing the programming of said drive, and our programmers will visit them as necessary. Thank you.

[Jon Stratis]

Originally Posted by CalTran

Thirdly, wiring. The obvious implication of swerve modules are that they are not infinitely rotating, due to the twisting of the power wires. What we would like to know is if it is possible to make one that would be infintely rotating, and how one would design for this. If not then how does one ensure that the position and rotation of the wheels are correct?

I'll let others with more swerve experience respond to the other parts, but I can help with this!

What you're looking for is called a Slip Ring. These were permitted last year per R44.

Slip Rings are, generally speaking, fairly inefficient. You would be much better off limiting your rotation, and it would be technically a simpler solution, I think.

[Jon Stratis]

Oh, and to ensure position/rotation of the wheels, you'll want to have feedback on them. I would suggest a potentiometer - this can tell your code exactly which direction each wheel is pointing, and would be a bit simpler than an encoder.

[Alpha Beta]

In 2010 we loved using a mercury slip ring from Mercotac. I believe we had some donated. They were later outlawed that year and we switched to a twisting loop of wire and used software to keep track of how many twists we had undergone. I think recent rules have allowed for them again.

There were 3 swerve drive systems that I know of at CowTown. 16, 3284, and 3928. Aren Hill said they wouldn't be doing swerve again. 3284 is willing to, and thought they learned alot this year. They used purchased modules from AndyMark. This weekend they had one of the modules lose a physical connection to its encoder. After adding a floating sprocket to tension the steering chain the felt like they were ready to roll again. I can't think of the last time 16 didn't do swerve.

In 2011 1717 steered the opposite corners together, allowing them to create a diamond wheel pattern and spin in place to reorient. That would have been our next iteration had we continued with swerve.

[Alan Anderson]

You can completely avoid the problem of getting electricity to a motor that swerves with the wheel. Using coaxial shafts and bevel gears, you can keep the motors stationary and transmit mechanical power through the rotating parts.

[Aren_Hill]

Originally Posted by CalTran

Having read this as well as the pleathora of other threads explaining the pros and cons of swerve, and the 1625 whitepaper on their swerves through the ages, our team would like to pursue creating a swerve drive as an out of season project. No, this does not mean we are going to try and design a swerve drive for the 2013 season.
We are designing a swerve system so that our team will, should the need arise in the future for a swerve drive, have some first hand details on how to pursue a competition swerve drive.

That being said, we had a few questions that I figured ChiefDelphi would be able to answer.

The first and foremost question is the wheel modules and independence of each. As far as we know, there are some basic types of module. independence:
Chain all 4 modules together
Chain each side together
4 Independent modules

If we had to make the decision right now, we would chain each side's module together. Our reasoning behind this is because we believe this iteration is the "simpelest" method of swerve while maintaining some amount of maneuverability. As far as we have been able to tell, the added complexity of 4 independent modules for the added driving tricks added are not worth the time or research.
Is this the right decision? If you could provide personal examples or logical reasoning as to why independent modules are a necessity vs. keeping sides tied together than that would be appreciated.

Secondly, at CTTD this weekend I was fortunately to get a first hand look at 3928's revolutionary swerve drive modules. Between using their modules as a basis for design and buying a WildSwerve module from Andy Mark to use as a model (Blanking on who I saw that did this; been reading too many threads on swerve to remember what came from where) which would be suggested? I am leaning towards using 3928's swerve as a basis for design because it seems to somewhat help with keeping the weight of the modules down.

Thirdly, wiring. The obvious implication of swerve modules are that they are not infinitely rotating, due to the twisting of the power wires. What we would like to know is if it is possible to make one that would be infintely rotating, and how one would design for this. If not then how does one ensure that the position and rotation of the wheels are correct?

If this thread could be kept purely to the physical aspects of swerve that would be appreciated. There are plenty of threads and papers also describing the programming of said drive, and our programmers will visit them as necessary. Thank you.

You should have found me, so I could talk you out of it.

The advantages to the style of module we used this year were size and weight. It was also easy to mount to whatever frame system we chose, and it kept the COG really really low.

Its obviously incredibly custom and took a large amount of machining and assembly time, I was surprised at how well they held up for being a 1st generation swerve module concept.

You've nailed on one of the main issues with "CIM in module" setups, the wires (kinda annoying). If you can find a slipring that can handle the amperage of a CIM more power to you, it'll save you alot of grief if an encoder ever comes unplugged.

But the resource drain is enormous, and for that reason I do not see us pursuing it in the near future, I'd like to save some time for other parts of the robot so we can put on a little bit better show than this weekend (we were very very far from prepared due to other circumstances).


The technical learning benefits of doing a swerve on the other hand are enormous, from Concept to CAD to Machining to Programming to Driving, you learn an incredible amount due to the complex nature of the system and the level of performance you could potentially extract from it.
For that reason pursuing a prototype in the offseason is fairly okay, just be watchful of the "man this is so cool we should do it in build" as I've embarrassingly fallen victim to it so many times before, with varying results.

[ajlapp]

Motor in module swerve systems are limited in the amount of rotation you can achieve.

That said, if you run the wires directly through the pivot point and properly strain relieve the wires on either side of the joint I feel confident you could have multiple rotations without damage to the wires.

It's also not unreasonable to think that you could manually unwind any module between matches that appeared to need attention.

[Siri]

Originally Posted by CalTran

If we had to make the decision right now, we would chain each side's module together. Our reasoning behind this is because we believe this iteration is the "simpelest" method of swerve while maintaining some amount of maneuverability. As far as we have been able to tell, the added complexity of 4 independent modules for the added driving tricks added are not worth the time or research.
Is this the right decision? If you could provide personal examples or logical reasoning as to why independent modules are a necessity vs. keeping sides tied together than that would be appreciated.

We use fully independent modules primarily because it provides more turning options, including spinning and snaking in both orientations. I don't think snaking in both orientations in most games, though we did use it this year: long for barrier crossing and some defense and wide for ball and bridge manipulation. Spinning can be valuable if you don't have a turret, though. As always, you should look at the stationary turning radius of the drivetrain you choose.

/..\
\../ ... Spin

/../
\..\ ... Snake

Originally Posted by CalTran

Thirdly, wiring. The obvious implication of swerve modules are that they are not infinitely rotating, due to the twisting of the power wires. What we would like to know is if it is possible to make one that would be infintely rotating, and how one would design for this. If not then how does one ensure that the position and rotation of the wheels are correct?

As Alan said, you don't need slip rings or wires rotating at all. All you need are power take-offs to transmit drive and steering rotation co-axially. We do it with one belt each, plus a set of bevel gears and a chain for each drive, 8.6lb each. (FRC 1640 Pivot Modules 2012)

[Ether]

We use fully independent modules primarily because it provides more turning options, including spinning and snaking in both orientations.

/..\
\../ ... Spin

/../
\..\ ... Snake

I suppose you could do the above two motions with the left and right sides chained together for steering if you added an extra gear on each side to change the front/rear steering directions. But you'd sacrifice crab motion.

[Secretspy97]

Thirdly, wiring. The obvious implication of swerve modules are that they are not infinitely rotating, due to the twisting of the power wires. What we would like to know is if it is possible to make one that would be infintely rotating, and how one would design for this. If not then how does one ensure that the position and rotation of the wheels are correct?

Yes it is possible for a wheel to spin limitlessly.

This is a CAD picture of a swerve module:


And this is a CAD picture of our entire robot's drive frame:


We mounted the CIMS next to the module and then connected a chain from the CIM to the smaller shaft on the module. The CIM controls the motors speed. We then attached two window motor to two sets of swerve modules, (one window motor for each side) by chain, in order to turn.

If you would like to just move around the field and have the robot facing the same wall for the entire match then 2 motors controlling steering (one for each side) works great. But if you want to be able to turn the robot, then you might want to think about changing to 4 motors steering. (one controlling the rotation of each wheel).

[Cal578]

You could have one motor steer the left side, and another to steer the right side. When you turn both of them 90 degrees, you get crab drive.
|..|
|..| = Forward

/..\
\../ = Spin

/../
\..\ = Snake

-..-
-..- = Crab

Crab requires independent drive motors on the four wheels, since the rear wheels are aimed the opposite direction of the front wheels.

[CalTran]

As soon as I get the project write up done I will post it to CD as a white paper and y'all can have at the critiques.

Originally Posted by Jon Stratis

Oh, and to ensure position/rotation of the wheels, you'll want to have feedback on them. I would suggest a potentiometer - this can tell your code exactly which direction each wheel is pointing, and would be a bit simpler than an encoder.

We figured if we can't get infinite rotations in then a pot would be the simplest method for checking rotation. We've had experience with them (Logomotion arm and our use of a pot won us Rockwell Innovation in Control award at Greater KC)

Originally Posted by Alpha Beta

In 2010 we loved using a mercury slip ring from Mercotac. I believe we had some donated. They were later outlawed that year and we switched to a twisting loop of wire and used software to keep track of how many twists we had undergone. I think recent rules have allowed for them again.
In 2011 1717 steered the opposite corners together, allowing them to create a diamond wheel pattern and spin in place to reorient. That would have been our next iteration had we continued with swerve.

Two things about this post:
1. Slip rings. We looked into the wikipedia, and we think we understand how they work but if someone could give us a somewhat more simple explanation for us to check against that would be appreciated.
2. How would one go about steering opposite corners without using a motor per corner? We would like to keep things chained together for sake of simplicity, but with the talk of simplicity on the other side of complexity, if one can justify using individual motors but programming them as 2 motors (ie utilizing a pwm y cable) then we'll take that. I imagine that if we do use individual motors but code them as 2 then it might make a transition to full individuality simpler.

Originally Posted by Alan Anderson

You can completely avoid the problem of getting electricity to a motor that swerves with the wheel. Using coaxial shafts and bevel gears, you can keep the motors stationary and transmit mechanical power through the rotating parts.

We've thought about using bevels or miter gears before to transfer power but the calculations and precision necessary aren't exactly something our team are known for.

Yes this sounds somewhat counter intuitive to creating a swerve drive if we can't pull off something extreme, but we think that if we can keep the swerve drive as simple as a swerve drive can get then we might be in the clear.

Originally Posted by Aren_Hill

But the resource drain is enormous, and for that reason I do not see us pursuing it in the near future, I'd like to save some time for other parts of the robot so we can put on a little bit better show than this weekend (we were very very far from prepared due to other circumstances).


The technical learning benefits of doing a swerve on the other hand are enormous, from Concept to CAD to Machining to Programming to Driving, you learn an incredible amount due to the complex nature of the system and the level of performance you could potentially extract from it.
For that reason pursuing a prototype in the offseason is fairly okay, just be watchful of the "man this is so cool we should do it in build" as I've embarrassingly fallen victim to it so many times before, with varying results.

As far as the resources go, our school district is fortunate enough that research projects get a somewhat substantial budget, though it isn't quite a black budget. As long as we can minimize the cost and we're not attempting to buy the moon we're alright.

As far as the technical learning benefits, that is one of the reasons we would like to pursue this. Myself and a few other kids are in a pilot FIRST Robotics Engineering class, and with CowTown over (Our only off season), we're looking for something to do each day for 2 hours until season.

This being said, we are also going to do a project write up for a 6 or 8wd that may be used in season. Should it be necessary I will open another thread with similar purpose to this thread about that drive. Also note that should we only be able to do one project, the 6/8wd project will take precedent over this project and swerve will be shelved as a theoretical project.

[CalTran]

Originally Posted by Cal578

Crab requires independent drive motors on the four wheels, since the rear wheels are aimed the opposite direction of the front wheels.

We intend on each wheel having independent drive motors. We're just a little shaky on the rotation motors and whether to chain rotation together or one motor each, or some weird combination (ie 1717's opposite corners). Whichever CD deems the best will be what we pursue.

[Siri]

Originally Posted by CalTran

1. Slip rings. We looked into the wikipedia, and we think we understand how they work but if someone could give us a somewhat more simple explanation for us to check against that would be appreciated.

What they do
Small cylinders with wires protruding from both faces: you hard put them along your wire runs at the stationary-rotating interface of your swerve modules. One side's wires turn; the other side's stay still.

How they do it
The classic version (I think they're all like this?) and simplest way to think about it is that each stationary wire has a little brush on the end. Each brush sits on a metal ring which can rotate while still allowing the signal to transfer.

Does that work?


Ether: Good point. That'd be pretty neat!

[CalTran]

I'm back with another question/update on our process. During the mechanical design write up of this project, a mentor and I conversed about the decision to chain sides together - and he suggested we attempt full independence. His reasoning is that the long chain runs that would be necessary would be invitations to the chain hitting something then skipping. Another thing he brought up not previously thought about was the investment of space necessary to chain sides together. I also believe we will be doing Co axially driven pods, as the infinite rotations and gearing would be somewhat advantageous.