Hey y’all! My FRC team has begun to develop swerve drive and in our brainstorming process we have come across the question of what makes a swerve drive good (or better than others/tank). It is clear from watching matches that some teams have swerve drive down to a T and others would be better off going with tank. What do you think are the biggest differences between a good and bad implementation of swerve drive?
4 Likes
Do you understand each piece of the control stack well enough to figure out where exactly a problem is if something goes wrong?
Do you have a firm grasp on dimensional analysis?
If the answer to either of the above questions is “no,” you might not be ready to use swerve in competition.
It’s still a great learning project in the off-season, though, and experimenting with one then can probably get you where you need to be by the time build season rolls around.
6 Likes
Many times the difference between a good and bad implementation of swerve is the difference between a good and not so good driver 
Same is true for more conventional drives too…
20 Likes
The first point I’ll agree with 100%
The second one though; not at all.
4 Likes
We decided to try swerve in 2022 despite not using it in the offseason only because we knew we could buy a COTS module and use the WPILIB code that way we could focus on getting the drive base tuned and getting more driver practice given our limited hours in person.
Having the sensors and code be reliable so you can trust it to zero correctly on boot every time is huge. Then spending time tuning things like the ramp rate and how to make the joysticks feel more responsive is also important.
At our first event we didn’t have much time to do much software tuning or driver practice but in between our first and second event we figured things out and looked a lot smoother, its not just driver practice but it also helps.
12 Likes
I’ve noticed a lot of teams that adopt swerve for the first time have a hard time thinking in terms of swerve. They still picture the robot as having a front and a back and they need to be driving the robot forward and turning to have the front facing in the direction they are moving. Essentially they treat it like a tank drive.
Other teams clearly have shifted their thinking. They understand that the robot can move in any direction and they understand that while moving the robot can be oriented in any direction. It’s clear that many teams figure this out in the design phase (putting intakes on various sides of the robot and other mechanisms on other sides of the robot since any side of the robot can become the “front” at any point in time). Other teams figure this out while driving such that even though their robot clearly has a “front” in mind, they do not drive with the front facing forward much of the time.
In 2019, we had a ball intake on one face of the robot and a hatch grabber on a face that was adjacent to that. Both mechanisms were attached to the same elevator, but the robot had to be moving with different sides of the robot facing the rocket to be able to place the hatches vs placing the cargo. When we were being inspected at Worlds that year, this really confused the inspector and he could not understand how our robot would be able to use both mechanisms. After a few minutes of us being confused by his questions and him being confused by our robot, our drive coach figured out where the confusion was and stated “we have swerve”. At which point the light went off in the inspectors head and everything made sense to him.
It’s the same with teams and drivers when adopting swerve. You can tell when they are just not getting it yet. Then, when the light goes off, everything changes (from design to driving to code).
16 Likes
My answers are:
- The ability to create (or purchase) and maintain modules which do not break down mid-match.
- The ability to write, debug, and validate software which pushes the drivetrain to its fullest capability.
- The driver’s ability to take full advantage of the drivetrain’s capabilities.
The most common advice: Try it in the offseason. If you can hit these requirements in a few weeks over the summer or fall, you can likely hit them during the build season.
3 Likes
Good Implementation of Swerve: Your performance is better than a kitbot, and the swerve breaks as much or less than one.
Bad Implementation of Swerve: Not a good implementation of one.
This may seem like a snarky answer, but it’s actually just a bare bones assessment of why you actually would when you would want to run one. You can have the cleverest control stacks, the darn greatest driver, or a most magnificent mechanical team, if it doesn’t work better than your old drivetrain, it doesn’t work better.
Thus, whenever someone asks “Are we ready for Swerve?” the answer is, “I have no freaking clue.” You have to actually do testing against your other drivetrains to know if you’re doing it better or not. The swerve modules have to be build, programmed, and driven first.
Answering the question “Are we ready for swerve?” then becomes relatively easy. It’s understand if you’re ready to invest the time and money into answering that question that becomes the real ask.
3 Likes
It is also good if the driver can give feedback to the programming team (or have programmers that are competent at driving) so they can fine tune and make adjustments for when the robot is not acting as predictably as it should.
2 Likes
This is a great point, I have talked with some teams where their drivers preferred to use “Robot-Oriented” vs “Field-Oriented”. Basically driving the robot like a tank drive, which imo a tank drive would be better off being used then.
We have used field oriented exclusively with swerve since 2016, with the NaxX and Pigeon being so reliable there’s not much reason to have even an option to switch, and for us we did take that option out of code this year to free up buttons for the main driver to do other things… (our operator only does the climb).
5 Likes
I have met a couple of drivers that can drive very swervy in robot-orient. Even though it is completely counter intuitive to me, they can wrap their mind around it and it just makes sense to them (of course I have met some programmers that refer to turning right as turning negative left). But in general field-orient is much more intuitive for the vast majority of drivers. So good field-oriented code with a good gyro is a must for good swerve.
We have kept the robot oriented controls in the code (and as far as I know on the control pad as well). It seems like every game has some need for using an onboard camera to assist the drivers and being able to drive to a camera view is often best done in robot oriented mode. In 2019 we used this to drive during blackout and in 2022 this was helpful when hunting the cargo hidden behind the hub.
4 Likes
This was our first year with swerve. We did complete an off season swerve project to prove the programming and mechanical. We would not have done swerve if it were not complete before the season, a requirement we met by 6 days
Our driver picked it up pretty fast, but programming helps with this. I see a lot of teams doing speed and direction with the left stick of a gamepad. We found it was hard to have both directional and speed subtlety. What we implemented was direction is determined by the stick and speed is determined by the ‘gas pedal’ being the axis of the right trigger. Once the drivers got the hang of it they liked it better and it gave them better control.
3 Likes
Having driven swerve in the 2022 season, the difference between successful and poor swerves is whether or not a driver uses the full capabilities of a swerve. Some teams drove swerve like a 6wd and performed like one, while the teams that took advantage of the extra mobility performed much better with a swerve.
The ability to translate and rotate at the same time is the greatest advantage of swerve. A swerve bot can go straight from point a to b without having to waste time rotating. Cargo (or any other randoly scattered gamepeice) can be intook in direct paths without wasting space or time rotating the intake into position. Mechanisms can also be placed on any side of the robot due to rotation wasting no time during a match.
The extra movement options allows swerve to excel at playing and playing against defense. When playing against defense, you can “swerve around” most defenders preventing them from doing much. Getting tboned is impossible due to being able to just drive straight away. It is also possible get past most defenders by spinning around them, as constant rotation prevents them from getting a good grip on your bumpers.
When playing defense with a swerve, the extra mobility makes it easy to target the weaknesses of most bots. When against a 6wd bot, a swerve bot can easily start a tbone and shut down a 6wd bot if the tbone is maintained. And against any bot, a swerve bot can easily target the corners of a bot controlling its rotation. Opportunistic defense is easier to play because sidetracking being much faster.
3 Likes
Interesting method, i could see for some that this could be handy, especially if their left thumb control is less precise than others.
Did you guys every try using a signed square function? IE out = Math.signum(input) * input * input;
We found this helps greatly with being less touchy and I highly recommend giving a shot if you can. Of course if what you are doing is working then do what you’re doing!
Yes we use square function. Even with the gas pedal approach. We found this even better.
1 Like
+1 for gas pedal method.
We tried it in college and our driver didn’t like it. But I did.
We didn’t get to try it out much yet this year, but it’s on our list to bring back.
I’m sure it’s person to person. But if someone’s struggling with fine-tune control on a swerve drive, it should totally be in the back pocket for any team looking to optimize performance.
Do you also have a gas pedal for rotation? Or is the rotation speed dependent on the amount of movement of the stick? Or is there only one speed for rotation?
It seems like, from a coordination standpoint, having two independent finger (thumb) movements needed instead of one would require more cognitive bandwidth (leaving less bandwidth for decision making or controlling other tasks).
We’ve debated whether we should try using a joystick controller (with twist motion for rotation) so that control of the robot movement on the field is completely contained in a single hand (note that hand can still push buttons for other functions as well). We’ve not done it yet, but we have talked about it…
To help the twitchiness at low speed, we’ve tried a couple things over the years:
- we dialed down the gains for “normal operation” and then included a “boost” button to allow short burst of speed. But it seems like every year we end up changing the gains back to 100% and get rid of the boost button.
- we added a creep mode. But it seems like the drivers never wanted to use it and were able to make fine tune, slow speed adjustments just by careful small movements of the sticks.
1 Like
We only use the gas pedal for translation, the rotation on the right stick was strictly a magnitude and direction.
The reason to take speed out of the translation stick is too many things are now on the same press. It is hard to have the fine control over both the direction and magnitude. On the rotation you are ignoring the y axis of the stick so a bit of drift doesn’t hurt you but on translation you are using both axis so it becomes a bit trickier. It does take an adjustment period.
When @jdaming first suggested it to me I was skeptical and when I first suggested this to our drivers their faces kind of took on a skeptical expression. But after 1 afternoon of driving they saw the benefits.
The gas pedal method is used in a lot of flight RC.
@Ether posted an even better solution a decade ago based on cubic polynomials:
1 Like
We messed with cubic but found quadratic to be a nice balance. Every robot and driver will be different though and we always ask the driver how they feel things can improve.
1 Like