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]

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.

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]

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]

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 (http://team1640.com/wiki/index.php?title=3-Wheel_Swerve) for our findings, as well as this whitepaper (https://www.chiefdelphi.com/media/papers/3052?langid=2) 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 (https://www.thebluealliance.com/team/1640/2013), 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 (https://www.thebluealliance.com/team/16/2016) and FRC 4143 (https://www.thebluealliance.com/team/4143/2016) 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 (https://www.chiefdelphi.com/forums/showthread.php?threadid=131778) 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 (http://team1640.com/wiki/index.php?title=Swerve_Central) page. And check out Ether's Whitepaper (https://www.chiefdelphi.com/media/papers/2426) and our 2015 code (https://github.com/FRC1640/2015-Code/tree/master/2015-Offseason-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]

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]

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]

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]

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.

[AlexanderTheOK]

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


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.


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.


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.

[dmorewood]

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.

I actually think swerve was a very good solution for 2014 and we enjoyed having it in 2015. Back in 2014 it was a lot harder to play defense on a swerve bot with a good driver then it was to play defense on a WCD bot. This is best demonstrated by 1640, who ended up being Einstien Finalists with 1114. In 2015 we used swerve on our landfill bot and it was exceedingly useful for quickly maneuvering to intake totes and just being able to turn in place to score our tote stack made us less susceptible to losing the stack. Hope these examples help. Personally I will always advocate for swerve on a relatively flat field where heavy defense could potentially be an issue.

[Bryce2471]

As advice for January I have to recommend using a WCD or similar skid steer drive. So if your team has not explored these thoroughly, you should start there.

However, choosing between a butterfly and swerve drive as an off season project is a completely different matter. The swerve drive is by far the better option, for many of the same reasons that it should not be used in most FRC games. Swerve drives are expensive, difficult to design, difficult to machine, difficult to assemble, difficult to program, difficult to maintain, and difficult to drive well. But when you get it all right, Swerve drive is an amazing sight to behold. This means that when you get done building a good swerve platform, your team will have grown and learned in every way, and you'll have a killer demonstration bot.
(Just my two biased cents)

P.S. I am biased because a swerve drive robot sparked huge inspiration in me as a freshman.

[Ginger Power]

This thread has mostly felt like a referendum against swerve drives, which has been telling. Given my current situation and the feedback here, it definitely seems as though butterfly is a better option for our purposes.

Some have mentioned that both drivetrains are unnecessary/too complicated for FRC and that WCD/Kop drivetrain is the better option. The point was made that a simple tank drive will offer 95% of the performance for a fraction of the cost. While that may be true, why isn't it worth investing build season time to implement a more complex drivetrain that has been perfected in the offseason vs. a WCD or kop drivetrain?

[asid61]

This thread has mostly felt like a referendum against swerve drives, which has been telling. Given my current situation and the feedback here, it definitely seems as though butterfly is a better option for our purposes.

Some have mentioned that both drivetrains are unnecessary/too complicated for FRC and that WCD/Kop drivetrain is the better option. The point was made that a simple tank drive will offer 95% of the performance for a fraction of the cost. While that may be true, why isn't it worth investing build season time to implement a more complex drivetrain that has been perfected in the offseason vs. a WCD or kop drivetrain?

The biggest problems I think teams face in implementing butterfly or swerve drives in season is a lack of testing pre-season, poor design choices, and a lack of good machine tools. I think octocanum can be done fairly well with a manual mill, but the design has to be very similar to what was done in the offseason to have a driving robot within a few days. IMO well-designed swerve drives are very rare, and often times teams do not have the machines to make them well.
Butterfly + strafe wheel takes up space in the center of the chassis, which is rarely available as well.
If you have the machines, the design experience, and the pre-season testing, I see no reason why you can't do swerve or butterfly/octocanum. Just make sure it actually benefits your strategy and/or driver before doing it!

[Andrew Schreiber]

This thread has mostly felt like a referendum against swerve drives, which has been telling. Given my current situation and the feedback here, it definitely seems as though butterfly is a better option for our purposes.

Some have mentioned that both drivetrains are unnecessary/too complicated for FRC and that WCD/Kop drivetrain is the better option. The point was made that a simple tank drive will offer 95% of the performance for a fraction of the cost. While that may be true, why isn't it worth investing build season time to implement a more complex drivetrain that has been perfected in the offseason vs. a WCD or kop drivetrain?

