I know there is a PR for a WPILIB swerve drive simulator, but the comments seem to indicate that is not ready.
Is there a current go to?
1 Like
This is definitely not the best solution but if you need something quick for testing higher-level control (something like auto pathing logic or more general things like that) you could just directly plug in the results of SwerveDriveKinematics.toSwerveModulesStates into your SwerveDriveOdometry.update function when you are in simulation mode.
Again, I would only recommend this if you want to generally see the robot moving on the simulated field, not for the sake of actually trusting the results (they would be perfect because we’re assuming no losses from setting the module states).
I’ve seen a lot of people use the WPILib flywheel sim class to simulate the individual motors in a Swerve module. This is an example to simulate the SDS MK3 modules with falcons.
private FlywheelSim driveSim =
new FlywheelSim(DCMotor.getFalcon500(1), 8.16, 0.025);
private FlywheelSim turnSim =
new FlywheelSim(DCMotor.getFalcon500(1), 150.0 / 7.0, 0.004096955);
1 Like
6328 took this approach, which is detailed in this post.
3 Likes
yeah i care less about simming the physics. more just about checking the control structure!
Only thing would be how do I sim the gyro haha
1 Like
As far as I’m aware 6328’s 2022 example (posted above), my own example in 2021, and 2194’s 2022 example* are the only one’s that work. They use the built-in WPILib simulation libraries to do this by using the FlywheelSim object to simulate the steering/turn motors. As a result they are not 100% physically correct, so you shouldn’t solely rely on it, but these methods are great if you just need to test code logic or test that the robot will roughly follow the auto path (You may need to cap the max trajectory speed/acceleration in this case).
* As an aside, our team found it amusing that 2194 copied our off-season robot code, since we went with a tank drive in-season and we never publicly said anything this. Bonus points for the team being in Wisconsin and that some of our newer mentors (who lived in Wisconsin and are now SpaceX employees) are friends with members of 2194 and had no idea that this happened.
I would look at how 6328 simulates the gyro in their code, their IO structure seems to be a fairly effective method of simulating almost anything.
Right now, you can simply pretend odometry is perfect. It isn’t perfect, but it works in the meantime.
1 Like
Sticking with the high level sim approach (i.e. not using a FlywheelSim, though for a more robust full simulation solution I’d definitely recommend looking into that) the gyro “simulation” can actually be very simple.
Because you care more about the control structure, for your use case it would be quickest to find where you’re commanding a ChassisSpeeds and just use that to update the gyro. Many teams have one singular “drive” function that takes in a ChassisSpeeds and does the kinematics calculations. If this is the only place your modules would ever be commanded, you could just directly use the omegaRadiansPerSecond and multiply it by some measured dt timestep and just add it to a simulated heading variable. Then in your getGyroAngle() function just have a check RobotBase.isSimulation() ? simHeading : gyro.getYaw() so you can use the same functions in simulation and real.
If you wanted it to be more “true” to the real robot you could instead take the result of kinematics.toChassisSpeeds(moduleStates).omegaRadiansPerSecond and multiply by the same timestep although this should return the exact same value as the previous method just with an extra calculation.
This approach assumes zero losses from friction but it also wouldn’t take into account things like the skew from driving and turning noted here, but again judging from your use case, this is likely good enough.
I spun up this low fidelity simulation harness for Swerve. It works pretty well to simulate the acceleration and dynamics of a swerve drive, but if you’re looking for sensor noise etc you’ll have to add that in on top. It takes a naiive approach to acceleration, but we’ve found it to be good enough for our purposes. 2023-ChargedUp/SwerveSim.h at master · CurtinFRC/2023-ChargedUp · GitHub
5 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.