Swerve Drive

[Eagle_Strike123]

Hello, I am I student from team 27, team RUSH, doing research on swerve drive for a presentation. Any teams that currently use swerve drive on their robots, or have in the past, if you could explain the advantages and disadvantages of using swerve drive to me, I would greatly appreciate it. Also, I would like to know of any situations where using swerve drive was particularly effective. Thanks!

[Al Skierkiewicz]

Eagle,
The game determines our use of crab. The advantage comes from it's ability to move like a crab, forward, backward or side to side, without the need to turn the robot. This can be a real plus when the game needs you to pick up or score rapidly and has little obstacles on the field. While Logomotion could have been successful with crab drives, we felt most motion would be forward and fast followed with an accurate minibot deployment. Crab worked well for us in 2003 by allowing maneuvering onto and up the ramp and also allowing us to target stacks. It's downside is that it requires a lot of practice to get it right. Drivers need to be able to visualize movement while driving towards or away from the driver's station in any orientation. They need to be able to control the robot even when it is turned (either intentional or not) and still get to the target. Drivers need to see the movements in their sleep. A well implemented crab drive will usually take more space and require more weight than other drives and will require some extensive fine tuning of the software to track and be accurate during auto.

[AlecMataloni]

The obvious advantage would be omnidirectional motion. As opposed to an omni-wheel drive or a Mechanum drive, Swerve retains all the pushing power of a similarly geared 4-6 wheel drive because of the potential to use traction wheels in the design, as opposed to the slippery wheels used in a mecanum or omni drive that result in a loss of power/pushing ability.

This type of omnidirectional movement (minus the traction wheels) was quite helpful during 2009's Lunacy, as pinning was completely legal. A huge advantage was given to teams that could ease their way out of a pin with their swerve drives (I'm pretty sure The New Cool mentions this while talking about 1717's swerve that year). Basically any game with robot contact rules like 2009 makes swerve look very attractive.

One downside is weight and part allocation. Swerves usually take up 6-8 motors, and they are definitely heavier than most other drivetrains, depending on design.

Another downer is the amount of coding involved. Programming a swerve drive is just as much a challenge as designing it, and then some. Perhaps someone else can touch on the specifics, since I'm not too familiar with how it all works.

Our driver has complained about driving our 2010 robot due to its long base. You probably don't want to design a long base swerve robot, because, depending on your design, it can be a hassle to turn the orientation of the robot, as it would be if you didn't have those drop center wheels on a 6 wheel that makes the base turnable; however, if you were on 1625 that same year, then this didn't apply. :D

Swerve drive is HIGHLY situational. It's only given us a visible advantage in probably 2 different years that we've used it (2003 and 2009). A well driven 6 wheel can hold its own against a swerve, at least in my opinion. It's important to know how to build an effective iteration of a swerve before the season starts and when it does start, It's highly important to judge if whatever your team wants to do with a swerve is accomplished just as well by a 6 wheel drivetrain (sorry if the wording was awkward).

[Ether]

as opposed to the slippery wheels used in a mecanum or omni drive that result in a loss of power/pushing ability.

Omni and mecanum wheels don't need to be slippery to operate properly. The rollers need to spin freely though. But even with grippier wheels, they lack the pushing force of a standard wheel because the floor reaction forces are larger.

Our driver has complained about driving our 2010 robot due to its long base. You probably don't want to design a long base swerve robot, because, depending on your design, it can be a hassle to turn the orientation of the robot

It sounds like what you are describing is crab, not swerve. A swerve has no problem turning with a long wheelbase.

[AlecMataloni]

Omni and mecanum wheels don't need to be slippery to operate properly. The rollers need to spin freely though. But even with grippier wheels, they lack the pushing force of a standard wheel because the floor reaction forces are larger.



It sounds like what you are describing is crab, not swerve. A swerve has no problem turning with a long wheelbase.




Whoops. My bad. Sorry.

[Andrew Lawrence]

It sounds like what you are describing is crab, not swerve. A swerve has no problem turning with a long wheelbase.




This may sound dumb, but what's the difference between the two?

[Peyton Yeung]

Team 45 is prototyping a swerve drive right now.
Advantages
-omnidirectional movement
-pushing power
-wow factor(if done right it makes people wow)

Disadvantages
-complex
-heavy
-expensive
-time consuming (design, build, then the enormous time that will be spent coding followed by hours of practice)
-requires many motors

[Joe Johnson]

Implementation matters.

