Swerve vs. Butterfly Drivetrain

[Ginger Power]

What are the pros and cons for each drivetrain? What types of game fields are conducive for each?

For Swerve: what are the advantages to 4 wheel swerve vs. 3 wheel swerve?

For Butterfly: Also consider nonadrives and decadrives (a butterfly drivetrain with a strafe wheel or 2).

I'm trying to figure out what I should spend my time working on as I'm procrastinating on my schoolwork. I just keep going back and forth on which drivetrain offers the most benefit. For this comparison, ignore ease of design, and cost. Assume that the team looking to manufacture either of these drivetrains has access to a simple mill and lathe (no CNC).

In my mind, a decadrive and a swerve are comparable in weight, maneuverability, and cost. How about other factors like manufacturability, driver learning curve, and durability?

I'd also be interested to hear about what drivetrain would perform better in a game like Aerial Assist where there is a wide open field, assuming equal driver ability.

[itsjustjon]

I mean, I'd hate to sound argumentative but all of these drives are far too complex of a solution to the FRC games given in the past five years, give or take.

You'd be better off 86'ing any of these and switching it for a WCD due to easy manufacturing. And, since all of these FRC games are designed with rookie teams in mind, you'd be hard-pressed to find a game where Swerve, Mecanum, Nona-whatevers are necessary for success.

[asid61]

