In search of an idiots guide to swerve drive

Basically sums up FRC.

I’ll be trying to program a 6WD KOP Chassis that was meant to be an Everybot that got scratched.


Are you talking the absolute encoders from andymark? And would I need 4 or 8?

1 Like

Swerve is actually a not-half-bad thought exercise in how to break down a complex problem into components with reusable chunks of code (classes). I’d highly recommend surveying how others do it, then drawing out on paper how you want yours to work, then implementing your own as much as possible. Be careful about relying too much on copy-pasting other people’s code, as there are lots of different assumptions folks make while doing swerve, and you need to ensure all assumptions are aligned. Especially when weird behaviors arise, you’ll want to have a thorough understanding of what the code is supposed to do so you have a reference when debugging. Swerve is a big enough problem that guess-and-check likely wont’ get you the correct answer by end of the summer.

Here’s some components to think about, in one possible break-down of the “swerve” problem:

  1. A class which takes in operator inputs from a controller, and calculates commands for translation speed, rotation speed, and translation direction
  2. A class which calculates the direction each of the 4 modules should be pointed in, based on translation/rotation commands.
  3. A class which calculates how fast each of the wheels should be turning, based on translation/rotation commands.
  4. A class which can rotate modules to a commanded angle (closed loop/PID)
  5. A class which can run wheels at desired speeds (open or closed loop)
  6. Wrapper classes to group related functionality together

Put these parts together in a reasonable hierarchy. Group functionality that’s strongly related, and trace the flow of information from operator to motor controller. And you’ll be well on your way to a swerve drive control!

1 Like

On the swerve and steer page they explain the parts you have to purchase from them in order to set up an absolute encoder. You would need 4, one to measure the turning of each module. I linked a thread below with regarding how to use it.

While I, in general, agree with this sentiment I do have to bring up that over reaching and failing can have a detrimental effect on overall learning because it discourages reaching in the future.

Swerve is hard. I love it. But I don’t recommend it to most teams simply because of the number of gotchas that aren’t apparent at all. Zeroing modules, current draw, drift over long paths… Sometimes just weird stuff happens.

But you want an idiot’s guide to swerve so here’s the best I can give you:

  1. Understand PID
  2. Get a system (Im partial to stuffing a half inch hex wrench onto a VP w/ an encoder stage) to repeatedly go between positions.
  3. Get 2-4 of these systems working
  4. Now we can add MotionMagic
  5. Now figure out the shortest path and if your wheel needs to reverse
  6. You should be pretty close now so go ahead and try it on a real bot
  7. Put it on a shelf, pull it out for next offseason so you can iterate it, understand controls, and train a driver.
  8. Run a swerve in the season
  9. Spend all season babysitting the swerve
1 Like

We didn’t actually get any help from 2910. We designed and machined ours ourselves (with the exception of the one large gear, which was a sponsor)

1 Like

I had a question regarding swerve drives. My uses aren’t in FRC - rather just general interest. From what I’ve seen teams tend to use 1 motor per module so that each wheel is completely independent, however I was wondering if teams had previously ever tried to connect all the wheels together.

[Top View]

  1. on the left simply connecting all the individual modules together using chain
  2. on the right: using bars to mechanically connect the different modules together (something I thought might be better than chain as that might increase slop). I got this idea looking back at old trains which have something similar to transfer the rotational movement. There is also the possiblity with this for all 4 modules to be joined.

Immediately, I knew that this would not be able to transfer to an X-Drive position which teams often use for turning. To solve this I thought just using tank turning would work just as well.

Ultimately the aim was to be able to create a swerve drive with as few motors as possible. Would this design work? Have others tried it before? Is there something glaringly obvious that I’ve missed out? Any suggestions would help!

The quest for Swerve is frought with challenges… complexity of the mechanics, electronics, software, driving, team ressources and cost.
For your first Swerve Drive, I recommend you invest in Team 2910 - Jack-in-the-Bot’s Swerve Drive Mk2 kit, learn to assemble it, get comfortable running the code released by 2910 on GitHub and start training your drive team.
That probably would be the most “idiot way” to dive into Swerve.
Also, certainly download the Paper identified above. It certainly stands as the reference for Swerve Drive control algorithms. The code implementation by most teams that have developped a Swerve Drive is generally heavily based on those algorithms.

1 Like

It is called Crab Drive. Some teams have used it as a step along the way to developing swerve, since it is much easier to program and learn to drive.


This is what is generally referred to as Crab drive vs. swerve drive - it works and has been used by in the past, the limitation is that you cannot rotate and strafe nicely at the same time. Once the motor rules relaxed, allowing more and better motors, teams have pretty much all gone with fully independent modules. Once you get the fully independent modules working well they are quite fun to drive.
Also tank turning with 4 wheels in a roughly square pattern is usually not very effective.

Thanks Richard and Page2067 - I’ll definitely look further into crab drives - do u know any teams that were able to use it successfully? Also - what do you mean by “tank turning with 4 wheels in a roughly square pattern is usually not very effective”. Surely its just as effective as a west coast drive base - unless I’m missing something?

Generally if you have tank drive with 4 wheels in a square you get the wheels scrubbing against the ground which makes turning weird and much less efficient. If you want to use a 4 wheel tank you generally need the wheelbase to be wider than it is long to avoid the scrubbing.

Page can comment further, but in general turning becomes harder as the ratio of wheelbase to track increases. In a square 4WD setup that ratio is unity, while in a typical 6WD setup it is less.

141 used a crab setup a couple of years ago, IIRC. I have not seen it often in recent years for the reasons Page gave.

Successful crab drives are relatively common–1011’s X-Box drive, 118’s V6 (and follow-ons), and a few others have cropped up over the years.

The OTHER half of your question has to do with drivetrain dynamics, specifically the relationship between wheelbase (length between front and back wheels), trackwidth (distance between left and right wheels), and scrub (friction force from pushing a wheel parallel to its own axle). When trackwidth/wheelbase >1, turning becomes much easier for the same value of scrub than it is when trackwidth/wheelbase <1. As Richard pointed out, a 6WD “drop center” tends to have that T/W ratio >1. You can drastically improve turning performance by removing the scrub, say by replacing regular wheels with omni wheels, but that has some other effects that are best learned by experimentation and observation. The short version is that “wide” robots tend to turn better than “narrow” robots, but dropping the center wheel or making some wheels slicker/omnis makes the “narrow” robot act like a “wide” robot.

I will not disclose it.

1 Like

This paper was a good one on scrub friction iirc but now the link doesn’t work.

Ah, I see what you mean - didn’t think about the friction (I do vex where omni wheels are very very common - hence I was confused why square bases would be an issue). But that makes sense - thanks for explaining it so clearly - i’m not used to the different terms used here.

1 Like

If you have no idea how to program it, you probably don’t actually understand all the math behind it.

Once you understand the math behind swerve drive (it is simple vector addition), the programming is easy.

1 Like

We did a crab drive this year, with 2 steering motors (front/back). We didn’t make all the best choices, and we could not effectively spin in tank configuration. We could only really turn around by using car steering (turning the front or back wheels, while keeping the other two straight). Don’t recommend. We were geared poorly (too fast) and not enough torque with the large amount of wheel scrub, and some crab drives I am sure have done much better (but still isn’t as easy as with swerve).

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.