It's a function of priorities for me. If my goal is to be as competitive as possible the goal is to be as simple as possible and get as much practice and iteration in as possible. But sometimes you just wanna build something that's MFD.

[Chris is me]

Some have mentioned that both drivetrains are unnecessary/too complicated for FRC and that WCD/Kop drivetrain is the better option. The point was made that a simple tank drive will offer 95% of the performance for a fraction of the cost. While that may be true, why isn't it worth investing build season time to implement a more complex drivetrain that has been perfected in the offseason vs. a WCD or kop drivetrain?

The big thing is, even when you know how to do swerve drive and you've perfected it in the offseason, it still takes more time, resources, and effort than tank drive. The drive still won't work better than tank without great code running consistently, and you are robbing efforts from your manipulator development, drive practice, etc. to do swerve.

Basically, you have to decide that swerve is such a competitive advantage that it is worth putting less polish into other systems of your robot. In most games, it just hasn't been. There hasn't been a game where optimized omnidirectional drivetrains (swerve, mecanum, or otherwise) are strictly better than tank drives, other than 2015. And in 2015, mecanum drive built and programmed well could achieve what swerve drives could without as much mechanical or software complexity.

(note for those following along at home: this is a post where I'm arguing mecanum drivetrains were the best choice for a particular game. Hell hasn't frozen over, has it?)

[Taylor]

Does a butterfly-style drive necessarily imply the use of pneumatics? For a robot design that does not otherwise incorporate pneumatics, it is certainly important to factor in the space, weight, wiring, and programming required for a pneumatic system to support the drivetrain.

-----

Also, it's important to consider levels of implementation. When I think swerve, I think 16, 71, 111, 118, 1640. Those aren't representative of the 'average' swerve drive robot.
If a butterfly drive succeeds, it's pretty nice. If BD fails, it's still a completely capable 4WD robot*. However, there hasn't really been a team that has used it consistently enough, and at a high level of success, to be the standard-bearer for that configuration.

*the same can be said for a failed SD, but mechanical locks may be needed to achieve that.

[Ari423]

Does a butterfly-style drive necessarily imply the use of pneumatics? For a robot design that does not otherwise incorporate pneumatics, it is certainly important to factor in the space, weight, wiring, and programming required for a pneumatic system to support the drivetrain.

-----

Also, it's important to consider levels of implementation. When I think swerve, I think 16, 71, 111, 118, 1640. Those aren't representative of the 'average' swerve drive robot.
If a butterfly drive succeeds, it's pretty nice. If BD fails, it's still a completely capable 4WD robot*. However, there hasn't really been a team that has used it consistently enough, and at a high level of success, to be the standard-bearer for that configuration.

*the same can be said for a failed SD, but mechanical locks may be needed to achieve that.

For butterfly drive you need to physically switch which wheels are touching the ground. This movement requires fairly quick actuation, a very large amount of force at stall (enough to support the whole robot), and only two positions. To me at least, those restrictions scream pneumatics. I guess theoretically you could use motors (big servos maybe?) but that would be way more complicated than with pneumatics where all you need is a cylinder pushing between the module and a hard attachment to the chassis.

IIRC 148 has used variants of butterfly drive in a number of games (I know they used it in 2010). They haven't used it every year like some of the team's above have used swerve, but if I had to pick a team to be the standard for butterfly drive, I would pick them.

[iyportne]

This thread contains many excellent perspectives. And yes, swerve is not easy to employ but worth the journey. We tend to look at swerve as our development infrastructure and learning bed. We are currently on version 4.0 and have successfully used swerve to our satisfaction in the last two seasons. Code is rock solid and and basically a library object so scalability is not an issue. We have a solid working encoder and have now figured out a robust position and mount to survive an entire competition. We use our technology to develop relationships with local machine shops off season so we have that covered (though the last two seasons we used the Team 221 Revolution Pro modules). We have working robots to practice with so driver training is also covered. I would suggest that if you are interested in any advanced drive train(s) that you make it a multi-season effort and manage your competition risk as you go. And also, you don't have to re-invent the wheel (ha-I just saw the pun there) since FIRST rules dictate that if any of us develop off-season hardware or logic, we must provide design and code to the FIRST community prior to kickoff in order for us to use it that season. We post links to our Swerve design models and JAVA code here on CD.

