My team has been working on using the SwerveSetpointGenerator from Pathplanner to calculate the maximum acceleration we can have our drivetrain accelerate at without hitting current limits or having our wheels slip.
I was pondering the physics behind the acceleration calculators, and I noted that at least the Pathplanner calculator assumes the mass of the robot is equally distributed across all four modules. While the robot is not moving this would be true if the COM of the robot is centered compared to the modules, but it would not be true if the COM was off center, or if the COM was not exactly on the floor and the robot was accelerating.
While the net possible acceleration ends up remaining constant with these variations, there is usually more weight going through certain modules than other modules, and since static friction is proportional to the normal force going through a module, this means that the modules weight is taken off of produce a lower proportion of the force necessary, and the modules that more force goes through produce a larger proportion of the necessary force to accelerate.
The SwerveSetpointGenerator does not take this into account, which would cause modules with less normal force to slip and modules with more normal force to not be providing as much force as they could, leading to underacceleration.
Has anyone found a way to compensate for this imbalance? I have been thinking about it and am yet to find a simple solution. I do have one that I think would work but it seems overly complicated and I would love to know if someone else has a good solution before I go through the whole process of working out the kinks with my solution.
Funny enough I actually did take that class last year, so I kinda see what you’re talking about. It isn’t too hard to calculate the normals on each module, and then you could theoretically reapportion the force each module is providing based on that weight.
The issue here comes in when you have a large portion of your normals on only one side of your robot, say the left side, perhaps because you were taking a circular maneuver where you stay at the same speed but you accelerate to the right. If you also are told to accelerate tangentially to your velocity, you could run into an issue where it would be impossible to accelerate above a certain acceleration without imparting torque on the robot (since all your force would be coming from only the left side of your robot).
LMK if this makes sense or if I did a really bad job explaining this issue.
I guess that would be one solution, just limiting acceleration so you never get to a point where finding a suitable solution is infeasible. This is really only an issue if you have a pretty high COM or one that is very off center, so optimally you would just build a robot with a low and centered COM to avoid these issues lol.
In theory, this is solvable using Second Order Cone Programming, but I think it might be excessively computationally intensive to be able to run on a RoboRIO.
Here’s the wikipedia on SOCP if you’re interested:
Linear Programming almost gets you there, but it fails because modules will slip if the norm of the forces on them is too high, so it isn’t a linear constraint. You end up with a constraint of the 2-norm of the forces.
Here’s an article on linear programming if you’re interested in that as well:
