I’m trying to rewrite our swerve drive code using the new AdvantageKit Release while also using 6328’s 2024 adaptation of 254’s SwerveSetpoint Generator (to create feasible setpoints).
Looking through the code, a crucial element tends to be the maximum acceleration of the module (m/s^2 (I assume?)) and I don’t understand how to get that number. For 6328’s code, it was roughly 77 (which is also why I’m not sure about the units being in m/s^2, it may be in rad/s^2 ), which seems very high to me.
How do you empirically maximize for an acceleration that would be consistently achievable, while avoiding slippage in varying tread grip and carpet quality? Is there a nice way to record some output of the motor to visualize in AdvantageScope?
FYI we have Kraken X60 drive, SDS Mk4i, and we do have 1/2 field’s worth of carpet and space to do any empirical testing needed.
since youre using krakens its fairly easy to view acceleration in phoenix tuner X. it would be in native units i believe, rotations per second squared. if i were you id just drive full speed and look at that graph, converting units as necessary.
For this kind of tuning I think it’s useful to create a tiny separate robot project (click “new project” in vscode), and make that project do just one very simple thing. For example, you could make your robot hold the swerve steering at zero, set the drive output to 100% for two seconds (use a Timer). Print the wheel velocities in your main loop, e.g. printf(“%f %f %f %f %f”, t, v1, v2, v3, v4), and paste the output into a spreadsheet and make a chart.
What do you think the chart will look like? I bet you’ll be surprised by what it actually looks like. You could fiddle with the spreadsheet to compute the acceleration in each time step, and I bet you’ll notice that it’s not at all constant. Then look at the setpoint generator code, how does it frame the problem? Does it match what you see in the chart?
You could also do a bit of fiddling in the spreadsheet (or by adding position to your print statement), to calculate what the distance traveled. Is that the same as the distance the robot actually traveled in two seconds? I bet it’s not close at all. Why?
What could you do with your little robot program to learn more about what those curves are telling you? Maybe the wheels are spinning, so try lower output. Does the actual-distance-traveled match the computed-distance-traveled if you slow down? Maybe robot skids when it stops, so try ramping the speed at the end. Make tiny simple changes that you understand 100%, and then look at the data.
This sort of experiment doesn’t take long at all, and at the end you’ll really understand what’s going on.
You can find the slip current first. Put the robot against the wall. Plot the stator current and the velocity. Increase power until the you see the velocity go non zero. That is your slip current. Set that value as a stator limit on your drive motors then when you run you acceleration test you won’t have slip.
note: in motion, more force is applied to the rear wheels than to the front wheels: the front will slip well below the static limit (it is not hard to “wheelie” a light robot), and the rear will slip well above.
), which seems very high to me.