A few more benefits to swerve added to those already mentioned are:
1. You are no longer limited to a two sided functional robot (front-back). Programming wise any side can be designated as front, and can be switched on the fly.
2. You can easily switch between or mix field-centric and robot-centric movements with vector math.
3. Your center of rotation is now virtual rather than mechanical, so it can exist anywhere - even outside the robot perimeter - great for object acquisition or placement.
4. Sure we use 8 motors, but the entire robot is now a very predictable 360° continuous turret while static or in field-centric motion - that means you have a turret for object acquisition and launch/placement.
5. With a full 150 lbs. competition weight on 4 swerve wheels pointed to the center of the robot, you have a pretty awesome brake for resisting defense or for ramps and it remains active at power-off.
6. You have full 4-wheel positive traction 100% of the time (obviously on flat surfaces) during any movement and don't suffer the movement control loss when not all four wheel are in weighted contact with some surface.
7. Our current development has gotten the net drive train weight near or below the standard KOP drive train.
8. If the game requires obstacle negotiations, you don't have to abandon the benefits of swerve, think of other add-on motion devices like belts, cogs or tank treads...remember Swank Drive?

We should have our Strange Swerve 4.0 designs posted before kickoff. Good luck with the development path you choose!

[marshall]

This thread contains many excellent perspectives. And yes, swerve is not easy to employ but worth the journey. We tend to look at swerve as our development infrastructure and learning bed. We are currently on version 4.0 and have successfully used swerve to our satisfaction in the last two seasons. Code is rock solid and and basically a library object so scalability is not an issue. We have a solid working encoder and have now figured out a robust position and mount to survive an entire competition. We use our technology to develop relationships with local machine shops off season so we have that covered (though the last two seasons we used the Team 221 Revolution Pro modules). We have working robots to practice with so driver training is also covered. I would suggest that if you are interested in any advanced drive train(s) that you make it a multi-season effort and manage your competition risk as you go. And also, you don't have to re-invent the wheel (ha-I just saw the pun there) since FIRST rules dictate that if any of us develop off-season hardware or logic, we must provide design and code to the FIRST community prior to kickoff in order for us to use it that season. We post links to our Swerve design models and JAVA code here on CD.

A few more benefits to swerve added to those already mentioned are:
1. You are no longer limited to a two sided functional robot (front-back). Programming wise any side can be designated as front, and can be switched on the fly.
2. You can easily switch between or mix field-centric and robot-centric movements with vector math.
3. Your center of rotation is now virtual rather than mechanical, so it can exist anywhere - even outside the robot perimeter - great for object acquisition or placement.
4. Sure we use 8 motors, but the entire robot is now a very predictable 360° continuous turret while static or in field-centric motion - that means you have a turret for object acquisition and launch/placement.
5. With a full 150 lbs. competition weight on 4 swerve wheels pointed to the center of the robot, you have a pretty awesome brake for resisting defense or for ramps and it remains active at power-off.
6. You have full 4-wheel positive traction 100% of the time (obviously on flat surfaces) during any movement and don't suffer the movement control loss when not all four wheel are in weighted contact with some surface.
7. Our current development has gotten the net drive train weight near or below the standard KOP drive train.
8. If the game requires obstacle negotiations, you don't have to abandon the benefits of swerve, think of other add-on motion devices like belts, cogs or tank treads...remember Swank Drive?

We should have our Strange Swerve 4.0 designs posted before kickoff. Good luck with the development path you choose!

Having watched these guys develop their swerve system as well as borrowed their lessons learned as well as those from Anthony at 221, this is all really good info.

I'm not 100% convinced about mixing other drive types with swerve (swank) but these guys made it work and it was impressive to watch.

Swerve is hard to get right.

[ctt956]

[snip]
7. Our current development has gotten the net drive train weight near or below the standard KOP drive train.
8. If the game requires obstacle negotiations, you don't have to abandon the benefits of swerve, think of other add-on motion devices like belts, cogs or tank treads...remember Swank Drive?

We should have our Strange Swerve 4.0 designs posted before kickoff. Good luck with the development path you choose!

Having watched these guys develop their swerve system as well as borrowed their lessons learned as well as those from Anthony at 221, this is all really good info.