If you've only got a simple mill and lathe, it's difficult to make a "modern" swerve drive (that's low weight and size, or comparable to a WCD in both). Butterfly is alright, but I like octacanum more because you can keep things in only 4 modules where with butterfly/H-drive you need center wheel to strafe as well. The strafe wheel will also inevitably have less pushing/acceleration power than one in a swerve drive.

Apart from the balance issues, 3-wheel swerve is nice because you can run 3CIM + 3 miniCIM. However, at that point you are using up 6 motors for drive + 3 for turning, leaving only 7 for all manipulators. For many teams, that's ok, but for some motor-heavy users you might want 8 (2 for shooter, 2 for angler, 1 for intake, 2 for angling that, 1+ for climber?). I prefer using a 4-wheel swerve with 1 CIM each to leave you with 8 motors.

I would say that swerve is equal to or has an advantage over H-drives/butterfly/octocanum in most aspects unless you're 33 in 2014 and are ok with being pushed sideways/drifting when you move. The main disadvantage is losing more motors and taking a lot of manufacturing time and weight. For those reasons I would go octocanum in most situations if you really want the strafing.

On a side note, I think the biggest advantage that swerve or other holonomic drivetrains have over a traditional WCD is being easier to drive. If you start somebody off on a field-centric drivetrain, they'll have no problems getting the hang of it quickly. There can also be a space-saving aspect depending on your overall robot design and the game in question, but more often than not it's negligible.

[Ari423]

Let me start with I have never physically made either of these, but I have done a number of CAD designs for each.

Swerve:
Pros:

• High traction in any direction (i.e. can push going sideways)

Cons:

• Lot of parts to fail
• Requires more precise alignment (harder without CNC)
• Complicated to program (more sensors and processing required in order to drive straight)
• Uses 8 motors (6 for 3-wheel swerve)
• Heavy without CNC
• Takes longer to tune before driving (multiple feedback controllers necessary)

4-wheel swerve is more stable if pushing matches are a possibility while 3-wheel swerve is lighter.

Octocanum/Butterfly:
Pros:

• Inherently supports two-speeds without a ball or dog shifter
• Easier to use COTS gearboxes as part of design
• Easy to program (viable without any feedback controllers)

Cons:

• Easier to be pushed
• Doesn't like uneven terrain

That's just what I can think of off the top of my head, I'm sure other people will have more.

[Jon Stratis]

Based on my experience, Butterfly is much easier all around. Swerve is more complex to produce, more complex to program, and potentially more complex to wire (depending on exactly which swerve design you're talking about, and concerns about wires rotating with the module).

In terms of design and production, building a swerve module properly with minimal friction is rather difficult. It requires some parts that you don't normally see on robots to solve issues with its complexity. On the other hand, Butterfly is relatively simple and straight forward, simply requiring the ability to machine identical pieces for either side of the module.

With swerve, you need precise PID control for wheel angle, and fairly complex calculations to figure out how to angle each wheel at any given time. With butterfly, you basically just have two driving modes, tank and mecanum, which are fairly well understood and easy to implement. Then just a little pneumatics to change the drive being used.

From a usability standpoint, being able to shift between butterfly drive trains using pneumatics leaves open more PDP slots for motors elsewhere, while swerve requires those extra turning motors.

All that said, while both drive train types are cool and impressive, I don't think they're really needed on an FRC robot to do well.

[fargus111111111]

Swerve:

• Harder to program, but more complex motion is achievable
• Easier to drive? it depends on a few factors a) how responsive the system is to sudden changes in direction and b) how it is set up to drive (field centric or not, depends on the driver which would be preferred)
• More complex machining
• More resource heavy
• Requires more of a commitment, if it falls through you are pretty much back to square one or you are rushing to find omniwheels to fit one end of your robot as you lock the steering on all the modules (trust me, not fun, we did that once, we don't talk much about that year)

Butterfly:

• easier to program
• could be easier to drive if your drivers are used to traditional skid steer operation
• not as good traction in all directions
• simpler to machine and assemble
• generally cheaper because of the lack of need for specialty parts
• if omnidirectional portion doesn't work out the robot can still easily be driven as a basic skid without major code modification or mechanical modifications
• for a team without experience with either system it would seem to me that a butterfly/octocanum system would be easier and quicker to design and build
• possibility of 2 speeds without any gear change

That seems to be everything I can think of, pros and cons, for both systems. I too would explore octocanum before butterfly for simplicity reasons, but I would say it all depends on what your base is (pun intended), if you have experience working with swerve that is probably easier, experience with mechanum makes octocanum easier and experience with skid leans in the direction of butterfly drive so the long and short of it comes down to what do you feel like taking on.

As far as which one of these will get you the most competitive advantage, well I would say that realistically a basic skid gives you the best competitive advantage because it generally leaves the most room for the advancement of other systems on board and it usually results in the most driver practice which is absolutely key. As a side note, from what I can tell the highest scores of any season, except 2015, were put up by an alliance of robots that did not have omnidirectional drive capability.

[Andrew Schreiber]

Originally Posted by fargus111111111

Swerve:[*]Harder to program, but more complex motion is achievable

Source on the bolded section because Im about the turn on the Ether signal and claim that, in fact, omni directional drives (mecanum and killough platforms) are capable of more complex motion because they are true omni directional capable. This is because they can control each degree of freedom they operate in (x,y,orientation) at any point in time compared to a steered wheel system which has some lag in controlling these degrees of freedom.

[Chris is me]

To answer the OP's question - there really is almost no software complexity to butterfly drives, and the mechanical complexity is much less but still significant. Swerve drives are very taxing both mechanically and software wise.

Originally Posted by Andrew Schreiber

Source on the bolded section because Im about the turn on the Ether signal and claim that, in fact, omni directional drives (mecanum and killough platforms) are capable of more complex motion because they are true omni directional capable. This is because they can control each degree of freedom they operate in (x,y,orientation) at any point in time compared to a steered wheel system which has some lag in controlling these degrees of freedom.

Butterfly drives are generally defined as 4 traction / 4 omni on pivots, and have no inherent ability to strafe.

Even with the addition of a sideways strafing wheel, they are significantly worse at strafing about an arbitrary center of rotation, or translating while rotating at the same time.

[Andrew Schreiber]

Originally Posted by Chris is me

To answer the OP's question - there really is almost no software complexity to butterfly drives, and the mechanical complexity is much less but still significant. Swerve drives are very taxing both mechanically and software wise.



Butterfly drives are generally defined as 4 traction / 4 omni on pivots, and have no inherent ability to strafe.

Even with the addition of a sideways strafing wheel, they are significantly worse at strafing about an arbitrary center of rotation, or translating while rotating at the same time.

Ah true, I was reading it as "optimally built swerve compared to optimally built omni drive"

[Drewit]

Originally Posted by Ginger Power

What are the pros and cons for each drivetrain? What types of game fields are conducive for each?

For Swerve: what are the advantages to 4 wheel swerve vs. 3 wheel swerve?

For Butterfly: Also consider nonadrives and decadrives (a butterfly drivetrain with a strafe wheel or 2).

I'm trying to figure out what I should spend my time working on as I'm procrastinating on my schoolwork. I just keep going back and forth on which drivetrain offers the most benefit. For this comparison, ignore ease of design, and cost. Assume that the team looking to manufacture either of these drivetrains has access to a simple mill and lathe (no CNC).

In my mind, a decadrive and a swerve are comparable in weight, maneuverability, and cost. How about other factors like manufacturability, driver learning curve, and durability?

I'd also be interested to hear about what drivetrain would perform better in a game like Aerial Assist where there is a wide open field, assuming equal driver ability.

I can answer your questions above about swerve, but I don't have enough experience with octocanum/any mecanum drive to talk about that drive system.

We have run swerve since 2010 (with the exception of 2016 - FIRST Stronghold - where we ran treaded tank drive), and we actually did some testing with a three-wheeled swerve. Check out our website for our findings, as well as this whitepaper from our head mentor (CD Username: Clem1640).

Swerve tends to perform better when the field is flat (2011, 2012 (mostly), 2013, 2014), consistently covered(2010), or a combination of the two (2015). The reason is that, to benefit from all of the drive motors with swerve, all wheels must contact the ground. If one picks up, your 4WD system becomes 3WD. We learned this the hard way with our 2013 robot, which relied on the drive motors to hook on to the side of the pyramid.

Without extensive modifications, it may struggle with fields that don't meet these criteria (2016). See FRC 16 and FRC 4143 for examples of some modifications that can be made to overcome field obstacles.

If you only have access to a mill and a lathe (no CNC), swerve may prove to be very challenging (more so than it normally is), but it isn't impossible. FRC 2471 showed an example of a manually-milled swerve design of theirs a few years ago. More complex/adaptable swerves will require more complex manufacturing resources.

Swerve's learning curve is significantly higher than wheeled tank drive (in both field-centric and robot-centric driving modes). We have our drive teams practice extensively until it becomes second nature for them. We also have our controls set up similarly to Call of Duty and other games to help it feel more familiar for the drivers (I'm pretty sure the correct name for this setup is Halo drive).

