# Different Swerve Drives

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.

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.

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.

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.

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.

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.

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.

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

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)

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.

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).

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.

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.

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)

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.

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.

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.

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.

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!

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.

As long as you have enough motors in the kit I would recommend going with the independent steering. It is mechanically simpler, and allows faster change of modules.

After doing swerve for 3 years, I strongly agree with MICHAEL that independent steering modules are the way to go. Swerve has many more failure modes. Having chain runs all over the robot is a night mare to work on at a competition in the pits. Our swerve modules require the removal of 4 bolts and disconnection of 3 pairs of wires to remove a module. We can remove and replace a problem module and get on to the next match. Repair it later. Doing swerve is going to increase the complexity of the robot. Try to minimize the added complexity.

Cal,

I am excited to hear the team is interested in taking on a challenge like this.

Knowing the resources that 2410 has and an idea of the teams other
constraints like, money, time and talent. I would say look closely at how 973 does their swerve. What I think is really nice is that each swerve section is it’s own module that is then bolted to the frame. I believe this method is something that is easily visualized, delegated and tweaked. Build 4 identical modules and a box frame with a plywood electronics board. Very solid testing module.

If you need any help, you know how to find me. Good luck!

-Jeff

P.S. send me CAD

Edit to add:
Cimple gears paired with 4 inch wheels seem to make a really nice combo.

Update 11.8.12

After evaluation, the team has decided to do coaxial rather than distributed. With deliberation between our programmers and me, it was decided that working with an extended travel potentiometer is much simpler for them to do rather than working with an encoder. (Coding will most likely be done in C++, for those wondering.) Our decision is thus because we believe it will be easier in the future to switch to an encoder from potentiometer once we decided we would like more than one rotation. However, some more deliberation will be had once we can get in touch with some of our mentors from Rockwell Automation.

Also, at Jeffy’s advice, I went over to FRC Designs and have dissected the Emperor Swerve corner module.
One of the things I am wondering about after looking at this design is how to design for the rotation. From what I can see in the CAD file, the wheel module is set inside a steering bearing and this is what allows for the wheel to rotate. Correct?

As well, we believe that the frame of our testing bed will be 80/20 extrusion, with the modules designed to slide on and off of the frame. As well as testing Swerve Drive on the platform, we will also look into a well-designed 6/8 wheel drive that could be slid on to the platform, so as to consolidate pricing of off season prototyping.

As a last point of note, when teams do fabricate the modules, how many are created? Four would be the minimum* (No spares), and I suppose the cap would be where you want to stop spending money on creating modules. Are two extra modules a happy medium to stop at? That would mean that we would need to fabricate six total modules.
*Note, Bomb Squad’s three wheel swerve is excluded from this analysis.

*Edit: http://www.chiefdelphi.com/forums/showthread.php?t=107569&highlight=Emperor+Swerve has shed some light on the various mountings and bearings necessary for rotation.

NAND, but can you please explain why?