Swerve vs. Butterfly Drivetrain

[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?

[AlexanderTheOK]

Originally Posted by Jon Stratis

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.

Fair enough, the difficulty of some systems comes from their scale. A servo motor waving a toothpick isn't the best way to test code for the arm of a 2011 robot.

I can say from experience however that the code for a swerve drive does in fact scale rather well. It took me possibly 3 days to port the code over to java, 20 minutes to tune the PID, and another 3 days to make it look pretty so we could debug things, (and likely 4 to deal with the nasty issue of analog counters in the wpilib).

The rest of the issues the system had stemmed from the unbelievable complexity of designing and building the darn thing (of which, to the credit of those who worked on designing and building it that year, there were very few.)

Originally Posted by Jon Stratis

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?

I do have to take offense at what seems to be deliberate misreading of my post.

It took 3 days to build the mockup. It did not take 6 weeks to build the whole drive. The base was working by the end of week 4 that season. The first I directly stated, and I believe you should have noticed, the second is rather easy to infer, which I assume you also did.

3 days does seem a bit short though. I would expect a team with fewer vex related components on hand to take more time due to the process of procurement.

Originally Posted by Chris is me

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.

A rather good point. I was a bit more experienced at that time than what I imagine the mean would be.

I would argue that a team with the means to build an effective swerve drive is almost guaranteed to have at least one programmer with the experience and talent to figure it out rather quickly,

but such an argument would be based entirely in conjecture since I have experience only with two teams. It would stand to reason that I had not considered teams with a greater imbalance of resources between the programming and mechanical teams.

Originally Posted by Chris is me

Even your own example is of a swerve drive that, in your words, had a configuration that did not work.

Right, seems a component of my post is missing. I was sure I had typed it but voila, as I was going back to look for it it was gone. There was a bug in the wpilibraries. It caused the configuration to not work. What I had failed to mention (but which it would reason isn't too difficult to infer) is that the bug was indeed fixed (good god would I have had a rant to put up here if it wasn't.) in, if memory serves me well, approximately a snappy four days. The configuration itself was fine, and worked, again, if memory serves me well, flawlessly.

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