Since swerve drives are so complex, they have multiple points-of-failure depending on the design. However, if your chassis is rigid enough and your swerves can't collide with field elements (we killed a lot of steering motors against the bridges in 2012), then they will be about as reliable as a standard or WCD tank drive. If you design it to be easily replaceable, then maintenance becomes exponentially easier.

For more information about swerve and how we use it, check out our Swerve Central page. And check out Ether's Whitepaper and our 2015 code for help with programming a swerve drive. (The code linked is in Java. We switched from LabView to Java in the 2015 off-season. LabView code can also be found on our Github)

Hopefully this helps answer your questions about swerve drive, and hopefully someone with octocanum/similar drive experience can answer questions about that drive system.

[AlexanderTheOK]

I'm seeing a lot of posts stating the difficulty of programming a swerve drive as a con.

I would really have to respectfully disagree with this sentiment.

In 2015 my team built a swerve drive for the first time in it's history. I was in charge of programming. The first thing we did was build a miniature swerve drive out of VEX EDR Components. That took 2 people 3 days to design, build, and assemble, and me 2 days to debug. With programming, it is almost always possible to get things working before the robot is even built. If youre scared programmers can't handle it, simply test if they can handle it. (note this also works to a lesser extent with EV3 kits)

Throughout the entire process the only issue was that we had chosen suboptimal sensors for the rotation, and that there was a bug in the wpilibraries causing our configuration not to work.(edit: yes it was fixed, rather quickly too.)

No system should be avoided because of "programming difficulty" because the programmers should be starting solving problems day one with working mockups.

