The Swerve Drive Specialties MK2 base code is now public. It can be found here. github.com/SwerveDriveSpecialties/Example-Swerve This should make getting a MK2 swerve chassis driving pretty simple and easy.
Hey I’m working on getting swerve working on a practice bot for our drivers. I set all the off sets so that the wheels go to the correct starting position but now when we drive it and then disable and then go to drive again the wheels don’t go to the original place I want them to go. They instead go to the place they ended the last time we drove. Does anybody know how to fix this problem
Our team purchased the mk2 swerve modules built a chassis.
We have the 2910 code loaded and have verified all pwm, analog and can ids.
When we run the code, the steer motors spin continuously. They never find home. We suspected it was a tuning issue so we put the bot on the table with wheels not touching the ground. Same issue. 2910 code base has p=0.5 i = 0 , d = 0. So we tried to lower p still does same thing.
We have verified each steer encoder returns valid values via smart dashboard.
Not sure what to try next.
Someone with specific knowledge of the SDS sample code will probably have more specific advice. However, in case it helps, here is a little generic advice.
Are the steering controllers getting a reasonable PV value (the scaled wheel position in radians or degrees)? You should be able to pull that up in SmartDashboard. It’s not clear from your post if you are seeing valid encoder values at the controller PV or in some variable before reaching the controllers.
Do the steering controllers have a reasonable setpoint? The scaling for the setpoint needs to match the PV (e.g. radians or degrees). Pull the SP up on SmartDashboard as well.
If you have a constant zero at the controller PV and anything other than zero in the controller SP, the steering motor would just spin as you described. If you have something scaled wrong coming in to the PV (e.g. 0 to 2 pi), but the controller SP is in degrees and happens to be something like 90, the PV could never reach the SP and the motor would just spin as you described.
If the P gain is too high, the controller output will usually oscillate (change back and forth between too much and too little). A tuning issue would be very unlikely to result in spinning in just one direction without stopping.
Thanks for the input. I will look into that.
Do your motors spin only one direction and only at full speed regardless of the input (forward or backwards)?
They seem to go only one direction. Occasionally they briefly stop but continue in the same direction. Speed seems to be very fast. But Idk if it’s full speed. Here is a video. https://www.chiefdelphi.com/uploads/default/original/3X/9/0/900727199f1f9d85b4099c79990d3c271b9920a7.mp4
OK! So we had the exact same symptoms. It looked like this for us:
Note: RoboRIO is haphazardly connected since we were trying a different RoboRIO to see if that was the issue.
TLDR: We traced it to our Spark Max speed controllers, and when we installed borrowed Spark Max controllers from another team, the problem went away. We’re currently working on writing up our fault isolation process and findings to send to REV to try and figure out root cause. Tagging @Greg_Needel for awareness, feel free to DM me for more details in the mean time.
The symptom is that for any PWM command that isn’t 0 or +/-100%, it will command the motor 100% forward. 0 and +/- 100% command stop the motor. The issue only manifests itself with PWM commands, and occurs when driving both brushed and brushless motors from the Spark Max while the motor case is electrically connected to the chassis. We were able to replicate this behavior with all of our Spark speed controllers running NEO motors and 775 motors. A Talon SR controller did not exhibit the same behavior. Whether or not the Spark Max speed controller is electrically isolated from the chassis had no effect. The Spark Max light always correctly reflected what the motor was doing, and not what command it was receiving over PWM.
Here is a demonstration of the behavior. Pay attention to the light on the Spark Max. The same command sequence is being given to the motor all 3 tries:
I don’t have video of the 775 attempt in brushed mode, but it did the same thing.
The reason you see the brief stops on the steering motors is that when the module reaches its angle setpoint, the PID drops the motor command to 0%, however the module inevitably overshoots, which results in the PID attempting to provide a reverse command signal. Since the controller is not able to command reverse due to this issue, the module keeps spinning the same direction.
The last test, we electrically isolated the far (front) left module from the chassis and it behaved normally running on our suspect Spark Max speed controllers (this doesn’t work to fix all of our modules, but it did for this module). The far right module is electrically connected to the chassis as normal, running on our suspect Spark Max speed controllers. The near right module is the same as the far right module, except it’s using one of 2910’s Spark Max speed controllers. The 4th module is not being commanded to move in this test. After this video we swapped steering speed controllers between the two right hand side modules, and confirmed the behavior moved with the speed controller location.
Other notes: All were updated to latest firmware at the time (1.4.0) and running on the associated API (1.4.1) . We did try reverting to an old firmware and saw no change. We did multiple tests with multimeters between various ground points and the chassis as well as the hot side of the (closed) main breaker and PDP to the chassis and found no connection. We also checked for voltage differential between the chassis and the battery negative terminal while running the modules.
To my understanding, all of our Spark Max speed controllers were purchased at the same time shortly after they became available for purchase, and they all exhibit this behavior. It’s possible something happened to all of them at some point that caused an internal issue. There’s still a possibility that there’s wiring issue that can cause this, but we’ve done our best to weed it out per the above.
I would recommend trying some different Spark Max speed controllers, either yours or another team’s, and see if that fixes the issue. It may also be worth peforming some of the tests we did to confirm you’re experiencing the same issue.
Thank you so much for getting to the (almost) bottom of this.
I was ready to get a PWM tester out but I never did. I will try that tonight.
Same problem for sure.
Tonight we switched 1 steer Spark from Pwm to CAN control and it worked. Had to play with PID P value a bit but it works.
Next we will apply same change to other 3 and see what happens.
Thx for all your help.
@TOPFUEL & @Nuttyman54 Our engineering team is looking at what you’re seeing and will get back to you as soon as they can. We also see your email to our support address, so we may follow up there before posting back here on CD.
just a quick update
@TOPFUEL and the team wired all sparks through CAN instead of PWM and drivetrain worked perfectly.
I went ahead and switched to all CAN controlled spark maxes but no luck. Still getting continuous rotations and steering. I checked our shuffleboard and I noticed that these position values seem really high. Maybe I’m missing something, but these look weird… right?
I looked at our targetAngles and they fit within the 0 to 2 pi range so I ruled that out as a potential problem. I modified our PID P values and while it did slow down the rotations as expected, it didn’t actually stop them and make them work as expected with any sort of controller input. Any thoughts as to what I should be looking at to troubleshoot further?
Not sure if this is relevant or not, but when I apply a drive speed forward or backward, all rotation stops, but once I let it go back to no drive speed, the random rotation begins again. Also, when I am throttling and applying a rotation, the wheels rotate at different speeds and are in different directions as if they were “out of sync”. I feel that this is due to (maybe) the random rotations they go through when no input is provided.
Hi @Kraj011 ,
I got the email from the post which i think you deleted. The code i used was not the example you referenced. I cobbled Team 2910’s code that was split into a couple of different repos and simplified some things and recombined them in our repo, https://github.com/olentangyfrc/2910poc in the experiment1 branch . I was having trouble tracking down which code was being used in the actual deployment. I have subsequently looked at the example and they are essentially the same though.
those position readings do look suspect, but i do not think that is what is important at this point. I think you want to look for the output from this line from line 110 of SwerveDriveTrain
SmartDashboard.putNumber(String.format("%s module angle", module.getName()), Math.toDegrees(module.getCurrentAngle()));
The module position data is different from just the encoder values.
I am far from the electrical guy, but my first path would be to confirm wiring. Those encoders should be going through roborio analog ports
The code from our repo uses a Pigeon on CAN 21 (which i actually hard coded 0 values because i was having some confusion with the way gyro input was being used to calculated kinematics) you can easily change that to the original NavX implementation in the Superstructure class if you have NavX.
let us know how you make out.
First off thank you so much for the code!
So I went ahead and looked at that in the smart dashboard and while I am getting a reading, when the modules spin (I have it lifted up so that it doesn’t actually spin on the ground) the reading doesn’t end up changing. I tried spinning them manually and the reading still doesn’t change. They appear to be plugged in properly into the Analog In ports. The reading does oscillate, but only by thousandths of a revolution. I’ll do some more troubleshooting with the encoders and keep you posted! Thanks!
EDIT: So when I disconnect the encoder I get a different reading than what I get if the encoder is connected so I know that its picking something up.
make sure you have the correct connection to ground.
Turns out our encoders were wired incorrectly . We are currently running the modules all through CAN and it is working perfectly with the example code!
We are using the MK2 modules and “mostly” the 2910 base code for swerve and we are having a strange issue. Sometime the robot likes to rotate, very slowly, when it is supposed to sitting still. This is periodic and can happen both in auto and telep. Any ideas?
Are you sure it’s supposed to be sitting still? Our joystick tended to get stuck with the turn axis slightly off from 0 even with calibration, so we had to add a larger headband