Swerve vs. Butterfly Drivetrain

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