Some go with swerve (steerable drive wheels) on two wheels and omnis on another two. Some go with 4 wheel swerve. Even with 4 wheel swerve there are differences. Do you have 4 wheel independent steering or perhaps 2 sets of two steerable drives.

There are resource differences in each.

And then there is the big kahuna: power to the driven wheel.

Most swerve implementations have independent motors on each wheel that provide the power. In this way you only have to feed wires to the motor and viola! you have your torque source for your wheel.

BUT... ...others have chosen to get the torque to the drive wheels via mechanical means (typically a shaft through the pivot and a pair of bevel gears).

On the one hand, I hate bevel gears (in FIRST applications especially). They can be done well (Note to self: talk to John V about his championship robot and inspect that dang bevel gear set up). On the other hand, having a remote motor can make swerve a more compact package (swinging motors in space uses a lot of room and the wiring challenges are less problematic). It also makes shifting somewhat easier if that is how you roll because there is morel likely room if you have a stationary motor/gearbox.

Still other use a long chain and drive multiple wheels via this arrangement. It has its own set of strange behaviors to deal with.

Then there is the question of how many revolutions do you allow? Some swear by infinite. I think I am more of a +/-180 kind of a guy. In many cases even +/-90 is enough. Depends on the game.

In all cases, driver skill is as important as the feature. If you don't have a chassis to practice on, your drive will be learning at a regional. I can tell you from experience this seldom ends well.

Oh... ...one more thing. wheel power. The one wheel one motor method limits you in a pushing match in that if you ever get rocked back the motors that are driving wheels that are in the air are giving you no help at all. You have the advantage that you can move sideways to get the right angles to push at, but that is not always enough.

Joe J.

[connor.worley]

This may sound dumb, but what's the difference between the two?

I'm not sure, but I think in a full swerve, all modules can rotate individually (you get the magic "rotate and and translate at the same time" motion). In a crab, modules are linked rotationally (less motors?).

[EricH]

I'm not sure, but I think in a full swerve, all modules can rotate individually (you get the magic "rotate and and translate at the same time" motion). In a crab, modules are linked rotationally (less motors?).
Nope, that's not the difference. 118's coaxial swerve drives have had every module linked rotationally in the past.

I think it has more to do with the way the rotation happens and the various linkage schemes. There are quite a few of those, including all, front/back, and left/right.

[Aren Siekmeier]

Technically 118's '07 and '08 bases were crab drive, because they had no ability to rotate. The steering of all the wheels was linked together with one chain, driven together. They also powered all the wheels together, and were able to do this because their manipulated was turreted. 148's '08 drive was also crab for the same reasons.

[Ether]

This may sound dumb, but what's the difference between the two?


http://www.chiefdelphi.com/forums/attachment.php?attachmentid=11111&stc=1&d=1321936033

[Aren_Hill]

Hello, I am I student from team 27, team RUSH, doing research on swerve drive for a presentation. Any teams that currently use swerve drive on their robots, or have in the past, if you could explain the advantages and disadvantages of using swerve drive to me, I would greatly appreciate it. Also, I would like to know of any situations where using swerve drive was particularly effective. Thanks!

from my perspective (3 competition swerves (one with too many wheels), and a bunch of prototypes)

advantages:

Elusive to defenders (the biggest pro IMO)
Many defensive robots aim to lock up opponents with a side tbone, or simply playing moving wall, its much harder for them to accomplish both of these if you have a well driven swerve and are unpredictable.


great in tight quarters (in theory)
grace and fluidity are possible (though rarely accomplished IMO, watch any 16 matches for an example)
great creative outlet for a bored designer :p


Disadvantages:

control: Getting that direct mental connection from operators mind to robot movements is quite difficult, and takes alot of development and practice time
labor intensive in most cases (COTS ones available)
expensive
typically take up much of the base (I've found ways around this)
require many motors (I don't think i'll ever do a non fully independant one again meaning at least 8 motors on drive)
Number of moving parts/failure points is fairly high





On the one hand, I hate bevel gears (in FIRST applications especially). They can be done well (Note to self: talk to John V about his championship robot and inspect that dang bevel gear set up).

You mean the ones that lost a few teeth each regional?

[Al Skierkiewicz]

Ether,
Crab mode robots have the potential for changing robot orientation with respect to the field with a simple descending foot that lifts two wheels off the floor and allows the drivers to move one side of the robot (Wildstang 2003). Another method is to jump to a software routine that allows the robot to drive in "tank" mode to change orientation and jump back to crab mode when the driver is satisfied with the orientation. In rare cases designers have allowed two steering motors (connected to opposite sides of the robot drives) to change the turning radius of the robot (Wildstang 2007). This allows changing the orientation over a greater distance but still accomplishes a design with the advantages of crab for other parts of the game.
Personally, I find the terms "crab" and "swerve" interchangeable. If I was asked to make a distinction I would be inclined to call drives where the wheels rotate 180 degrees or less "swerve". Drives that turn up to 360 degrees "crab" and drives that turn greater than 360 degrees "continuous crab". Drives that are any of these where one set of wheels turns independently of the others can use the modifier "steerable" e.g. "steerable crab". As Joe has pointed out above (possibly the first to use a crab drive in First) each system has distinct advantages and disadvantages.
How you use the drive or implement the design can have a huge impact on the drivers and how the game is played. Crab will not win the game all by itself. If it takes your drivers a lot of time thinking where to go and how to get there, you will lose precious seconds you could be scoring.

[Ether]

Personally, I find the terms "crab" and "swerve" interchangeable.

That's unfortunate. It makes the words redundant and far less useful.

To many vets here on CD, crab is a subset of swerve, wherein all four wheels are steered in the same direction, whether by mechanical linkage or by software design. That is a very useful distinction and one worth supporting.

http://www.chiefdelphi.com/forums/attachment.php?attachmentid=11113&stc=1&d=1321972474

http://www.chiefdelphi.com/forums/attachment.php?attachmentid=11111&d=1321936036

[Al Skierkiewicz]

To many vets here on CD, crab is a subset of swerve, wherein all four wheels are steered in the same direction, whether by mechanical linkage or by software design. That is a very useful distinction and one worth supporting.


As a vet here on CD, I respectfully disagree.

[Ninja_Bait]

Let's not get too crabby, guys.

I've always felt that "crab" holds the connotation that the robot is primarily meant to translate without rotating, much like a crab's motion. While there may be ways to make a crab drive rotate, it doesn't change the fact that the wheels almost always all point in the same direction and are meant to be used that way. (In this case, crab drive can also describe a control system.)

Swerve (and I've also heard vector drive) is the broader definition where the wheels actually can have different orientations relative to each other. That allows a wider variety of motions that a crab drive might struggle to achieve.

Honestly, though, it's just finicky semantics. We could also call them all "powered office chair caster wheel drives" but that would be lame. They're all basically built from the same idea, and the name doesn't matter as long as you're specific enough to differentiate the mechanism.

[Aren_Hill]

I ignore any difference between the two, and use them interchangeably, as enough variations exist for steering and power distribution.

Swerve/crab to me is just a drive that can pivot all its wheels, and just follow it up with what configuration you're running for steering and power.

[ajlapp]

On the one hand, I hate bevel gears (in FIRST applications especially). They can be done well

You should try using a set this upcoming season. We build our Revolution Co-Axial style crab/swerve modules with a bevel set using semi-precision components and they work well in my opinion.

We have much more trouble with the roller chain final drive than we do with bevel gear alignment and spacing. :)

Also, crab and swerve are the same thing to me. King Crab means something, but otherwise I don't adhere to any difference between them.

BTW, thanks to Dr. Joe for bringing us swerve/crab technology in 1998. I was truly blown away and inspired by the design.

[Joe Johnson]

You should try using a set this upcoming season. We build our Revolution Co-Axial style crab/swerve modules with a bevel set using semi-precision components and they work well in my opinion.



Pictures or it didn't happen ;-)


We have much more trouble with the roller chain final drive than we do with bevel gear alignment and spacing. :)



Now I KNOW you are pulling my leg!!!


BTW, thanks to Dr. Joe for bringing us swerve/crab technology in 1998. I was truly blown away and inspired by the design.

Now you've got me blushing. To my knowledge the only thing you may be able to argue was earlier was the robot that Tony and Bob's old Raytheon Team built in 97 which docked with the goal (the tube tree) and spun it. Man, nobody wanted to play against them on Saturday (this was the days of 1 on 1 on 1 and Saturday morning was a double elim tourney). As recall, they defeated Wildstang that year when a branch of the spinning tree knocked them over as it tried to dock with the goal after Raytheon had docked and the dervish had begun. Back to being first, it is a fleeting thing. The technology was advancing such that it was going to happen sooner or later.

While I am posting, I have an idea for a crab chassis morphology that I have never seen in FIRST before. I think it could be 4 ways of awesomeness.