I'm not 100% convinced about mixing other drive types with swerve (swank) but these guys made it work and it was impressive to watch.


1533's swank drive from 2016 was definitely impressive. That robot could do everything in the game, and it did it fast. I think the swerve part saved time because of the ability to move sideways/diagonally/faster than a tank drive could make the same movement, if it could do it at all. IMO, it was easily one of the best robots within the NC district for 2016, and still amazing outside of the district. I saw similar designs with other teams(330 is a notable example); not sure whose design inspired whose, or if several teams had the same ideas.

[troy_dietz]

I saw similar designs with other teams(330 is a notable example); not sure whose design inspired whose, or if several teams had the same ideas.

I'm not sure if I'm misunderstanding something, but we had an 8 wheel tank this past season. The last time we did anything other than tank drive was in 2009 with our single module "swerve". (closer to a giant turret with bumpers)

[EricH]

I'm not sure if I'm misunderstanding something, but we had an 8 wheel tank this past season. The last time we did anything other than tank drive was in 2009 with our single module "swerve". (closer to a giant turret with bumpers)
And if it weren't for the trailer, it would have been a full turret. Tank drive at heart, though.

The only previous times 330 had a non-traditional tank drive, either they never made the field ('05 mecanum) or they were just an added feature (1999's rotating drivetrain could roll front wheel modules and rear wheel modules independently--handy for dropping down to snag floppies or raising up to slide onto the puck).

330 has never attempted a swerve, other than that '09 robot (which... well, it was a well-camouflaged tank drive). Unless they've tried something in the last couple offseasons, which I doubt.

[XaulZan11]

Especially for 3rd/4th robot, a butterfly drive will likely be viewed as a negative while a swerve will likely be viewed as a positive when it comes to alliance selection.

[AdamHeard]

Especially for 3rd/4th robot, a butterfly drive will likely be viewed as a negative while a swerve will likely be viewed as a positive when it comes to alliance selection.

Odd, I view this one the other way.

We'd be pretty terrified picking a swerve that late in the draft if we also didn't really, really trust that team's ability to keep it running.

[XaulZan11]

Odd, I view this one the other way.

We'd be pretty terrified picking a swerve that late in the draft if we also didn't really, really trust that team's ability to keep it running.

Yeah, I see what you are saying and I agree with it at the districts/regionals. There are many examples of swerve drives doing well at the championship as 3rd/4th robots (1640 off the top of my head). Assuming I could trust it, I would probably pick a swerve drive over a tank drive as a 3rd/4th robot.

My main point was that although a butterfly is more 'advanced', it will likely be viewed as a negative compared to a tank drive when it comes to 3rd/4th robot. When we did butterfly in 2014, several top teams expressed concern or dissatisfaction with it. Fair or unfair, there is some negative stigma attached to butterfly drives.

[Chris is me]

Odd, I view this one the other way.

We'd be pretty terrified picking a swerve that late in the draft if we also didn't really, really trust that team's ability to keep it running.

A nonfunctional drive is DNP in either case - and a butterfly drive will at least be functional even if it doesn't work (just zip tie the modules up).

That said, I've seen more than a few robots from teams who tried swerve drive, got the drive to work... and basically didn't do anything else well, because of the resource drain of swerve. These robots can sometimes make GREAT third picks, because they can play certain kinds of defense in certain games better than tank drive robots.

[Ginger Power]

Especially for 3rd/4th robot, a butterfly drive will likely be viewed as a negative while a swerve will likely be viewed as a positive when it comes to alliance selection.

Can you elaborate on this? Why would a butterfly drive be inherently looked upon as a bad thing? Obviously a swerve drive will be looked upon as a good thing, if the team can drive it well, which will be included in the scouting information.

Also, given the feedback in this thread I decided to CAD a decadrive/Butterslide drive which can be found here (https://www.chiefdelphi.com/forums/showthread.php?threadid=152243).

Edit: Quadruple Sniped

[Chris is me]

Can you elaborate on this? Why would a butterfly drive be inherently looked upon as a bad thing? Obviously a swerve drive will be looked upon as a good thing, if the team can drive it well, which will be included in the scouting information.

Butterfly drives can't push and turn at the same time as well as a 6WD traction drive. They can make walls for defense, they can follow, but they aren't as good at direct pushing other than in a straight line.