I have heard a lot about swerve drive recently, and I have a few questions about it. One being why? If you are pushed around so easily and can’t score, what is the point. Also price, isn’t it quite expensive compared to other options. It also seems to be harder to code. Yet despite all of that, it is still a very popular option. I would like to try it but I don’t know if it will be worth the price. Thanks
1 Like
One of your comments “if you are pushed around so easy” is a bit off base for swerve and probably why it is the most advantageous omnidirectional drive common in first is that is hard to push around. The other common omni direction drives Mecanum or some form of omni H or Kiwi can be pushed around easy due to their wheel construction.
10 Likes
Swerve is not easy to push around. In someways it can be harder to push a swerve around than a tank drive. So without the disadvantage of being able to be pushed around, the advantage of a swerve is the ability to move in any direction and rotate while moving in any direction. This allows for very easy and accurate control. It can be more expensive, but prices recently have been going down on swerves thanks to the many COTS options. Same with being harder to code, but there are many examples available to learn from.
It comes down to whether you find the cost/increased code difficulty/ and increased mechanical complexity worth it for the ability to drive sideways.
2 Likes
Swerve is not for every team, that is for sure.
The main advantage of swerve is it’s insane level of maneuverability. The drivetrain is the most important mechanism of your robot. If you can make it better (swerve is better) you improve the entire robot. In short, swerve raises the floor of your own robot’s capabilities.
As @chadr03 mentioned, the claim of being able to be pushed around easily doesn’t match the real world experience most teams have with swerve.
It is expensive. 8 motors + 8 motor controllers + 4 swerve modules = lots of money. For some teams that is not that much, since those motors would be used on the robot anyway. The constraint on the number of available motor slots is a related trade off, and is probably the biggest with swerve.
As for the programming problem, yes it is harder relative to some other drivetrain. However the problem has already been solved and examples can be easily found. Some people value some increased complexity - our lead programmer asked us to give him something harder (swerve) because he wanted to give it a go.
TLDR: In short, I don’t think these are major problems. Knowing them and evaluating them in relation to your team’s capabilities is important. Swerve is a popular option because it increases capabilities and is better in many cases.
4 Likes
15 Likes
There is another good example, watch 1690 shove a team out of the way in the top left. At about 1:05 in
Swerve, like pretty much anything, is only good if you do it well. Swerve just tends to be a little harder to do well.
3 Likes
Just a note to add: Swerve is very different from other forms of omni-directional travel. Don’t get it confused with mecanum or omni-wheel based drive trains
4 Likes
Swerve is difficult to program, even with the new WPIlib tools, but it’s one of those things you can develop in off-season and use forever. I find that it’s very easy to train new drivers on a field-centric swerve compared to WCD/tank. With a decent control scheme, a new student can perform at a high level in just a few hours.
The performance is comparable to tank drives, but with more manueverability.
1 Like
A very wise man once said:
(satire)
2 Likes
To further what some people have mentioned:
Many people look at high powered swerve teams and think that the swerve itself is what made team strong. They don’t realize swerve is just one piece in a giant puzzle. Most of those teams have highly optimized work flows that allow them to create incredible robots.
Not everyone realizes this though, and so the assumption is made that swerve made that team good. Thus, by building a swerve, our own team will become good. This type of flawed logic can sometimes hinder rather than help.
Teams should always try to build within their “credit” limitations. This is an arbitrary number that is based upon mentor support, sponsor support, machining capabilities, and student capacity. Realize it’s like the price is right. The close you get to your credit limit the better, but if you overshoot you are in trouble. I would consider swerve to be something that takes a lot of credits (though it has gotten easier with off the shelf modules)
12 Likes
Following curved paths is easier if you don’t have to waste time driving forward.
2 Likes
We have done swerve effectively in the last two years. We struggle more with game piece handling. My epiphany is that our team’s strengths are in up-front design, programming and access to resources, and our weakness is in iterative design.
That is, swerve is hard but straightforward to get working if you have resources and experienced mentors to help you through it. It’s almost impossible if you don’t have that depth of knowledge on your team, because the math is clearly at the very high end of high school grade levels.
In terms of advantages: we have field-oriented control, and that makes it much easier for drivers to come up to speed with driving skills. Also, it’s still 4-wheel drive, so it’s powerful. The motors out-perform the wheel’s capability to hold traction, and we have to program acceleration limiting so we can maintain traction. The ability to put the wheels into a circular orientation (or X configuration) makes us very hard to push around. We have a lot of pushing power too, but I find pushing power is over-valued by teams here (just my opinion). It’s no accident that there were a bunch of really good defense bots in 2019 that utilized swerve.
“sideways bad” - poof man
In all seriousness, after seeing a bunch of teams try and fail at swerve, imo it isn’t worth the effort to get set up and running until you can get everything else dialed in and working well enough that your chassis is your limiting factor
3 Likes
I agree with this. Teams’ first priority should be game piece handling and effective scoring, as that can be accomplished with even the KOP drivetrain (which is an excellent piece of engineering by the way). Once your team starts to see places where swerve could improve your strategy (whether that be on the field or off), give it a shot in the offseason.
From what I’ve learned talking to teams that have done swerve, it is the holy grail of FRC drivetrains, but it does come at a cost. Programming is difficult and there are quirks to it that complicate integration, hence why I think it shouldn’t fall in the critical path of your team’s success.
tl;dr: swerve good if you do it right and don’t let it fall on the critical path to success.
I agree. We did it because we were naive. Luckily it worked out.
Assuming you can get field-oriented swerve working (it’s not worth it without field-oriented control, honestly), then I would say the one major downside that you can’t engineer around is that it takes up 8 PDP slots. This actually presented some challenges to us in 2020. There were a few times where we might have been able to solve a ball handling problem by adding a motor somewhere, and we just couldn’t because the PDP was maxed out and we would have had to give up something else to get it. Those kinds of decisions are difficult.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.