But it is only a twinkling in my eye at this point. If I can get my rookies organized enough that we can prototype it before the season starts, AND if it works like I think it will, AND if the game is sideways motion friendly... ...all ya'll may get to see it at the Boston Regional ;-)


Joe J.

[Aren_Hill]

https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-snc4/40568_148288231849058_100000036466786_432887_10657 70_n.jpg

Dr. Joe,

I've used bevel gears 3 times in competition and have never had a problem with them, in the above pictured setup we only had issues with the utterly ridiculous chain runs.

(^that one hit einstein in 2010)

[Peyton Yeung]

While I am posting, I have an idea for a crab chassis morphology that I have never seen in FIRST before. I think it could be 4 ways of awesomeness.

But it is only a twinkling in my eye at this point. If I can get my rookies organized enough that we can prototype it before the season starts, AND if it works like I think it will, AND if the game is sideways motion friendly... ...all ya'll may get to see it at the Boston Regional ;-)


Joe J.

I'm so excited. It'll be interesting to see what you have in mind.

[Andrew Lawrence]

So it looks like this:

Crab drive keeps the omni-directional part, but doesn't change the orientation of the robot.

Swerve drive has omni-directional motion, as well as the ability to change the orientation of the robot.

Well, in all of my years in FRC (Almost 2!!! :D), I've never seen a match where robots didn't need to change their orientation, so therefore, why would one use a Crab drive if it can't change robot orientation?

Are there any advantages/disadvantages to the loss of the ability to change orientation?

[Aren_Hill]

So it looks like this:

Crab drive keeps the omni-directional part, but doesn't change the orientation of the robot.

Swerve drive has omni-directional motion, as well as the ability to change the orientation of the robot.

Well, in all of my years in FRC (Almost 2!!! :D), I've never seen a match where robots didn't need to change their orientation, so therefore, why would one use a Crab drive if it can't change robot orientation?

Are there any advantages/disadvantages to the loss of the ability to change orientation?

Usually people without the ability to reorient the base turret the entire auxiliary.

[Andrew Schreiber]

Well, in all of my years in FRC (Almost 2!!! :D), I've never seen a match where robots didn't need to change their orientation, so therefore, why would one use a Crab drive if it can't change robot orientation?



Look at FRC118 in 2008 or 2007.

[Andrew Lawrence]

Look at FRC118 in 2008 or 2007.

Point taken. I did not think of that. Thanks Andrew!

And thanks to Aren, since i don't want to leave him out (he answered too!)

[Joe Johnson]

Dr. Joe,

I've used bevel gears 3 times in competition and have never had a problem with them, in the above pictured setup we only had issues with the utterly ridiculous chain runs.

I concede. Those chains DO worry me more than those bevel gears! But that doesn't mean I am not worried about the bevel gears ;-)


FYI what pitch are those bad dads and where do you get them/make them?

Joe J.

[Aren_Hill]

FYI what pitch are those bad dads and where do you get them/make them?

Joe J.

The ones we've used since 2007 for every swerve has been Mcmaster part # 6529K14

(to be honest they were a shot in the dark guess from a naive designer that happened to be a bulls eye)

12DP, Never once have we lost any teeth or damaged one of them past functionality (we also completely remove the hub off the back leaving JUST the teeth, steel is heavy)

I believe they are the same ones that FRC118 uses, and 973 has used them several times.

[AdamHeard]

The ones we've used since 2007 for every swerve has been Mcmaster part # 6529K14

(to be honest they were a shot in the dark guess from a naive designer that happened to be a bulls eye)

12DP, Never once have we lost any teeth or damaged one of them past functionality (we also completely remove the hub off the back leaving JUST the teeth, steel is heavy)

I believe they are the same ones that FRC118 uses, and 973 has used them several times.

1717 does as well. Good stuff.

[JDNovak]

Dr Joe,
For 2006, 07, and 08, we used your Nothing But Dewalt CIM setup with a bevel gear on the drill output shaft. We just trued up the casting designed for the handle and shoved it into a collar that aligned it with the horizontal gear mounted to the wheel like a sprocket. I think it was a 2:1 bevel gear set from Martin and it wasn't cheap. It did work pretty well and never failed. we just set the lash by feel and clamped the drill nose with set screws. It worked well enough to make it to the Einstein finals in 2008.

I just couldn't stand the inefficiency and we moved away from the transmissions and bevel gears the last few years. The motors sure stay a lot cooler these days.

