My team is currently working on integrating swerve drive into our robot for this season. We have decided to use WPI’s example Swerve Bot Code. We have our encoders(for the turning motor), the gyroscope, and our motor-types integrated into the code. We keep having the issue of each module not going to the intended point. It seems as if the modules are continuously getting different inputs and therefore are attempting to go to many different positions at once. Even when the joysticks are not being touched, the modules will move back and fourth to different positions. We attempting to use straight M/P/S and RAD/P/S in order to remove any variables from the joystick, however this yields the same result. We used to SmartDashboard to attempt to trouble shoot, isolating each step of the swerve code process. It seems as though the conversion from joystick values to Chassis Speeds is working correctly, however I have the notion that the error maybe the conversion from Chassis Speeds to individual Module States. I have searched all throughout the code and cannot seem to find any errors. I also think that the Encoder Resolution may be the part of the issue. We are using the Hall Effect Two channel Encoder From AndyMark(Hall Effect Two Channel Encoder - AndyMark, Inc). The swerve module we are using is the Swerve & Steer Modules from AndyMark(Swerve & Steer - AndyMark, Inc)
Here is the link to our GitHub Repo with the current iteration of the code: https://github.com/frcteam2080/SWERVE
Try to multiply the 7 encoder pulses by the ratio of the pg71 gearbox and steering ratio of the swerve modules. Then tune the P value of the turning pid.
I understand that, but as your code is written now your azimuthal encoder has a resolution of \frac{2\pi}{7} radians. That’s totally insufficient for azimuthal control.
If your encoder is pre-gearing, you need to factor that into the number of pulses that occur in a revolution.
The number 7 you see under the kEncoderResolution was the number of pules per revolution(sorry for not clarifying). I understand that Encoder Resolution is different from pulses, however I am having difficulty calculating this value. To my understanding(for incremental encoders) resolution = Operating Frequency x 60 / Max RPM. Our max RPM is 90, however I can’t seem to find the operating Frequency anywhere. Any ideas on where this information could be located?
I don’t know what resolution you’re calculating there (how can operating frequency affect spatial resolution?).
You need to set distancePerPulse to whatever angular distance the module turns per pulse of the encoder. There are 7 pulses per rotation on the model encoder you have specified. How many times does the encoder shaft (or magnet) turn for each rotation of the module?
I was playing with the kEncoderResolution value, then outputting that encoder tick reading to the SmartDashboard. A change of the kEncoderResolution would edit the “number of ticks” for the encoder. Therefore I believe that the resolution value must be set to a certain value(particular for each setup) as this will allow for the rest of the math to set the PWM of the turning motor to the correct value. I am just confused on how to find the correct encoder resolution for my setup.
What I’m telling you has nothing to do with the code. It has to do with the actual physical resolution of your sensor. You are describing a swerve module whose azimuthal resolution is on the order of 1 radian. That will not work.
I think my explanation of the swerve modules is a bit confusing. The encoder on the turning motor came preassembled and attached to the assembly from AndyMark(Swerve & Steer - AndyMark, Inc), so is possible that I don’t have the encoder configured correctly? Or do we need to change our encoders for a different type?
Okay, that means the encoder is in front of some amount of gearing. You need to take that into account when calculating how many encoder turns occur per module turn.
If you can’t determine the correct conversion factors analytically, sometimes doing an empirical measurement may help point you in the right direction. Remove any scaling factors in your code and rotate the module 1 revolution and see how many pulses were detected. This will be close to the right value and can help you figure out what factors you’re missing. Don’t use the measured value directly because only a few ticks of error may compound.
Yes, it is a simple conversion for this, however I do not understand as to why the module would “appear” to be getting multiple set value with only one input value. Wouldn’t the module just go to the wrong position and stay there?