fun fact: I was unaware of the existence of Ether's whitepaper at the time, and can attest that working out the equations needed to direct the wheels in the correct directions at the correct speeds is trivial if the student has taken trigonometry, difficult if he/she hasn't.

fun fact 2: The derivations are even more trivial if you view a swerve drive as a "center" and a bunch of individual modules with relative coordinates x and y, instead of using L and W and constraining the code to work with a rectangular chassis. This has the side benefit of being generalize-able to accommodate changes in "center of rotation" (if your driver want's that) and swerve's with fewer/more wheels (west coast swerve anyone?)

[Jon Stratis]

Originally Posted by AlexanderTheOK

No system should be avoided because of "programming difficulty" because the programmers should be starting solving problems day one with working mockups.

And that right there is what most teams have problems with. Building a "working mock up" that is similar enough to actually let you do what really needs to be done isn't always easy. What works with small, weak motors when supported off the ground doesn't always translate directly to strong, fast motors hauling around 150lbs. Getting the PID controllers set up correctly can be horribly time consuming.

If you can build a working mockup that is sufficiently complex in one day for your programmers to use, why does it take 6 weeks to build the real thing?

[Chris is me]

Originally Posted by AlexanderTheOK

No system should be avoided because of "programming difficulty" because the programmers should be starting solving problems day one with working mockups.

With all due respect, this single line is absolutely awful advice. Teams should not be ignorant of their limitations and should definitely not underestimate the challenges of betting their entire season on the effectiveness of their software team.

Every team is run differently and is composed of totally different people of different skill sets. Some teams have barely 1 student who can write all of the robot code, some teams have a few students but no mentors, some teams have a mentor or two but no students, and others have entire software teams at their disposal. Exposure to control theory and advanced embedded control is similarly mixed.

Swerve drive, within a season, is out of the reach of the majority of teams. A swerve drive that is decidedly more competitive than a similarly optimized tank drive is out of the reach of the VAST majority of teams. Even your own example is of a swerve drive that, in your words, had a configuration that did not work.

The biggest reason not to do swerve drive isn't simply that it's difficult, it's that tank drive is much easier and is 95% as effective at least. It can be made fantastic with good software but works well even when the software does not. And every other part of your robot depends on the drivetrain to see the light of day. Not moving reliably or quickly is an unacceptable risk for most teams.

[AdamHeard]

Originally Posted by Chris is me

With all due respect, this single line is absolutely awful advice. Teams should not be ignorant of their limitations and should definitely not underestimate the challenges of betting their entire season on the effectiveness of their software team.

Every team is run differently and is composed of totally different people of different skill sets. Some teams have barely 1 student who can write all of the robot code, some teams have a few students but no mentors, some teams have a mentor or two but no students, and others have entire software teams at their disposal. Exposure to control theory and advanced embedded control is similarly mixed.

Swerve drive, within a season, is out of the reach of the majority of teams. A swerve drive that is decidedly more competitive than a similarly optimized tank drive is out of the reach of the VAST majority of teams. Even your own example is of a swerve drive that, in your words, had a configuration that did not work.

The biggest reason not to do swerve drive isn't simply that it's difficult, it's that tank drive is much easier and is 95% as effective at least. It can be made fantastic with good software but works well even when the software does not. And every other part of your robot depends on the drivetrain to see the light of day. Not moving reliably or quickly is an unacceptable risk for most teams.

Everything Chris said here is true. There is another compounding issue that a swerve drive relies on sensors for basic teleop functionality.

Many teams struggle to keep sensors reliable and accurate over the course of an event.

[Jon Stratis]

Originally Posted by Chris is me

The biggest reason not to do swerve drive isn't simply that it's difficult, it's that tank drive is much easier and is 95% as effective at least. It can be made fantastic with good software but works well even when the software does not. And every other part of your robot depends on the drivetrain to see the light of day. Not moving reliably or quickly is an unacceptable risk for most teams.

I would add that the time and effort put into swerve drive could be better used elsewhere. A simple KoP (or similar) drivetrain can be put together in a single day.