My swerve drive has a problem, which is when the robot starts, the swerve drive cannot align itself to the initial position and generates a strange movement, that is, it goes crazy.
We suspect that they are the PID values, we tested it with the pid values from the YAGSL documentation.
our swerve drive is with falcon 500 from drive and neo is from angle
Are your conversion factors being applied properly? Falcon counts are still very much different than Neo counts, so factors are applied there differently. Is there a codebase we are able to see for this project or no?
We use the specific conversion values for each engine obtained from the YAGSL documentation
Try referencing to these: Standard Conversion Factors - YAGSL
It does look like you placed the correct ratios for those, but those are just the ratios. For the JSON file, you have to already have it calculate it out (it takes into consideration other factors as well, like the fact you are using the module’s standard 4 inch wheels like it states on the page).
You are able to calculate it in code and pass it along when you create your drive if you need something different, like here: YAGSL-Example/src/main/java/frc/robot/subsystems/swervedrive/SwerveSubsystem.java at main · BroncBotz3481/YAGSL-Example · GitHub
Sorry, we forgot to update the repository. It is now updated, which is the latest code we use regarding videos. 
2 Likes
No worries! Sorry about the earlier confusion.
Yes, I would go ahead and mess around with the PID values. Try starting at the original value again listed in the config: YAGSL-Configs/sds/mk4i/neo/modules/pidfproperties.json at main · BroncBotz3481/YAGSL-Configs · GitHub and gradually increase the P from there.
I would also recommending to update your odometry periodically with swerve.updateOdometry as it also periodically synchronizes your absolute encoders to your relative encoders when it’s still, which can aid in ensuring your offsets stick.
3 Likes
Do you notice that your Raw Absolute Encoder value’s dont line up with Raw Angle Encoder? You should probably invert your angle motor.
Great suggestion but this is not necessary anymore! I use WPILib Notifier instead. You can still do this but i would call SwerveDrive.stopOdometryThread() first
1 Like
I’m not really sure what my case is since all the wheels rotate from left to right as if it were a pendulum and its proportional value was very high.
Regarding the first video, could you guide us better?
Because if I let the wheels spin for a long time, they end up aligning.
Your angle motors should be inverted in every module file. Assuming they’re not in that video.
Assuming your absolute encoders are increasing when the module is spun counterclockwise and your angle motor encoders decrease like i ask of you here with the solution highlighted.
You need to invert your angle motors by doing "angle": true, instead of "angle": false, here…
Get rid of these as they’re redundant and you should only control conversion factors from physicalproperties.json unless you have a weird configuration (which you dont)
In addition to these I have a recommend checklist here that you should follow to make sure everything is correct. (Keeping in mind any configuration changes not in the JSON files will get erased on bootup of the robot)
2 Likes
We tried inverting the motors and it worked, we can move forward in X and Y, also turning independently works well, but when moving with both shapes, the tires point in totally different directions making it not get a correct movement.
That video doesn’t help me much unfortunately so I am going to guess your issue is this?
Please send a video with FRC Web Components!
I see we have a problem with the front. When moving in positive X, it actually goes negative, the same thing happens in Y, as seen in the video. The robot moves forward but on the website you can see that the arrows point backwards. Although it is not seen in the video, the turn is completely the same, turn to the right and the website shows that you should turn left.
We tried inverting the engines, the joystick input from JSON but without a solution.
https://drive.google.com/drive/folders/1ZfAaXT40VwKslhmJDjcGjNTiTcD4Ie6E
Did you try inverting the drive motors (all of them) and then inverting the IMU?
Yes, the drive motors and IMU but it did not solve the problem.
Have you tried changing the values from your controllers to be negative instead of positive when getting the target speeds from them.
1 Like
Yep, we finally have the chassis working correctly.
We pass the entire Math.pow parameter as a negative
Now at this point the robot from FRC Web Components moved according to the joystick, left was left, right was right, and only physically the robot moved to the opposite side that it should.
We simply inverted the drive motor from JSON for each module and this solved everything.
We also tried testing an autonomous command generated from PathPlanner and it worked as expected. Correct movements and a clean trajectory.
Surely by playing a little with the PIDF values we will achieve better performance.
2 Likes
I am happy that its working for you! Good luck this season!
1 Like
Oh, sweet!
This was a helpful thread as we were seeing the same problem. Reversing the values, applying the negative to the math function completely fixed the problem. But we’re seeing a new issues.
Same configuration.
Mk4i, Neo motors, ctre encoders, and a pigeon.
When we rotate the robot the in any direction the wheels move into the right position but the drive motors run and never stop.
@nstrike have you seen anything like this?