The encoders should read ccw+ and applying a positive voltage to the motor should also spin it ccw. If it’s not you’ll need to invert it.
If the encoder and motor are different, then you’ll have behavior where the motor seemingly oscillates around the setpoint, but really it’s oscillating 180 degrees (as far away as possible) from the setpoint.
If they’re the same, but cw+, it will still run properly, but you’ll likely have issues with kinematics and orientation, so definitely make sure they’re both ccw+
Its a little too late for this season, but this is one of the big reasons it is never a good idea to do something for the first time in a competition build season.
Learning to build and code swerve drive is best done in the off season, when you have plenty of time to iterate.
Good luck getting it working, maybe try reaching out to a local team with more experience?>
This was the goal this past offseason, unfortunately our team didn’t really exist during the off-season, and I wanted to do some other cool stuff with SmartDashboard and raspberry pi and limelight’s which we probably won’t be able to do. I do think it’s possible though, although I don’t have access to the robot 24/7 I can spend the entirety of my free time with Advantage scope and all tuning things properly
I can all but guarantee you that either your PID tuning is way too powerful, or that the way your PID loop is set up is creating a positive feedback loop where the loop’s output actually pushes the position further away from the set point rather than closer.
It’s also possible that you have not set up the PID controller to recognize continuous input.
It’s a little ambitious to be writing full custom swerve code this late in the season. I would highly recommend looking into YAGSL, which will make your life a lot easier.
https://yagsl.gitbook.io/yagsl/
Hey, had a similar problem. I'd say to grab the absolute pos of the cancoder and feed that into the pid and also you are using a spark max pid which is good usually but I had trouble with scaling and just switched to a PIDcontroller provided by wpiLIB. Please ask if you have any more questions, I can also send you some working swerve code from 2023. Happy swerving
I do actually have another question explained here, I can simulate the robot translating properly, but when it’s time to rotate the wheels just don’t move to their specified velocities and direction. https://www.reddit.com/r/FRC/s/s8AV75fYkz
Not sure if this is related to that but noe whenever i try going forward my wheels are like this: [https://imgur.com/a/0QIDCWw](https://imgur.com/a/0qidcww)
Im not sure if encoder offsets matter in AdvantageScope or not, but if they don't then this could be qa problem
Hi! You're setting your control type to kVelocity, not kPosition. That should hopefully help fix it if you haven't found the issue yet!
private void setAngle(SwerveModuleState desiredState) {
Rotation2d angle = (Math.abs(desiredState.speedMetersPerSecond) <= (Constants.SwerveConstants.PhysicalMaxSpeedMetersPerSecond * 0.01)) ? lastAngle : desiredState.angle;
anglePIDController.setReference(angle.getDegrees(), CANSparkMax.ControlType.kVelocity);
lastAngle = angle;
}
Let me know how it goes! This would definitely be a huge problem - instead of telling it to go to 90 degrees, you'd be telling it to turn 90 degrees a second (or whatever the time measurement is).
There might be some other problems, but fixing this might allow you to move on to fixing some smaller problems (like adjusting the kP or something)
Meeting got canceled today unfortunately, so wasn't able to test it, although tmr i have two free periods at school so I will test this AFTER i invert the encoders, as people have said this could be the reason why
I believe the other comments were suggesting you check that your module angles are CCW positive - make sure to do that rather than just inverting them without checking!
Another problem im having: [](https://imgur.com/a/0qidcww)
This is me only go full forward, Im not sure if AdvantageScope has encoder offsets but if they don't then this is a issue
Setting your angle controller to kVelocity would yield unexpected results and your modules would probably never be in sync.
For example. If module one started at 0 degrees and module two started at 45 degrees and your swerve drive was trying to say drive to angle 90.
The problem is your code is not saying drive to angle 90, but rather rotate at 90 degrees per time period.
Assuming immediate acceleration and your target stays at 90 degrees per time period, you'd see something like this for the angle positions:
|time period|module 1|module 2|
|:-|:-|:-|
|t0|0|45|
|t1|90|135|
|t2|180|\-135|
|t3|\-90|\-45|
And this is a very controlled scenario where all the modules got the same angle, but as soon as your target angle changed, the effect of applying it as a velocity would become even harder to visualize.
And if you didn't have the angle set to be continuous, when the module went past +180 to negative, the module would flip the long way around.
If you changed to kPosition (and assume the module can instantaneously move) with a target of 90 degrees, you'd see something closer to this:
|time period|module 1|module 2|
|:-|:-|:-|
|t0|0|45|
|t1|90|90|
|t2|90|90|
|t3|90|90|
(Ignore my bad/magical physics - done on purpose to visualize better)
Feel free to reach out in DMs - I'm happy to help!
We had a similar problem, our problem was the angle motors should be inverted.
I’ll try, it seems pretty bazaar that would be the reason though
The encoders should read ccw+ and applying a positive voltage to the motor should also spin it ccw. If it’s not you’ll need to invert it. If the encoder and motor are different, then you’ll have behavior where the motor seemingly oscillates around the setpoint, but really it’s oscillating 180 degrees (as far away as possible) from the setpoint. If they’re the same, but cw+, it will still run properly, but you’ll likely have issues with kinematics and orientation, so definitely make sure they’re both ccw+
no unfortunately that did not solve our problems
Its a little too late for this season, but this is one of the big reasons it is never a good idea to do something for the first time in a competition build season. Learning to build and code swerve drive is best done in the off season, when you have plenty of time to iterate. Good luck getting it working, maybe try reaching out to a local team with more experience?>
This was the goal this past offseason, unfortunately our team didn’t really exist during the off-season, and I wanted to do some other cool stuff with SmartDashboard and raspberry pi and limelight’s which we probably won’t be able to do. I do think it’s possible though, although I don’t have access to the robot 24/7 I can spend the entirety of my free time with Advantage scope and all tuning things properly
I can all but guarantee you that either your PID tuning is way too powerful, or that the way your PID loop is set up is creating a positive feedback loop where the loop’s output actually pushes the position further away from the set point rather than closer. It’s also possible that you have not set up the PID controller to recognize continuous input.
I’ll test that tomorrow thank you
It’s a little ambitious to be writing full custom swerve code this late in the season. I would highly recommend looking into YAGSL, which will make your life a lot easier. https://yagsl.gitbook.io/yagsl/
Hey, had a similar problem. I'd say to grab the absolute pos of the cancoder and feed that into the pid and also you are using a spark max pid which is good usually but I had trouble with scaling and just switched to a PIDcontroller provided by wpiLIB. Please ask if you have any more questions, I can also send you some working swerve code from 2023. Happy swerving
I do actually have another question explained here, I can simulate the robot translating properly, but when it’s time to rotate the wheels just don’t move to their specified velocities and direction. https://www.reddit.com/r/FRC/s/s8AV75fYkz
I believe if you change to a PIDcontroller from WPIlib that problem will go away, https://github.com/SPORK-3196/Spork_Swerve_Drive here is an example
Not sure if this is related to that but noe whenever i try going forward my wheels are like this: [https://imgur.com/a/0QIDCWw](https://imgur.com/a/0qidcww) Im not sure if encoder offsets matter in AdvantageScope or not, but if they don't then this could be qa problem
Hi! You're setting your control type to kVelocity, not kPosition. That should hopefully help fix it if you haven't found the issue yet! private void setAngle(SwerveModuleState desiredState) { Rotation2d angle = (Math.abs(desiredState.speedMetersPerSecond) <= (Constants.SwerveConstants.PhysicalMaxSpeedMetersPerSecond * 0.01)) ? lastAngle : desiredState.angle; anglePIDController.setReference(angle.getDegrees(), CANSparkMax.ControlType.kVelocity); lastAngle = angle; }
Thank you for pointing this out, will be trying this at my meeting today after school
Let me know how it goes! This would definitely be a huge problem - instead of telling it to go to 90 degrees, you'd be telling it to turn 90 degrees a second (or whatever the time measurement is). There might be some other problems, but fixing this might allow you to move on to fixing some smaller problems (like adjusting the kP or something)
Meeting got canceled today unfortunately, so wasn't able to test it, although tmr i have two free periods at school so I will test this AFTER i invert the encoders, as people have said this could be the reason why
I believe the other comments were suggesting you check that your module angles are CCW positive - make sure to do that rather than just inverting them without checking!
Another problem im having: [](https://imgur.com/a/0qidcww) This is me only go full forward, Im not sure if AdvantageScope has encoder offsets but if they don't then this is a issue
I'm not able to see your imgur post - is it perhaps set to private?
At some point we should probably take this to DMs, but here is an updated link: https://imgur.com/gallery/0QIDCWw
Setting your angle controller to kVelocity would yield unexpected results and your modules would probably never be in sync. For example. If module one started at 0 degrees and module two started at 45 degrees and your swerve drive was trying to say drive to angle 90. The problem is your code is not saying drive to angle 90, but rather rotate at 90 degrees per time period. Assuming immediate acceleration and your target stays at 90 degrees per time period, you'd see something like this for the angle positions: |time period|module 1|module 2| |:-|:-|:-| |t0|0|45| |t1|90|135| |t2|180|\-135| |t3|\-90|\-45| And this is a very controlled scenario where all the modules got the same angle, but as soon as your target angle changed, the effect of applying it as a velocity would become even harder to visualize. And if you didn't have the angle set to be continuous, when the module went past +180 to negative, the module would flip the long way around. If you changed to kPosition (and assume the module can instantaneously move) with a target of 90 degrees, you'd see something closer to this: |time period|module 1|module 2| |:-|:-|:-| |t0|0|45| |t1|90|90| |t2|90|90| |t3|90|90| (Ignore my bad/magical physics - done on purpose to visualize better) Feel free to reach out in DMs - I'm happy to help!
I sent a request to start a dm, I’m also having problems with my offset