Back to some more usual content…
For quite a while, I was pretty sure the acceleration limit math I came up with was incorrect. But, it was keeping the robot from tipping over, and we were focusing on auto development, so I didn’t get a chance to redo it. Until, the week before districts, our practice charge station broke during auto testing. It was late that night, so we went home, which meant that I had plenty of time the next day where I couldn’t test auto. So I redid the acceleration limit the night before districts, and fortunately it worked first try and our driver never complained. This time, I’m confident enough that the math is correct to share the Desmos calculator I used to develop it:
Why all the math? Because math is fun— a static acceleration limit could keep your robot from tipping over, but this way we can not tip over and still drive as hard as possible. Since I’m already talking about it, I’ll also describe in a bit more detail how the whole thing works.
The first step is to calculate your robot’s center of gravity. I wanted this limit to always work, so we determined the CG of the chassis separately from the arm, and then are calculating the CG of the entire robot live based on arm position. You can add as much or as little detail to this part as you want— so long as you can effectively determine the mass-moment of any mechanisms you care about. We corner-balanced our robot to determine chassis CG, and then used motor current draw to hold the arm level to determine it’s apparent mass at a chosen length.
You can see the result of the CG calculation in the Desmos thing; the point labeled Robot CG with the orange lines through it.
Those orange lines are for the next step— determining the distance between the edge of the wheelbase and the CG. We need this distance for the sum-of-torques problem that determines the actual acceleration limit:
The way this works is by finding the intersection between the direction-of-travel line passing through the CG and the square created by the robot’s wheels. This point is labeled “Wheelbase Edge” in the calculator, and the orange lines represent how the correct edge is chosen— the orange lines are the boundaries of the angular regions subtended by each side, and then the direction opposite the direction of travel is used to pick the region. Basically, we need the edge opposite the direction of travel. Currently, this assumes a rectangular robot, but I might expand it for any number of swerve modules using some kind of convex hull algorithm.
As a nice sanity check, I can use create a polar graph of the max acceleration function, and get a nice rectangle:
Predictably, the acceleration is greatest when driving toward the corners, because the distance to the wheel is greatest there. Additionally, the effect of the arm is apparent, as the max acceleration is greater going towards the arm.
After just adding the polar graph thing to the old one, it turs out it was even more wrong than I thought:
Though it is interesting.