Rotating while strafing using Swerve Drive

Technical
, , , ,
#1

We are trying to rotate while strafing using our swerve chassis. At the moment, we are capable of strafing, rotating in place, and rotating around a pivot point; however, we would like to be able to strafe while rotating around the center of the robot. A good example of this is Team 2910’s Swerve Drive in 2017: https://www.youtube.com/watch?v=FLnUZBHBczM

Our current robot’s configuration allows us to set the wheel’s angle and speed. Using this config, is there anyway we could accomplish our goal?

#2

I don’t have any swerve experience, but have you tried looking at teams who have released code that use a swerve drive? Maybe you can glean some information from there?

Sorry I’m not of much help here, but it’s what I’d do to start, at least.

1 Like
#3

Look through here.

As long as you can do this independently for each wheel, yes.

1 Like
#4

Find the vectors for each wheel as if you just wanted to strafe and find the vectors for each wheel if you just wanted to rotate and just add each of them together. Then you will need to do some scaling so your motor efforts don’t exceed 1. This slide (from Apple Pi I think) sums it up nicely.

Unicorn – fully independent drive allows Strafe Rotation
Unicorn – fully independent drive allows Strafe Rotation960×720 101 KB

2 Likes
#5

You need to represent this as a vector equation - essentially, you have some target [dx, dy, \omega], and four vectors (representing angle and speed of each of the four wheels). Set up the equation to model robot dx,dy,\omega given the speed and angle of each of the wheels, and then invert it and solve for the wheel speeds and angles necessary to achieve your target dx,dy,\omega.

Lots of good resources out there & on CD regarding the matter - I’d recommend reading through some teams’s codebases.

#6

We can. We just don’t know how :frowning:

#7

You didn’t mention what language you are using. If you are using Java or can read and interpret Java, you can look at 2910’s competition code to see how they implement fully independent swerve. They also released a stripped-down Java swerve codebase intended to be a resource to those who purchase the SDS swerve modules developed by one of their mentors. However, this codebase still refers to the utility classes in the 2910 codebase so it’s probably just as easy to look at the full 2910 code.

As far as I can tell, 2910 is not doing anything particularly unique in regard to the kinematic equations used to generate the angle and speed setpoints for each wheel. If you find the kinematics functions from any codebase of a team that does swerve well, you’ll likely see pretty much the same computations.

3 Likes
#8

WPILib also will have Swerve supported for the 2020 season, but you can already copy paste those classes into your own code if you’re interested.

2 Likes
#9

That’s why I linked the post I did. Check out the first two pdfs in the link to get a feel for the math.

#10

There are a ton of different ways to do Swerve Drive code. Before you dive into other teams’ code, it’s helpful to know how you have your swerve drive set up. Which direction is forward? Is 0 degrees forward? Is 90 degrees forward? I believe some teams might do things differently.

Here’s a helpful link on the math of the swerve drive: Math and Programming Behind Swerve

Also, since I don’t know what your code looks like, it could be structured in two different ways. You might know which module is FR, FL, RL, RR, or you might just know the location of the module relative to the center of the robot. For the position relative to the center of the robot, you can go for a design similar to how 1706 does it: https://github.com/rr1706/Swerve_Base-2020/blob/master/src/main/java/frc/robot/subsystems/drivetrain/SwerveDrivetrain.java

If you know which wheel is FR, RL, etc, you can use code similar to ours: Some kotlin code (0 degrees forward) or Our Java code (90 degrees forward)

Each of these code examples are its own beast. Don’t feel like you have to understand all of them. Just use the one that fits your code structure the best or use parts from each of them, or from none at all.

#11

With the 2020 update, I heard you can’t run the new code on a 2019 roborio. Is this not a true statement if we import only the swerve portion of the code?

#12

Some of the new code in WPILib only works with the new update to the RoboRIO itself that is not released yet. Basic portions of the Java WPILib code are able to be used. You have to copy and paste these classes because if you were to try to “import” the new code, you’d get all of the new code, including some things incompatible with 2019 imaged RoboRIOs.

The code for the Swerve Drive code and many other new utilities in WPILib can be copy and pasted and “just work” on 2019 robots because that code doesn’t use certain new features that require an update to the RoboRIO.

If you think you will want to use the swerve drive code from WPILib, it’s not a bad idea to copy and paste the necessary classes into your project. If you do this, I recommend keeping the same package structure. By keeping the same package structure, when you update your code to WPILib 2020, you can delete those classes and shouldn’t have to change any of your code.

When I say keeping the same package structure, I mean that if a class is in a package called “com.example.thing”, you would copy that class to “com/example/thing” in your project. When put into your “src” folder, the layout would look like this: “src/main/java/com/example/thing/.java”

That whole package thing is optional, it would just make updating your code next year a little easier.

2 Likes
#13

Here is a link to my teams swerve code written this offseason, it’s based of off Ether’s white papers which I highly recommend checking out here on CD. This code is by no means clean, well written, or the best it could be, but it is functional. For a bit more info we use the swerve specialties MK1 swerve with absolute encoders on a talon srx for steering and a victor sp for our drive motors.

#14

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.