Our swerve drive wheels aren’t acting in unison and become disoriented fairly easily. I have no idea why or how, I just know they are. Any help would be greatly appreciated! Even when lifted off the ground the wheels still don’t work in one direction or speed. I have zero experience with swerves and all I know how to do is to offset the wheels and straighten them using feedback from ShuffleBoard. (Note: I do not have current access to our code as Github is giving me errors and I’m posting this from my own device. However, possible solutions are still welcome and I will update this post with our code as soon as I can.)
There are a lot of possible places were things can go wrong with swerve, and I would start breaking down the problem in to small pieces.
-
Are your encoder angles from your robot reporting the right values. I would recommend just printing the values to SmartDashboard you can put this in your drive systems periodic funtion if you are using command based and moving each module by hand. Are the angles what you expect or are they giving a strange value.
-
It is a good idea to the same thing with the drive encoders. Put the bot on the ground next to a tape measure. Push the bot a known distance is the distance value the same as what is displayed on the smart dashboard.
Once both of those are correct.
-
Check to see that the code sending the right information to the modules. You can do this by putting the robot up on blocks and doing a similar printout of the value being passed into the control loops onto the smart dashboard as you try to drive. If all of these values look correct it then you need to find out if your control loops are working correctly.
-
Plot the actual position of your modules (encoder reading) vs the value fed into your control loop. Does your actual position follow the control loop value. If not there is likely something wrong with the gains in the control loop.
2 Likes
My encoders are a little bit off, but that’s most likely human error. We measured moving the robot 1 ft and pushed it and shuffleboard gave us 22,464 (what does this mean)?
Can you give some more information on what swerve modules you are using. What types of encoders you are reading on the drive wheels, where the encoders are located, and gear ratio?
Each manufacture is slightly different.
The counts per revolution on the encoder can be different depending on the manufacturer and type.
For example the REV NEO built in encoder function will typically count in revolutions so if you read the encoder after one turn of the motor shaft it will say 1.0. I have not used a Talon 500, but based on the docs I believe it will natively output 2048 counts per revolution. (Someone feel free to correct me if I am wrong). You could be using a variety of different encoders.
Then to determine what the encoder count should be for a given distance of movement you need to know your wheel size and the gear ratio between your wheel and encoder (the encoder can be in the motor).
If your wheel size is 4" diameter then if you calculate the circumference = pi*diameter.= 12.5664 inches per revolutions of a wheel.
Then lets say your gear ratio is 10.25:1 between the encoder and the wheel. This means that the encoder shaft would spin 10.25 times per each wheel turn.
Then we can calculate the distance traveled per encoder count.
distance_per_encoder_count = circumference / (gear_ratio * encoder_counts_per_revolution)
So for my example above a NEO would report:
12.5664/(10.25 * 1) = 1.1703 encoder counts per inch of travel
So multiply by 12 for to get counts per foot = 14.048 encoder counts for 1 foot of travel.
You should be able to do a similar calculation to determine the number of encoder counts per foot you would expect. Of course you will have to use your wheel size, encoder counts per rev, and gear ratio.
I would then recommend either using a method that would do this calculation and return the distance traveled, or on most encoders you can change the scaling in the setup configurations to output the distance units you would like rather than raw counts.
If you plan on using the wpilib built in trajectories it is helpful to convert this distance into meters.
Hopefully that was helpful.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.