As for crab vs swerve. The code to steer from straight through an arc to rotating around the center of the frame has taken years to perfect. Actually, we had the trig working on the Basic Stamp in 1999 but changed to look up tables through the PIC years. We finally got a better version of real time trig working last year. Crab, on the other hand, takes about 10 minutes to point all the wheels in the same direction and turn all the wheels the same speed.

[Tristan Lall]

I've used bevel gears 3 times in competition and have never had a problem with them, in the above pictured setup we only had issues with the utterly ridiculous chain runs.Looks like you took extreme care to make sure they stayed aligned—the keyed profile on the quarter-inch plates is a fantastic way of implementing that. I often worry about the torsional rigidity in the modules we occasionally see posted here.

[Andrew Schreiber]

As for crab vs swerve. The code to steer from straight through an arc to rotating around the center of the frame has taken years to perfect. Actually, we had the trig working on the Basic Stamp in 1999 but changed to look up tables through the PIC years. We finally got a better version of real time trig working last year. Crab, on the other hand, takes about 10 minutes to point all the wheels in the same direction and turn all the wheels the same speed.

This is interesting, I was under the impression that the STAMP did not have math libraries included whereas the PIC did. I know the programmer on 27 was very happy to have the math libraries on the PIC. Of course, not only is this a long time ago but it was also when I was much younger and wasn't really paying too close attention to him so I could be very much mistaken.

It does show how far the controllers in FRC have come though.

[JamesCH95]

Aren - how much did that swerve drive base weigh? I'm just curious.

[Joe Johnson]

This is interesting, I was under the impression that the STAMP did not have math libraries included whereas the PIC did. I know the programmer on 27 was very happy to have the math libraries on the PIC. Of course, not only is this a long time ago but it was also when I was much younger and wasn't really paying too close attention to him so I could be very much mistaken.

It does show how far the controllers in FRC have come though.

To use the STAMP2 you had to get into the PBASIC Zen Mode. It was all unsigned 16 bit math and it tooks some discipline to keep from hosing yourself. I can recall pulling my hair out trying to count/balance/place the nested parens (which I eventually gave up on -- I memorized the evaluation order of operators and basically kept parens down to the absolute minimum - took some doing but it was a time and bug saver in the end)

As to being glad to see the STAMP2 in the rear view mirror? You bet. It was some much easier to do things like scale a joystick using signed math. Oh and the PIC chip was many many times faster, more memory for variables, more code space (remember program slots? Ugh! that was painful).

Joe J.

[Andrew Schreiber]

To use the STAMP2 you had to get into the PBASIC Zen Mode. It was all unsigned 16 bit math and it tooks some discipline to keep from hosing yourself. I can recall pulling my hair out trying to count/balance/place the nested parens (which I eventually gave up on -- I memorized the evaluation order of operators and basically kept parens down to the absolute minimum - took some doing but it was a time and bug saver in the end)

As to being glad to see the STAMP2 in the rear view mirror? You bet. It was some much easier to do things like scale a joystick using signed math. Oh and the PIC chip was many many times faster, more memory for variables, more code space (remember program slots? Ugh! that was painful).

Joe J.


This makes me glad I only ever used the PIC based stuff.

[JamesCH95]

To use the STAMP2 you had to get into the PBASIC Zen Mode. It was all unsigned 16 bit math and it tooks some discipline to keep from hosing yourself. I can recall pulling my hair out trying to count/balance/place the nested parens (which I eventually gave up on -- I memorized the evaluation order of operators and basically kept parens down to the absolute minimum - took some doing but it was a time and bug saver in the end)

As to being glad to see the STAMP2 in the rear view mirror? You bet. It was some much easier to do things like scale a joystick using signed math. Oh and the PIC chip was many many times faster, more memory for variables, more code space (remember program slots? Ugh! that was painful).

Joe J.

I recall when 95 did a swerve drive using the basic stamp in 2003. I soldered up a board to use a second stamp in parallel with the RC in order to speed up our processing time. It was a nightmare from what I recall.

[Aren_Hill]

Aren - how much did that swerve drive base weigh? I'm just curious.

Never got a weight on just the chassis, but my estimates put it around 45lbs.
Currently rebuilding the practice chassis into a 4wd completely independent swerve for controls development, so I can probably get a weight on that later this week.

I've got a few new concepts in mind that would bring an 8 motor swerve down to 30-35lbs

[Chris Fultz]

http://www.chiefdelphi.com/media/papers/2378

http://www.chiefdelphi.com/media/papers/2381

Here is a paper and presentation from a few years ago that you can review.