I am a member of team 8116 and I was wondering if anyone had tips for our robot drive. Both Technical (Code) and Mechanical (Wiring and Build), as we prep for off-season events.
Some info about our robot.
We use tank drive
Top heavy - When stopping the robot will tip back and forth. - Our lead mentor doesn’t want to make any major reworks for this issue.
We use cims motors with sparks motor controllers-He is willing to swap out motor controllers as we have better ones
Another option, which isn’t too big of a change, is going with 8 wheel instead of 6. 6 wheel will always be balanced on one side of the center-drop or the other and easily tips between the two. 8-wheel has a level center 4-wheels and only tips when under severe acceleration/deceleration. Also, use the slew-rate limiter Lexeo suggests.
In regards to the top-heavy issue, how much does your robot weigh? if you can, I’d recommend adding weight to the lower areas of the bot, and if you can, reduce weight up higher. I notice you guys have solid sides on the top of your shooter, maybe cut some holes there? You could also add some weight in your bumper since the bumper weight isn’t included in the 125lb weight limit. In regards to the rocking issue, as an absolute last resort, you could set rpm/current limits in the code for your drive.
What’s the end goal of the improvements you’re looking to make? Are you trying to increase overall performance? Solve one or more specific issues? Perhaps just do cool things and learn along the way?
Sounds like at least one specific problem:
Spoiler alert, slew rate is the software-fix answer. But the “why” is interesting.
It’s a comon issue for high “center of mass” robots. The possible solutions fall out of doing a free-body diagram on the robot itself. It’s not extremely simple but still approachable. Here’s a simplified model:
F_{a}, the force which is accelerating the robot’s mass forward or backward - what you generally want on the field.
F_g, the downward force of gravity keeping the robot (hopefully) on the ground
F_n, the upward force of the floor acting on the wheels to keep the robot from going through the ground.
F_n is actually the sum of three forces - one from each wheel set as it supports the weight of the robot. This means that the net F_n force can change in magnitude and direction however it needs to for countering the other forces… but only up to a point. Wheels aren’t glued to the ground, so those three little component arrows can only be positive (point in the direction drawn). This means the maximum angle F_n can ever point is along the axis from one axis through the center of mass.
When only one wheel is exerting any force, it starts to act as the pivot point for the center of mass, to rotate about that point. If you rotate too far, the robot tips.
Assuming we’re operating right at the point before any motion occurs, you have to balance the following free-body diagram for no motion:
Presumably - the force of gravity is constant, and you want maximum robot mass. This means F_g is constant.
For a given \theta_n, F_n's magnitude will also have to be fixed to counter out F_g in the vertical axis. This in turn sets what F_a can be at this operating point.
Which leads to the two main engineering ways to prevent tip:
Limit F_a so it will never exceed the magnitude of the horizontal component of F_n
Increase \theta_n by moving the center of mass closer to the ground.
Since 2 is already deemed out of scope, you’re left with 1.
To a very simple model, drivetrain velocity is proportional to the voltage applied. A slew rate limiter limits the rate of change of voltage. Therefor, limiting the rate of change of voltage, you also limit the rate of change of velocity.
Since acceleration is the rate of change of velocity, slew rate limiters (generally) limit acceleration.
Therefor, a slew rate limiter on drivetrain commanded voltage achieves 1
…
Now, is it actually that simple? Nope. But can you ignore all the other stuff? Probably! Just pick a slightly more conservative rate limit.
I wonder if there is a performance improvement using other than trapezoidal? There are an infinite number of choices. I’m thinking the motor braking is hard at the beginning because of high speed and little motor breaking at the end because of slow speed. Reverse that action by slowing gently at the beginning and slow down faster at the end. easing functions (in/out)
The set motor speed would be like an upside down easeInCubic. Ease in is starting slowly and then speeding up the movement as it comes to a halt.
Picking up on this, “slew rate limiting” is best done in “open loop” driving by setting a voltage ramp rate. It makes the robot more sluggish, but at least you don’t tip! I’m pretty sure these are the functions you want to use (but I’m not our programmer)
One other thing to look at is what chassis are you running? If it is the Andymark KOP chassis the center wheels have a 1/8" or so drop so the robot will teeter on those center wheels. All the programming in the world will not change that tipping.
Yes, the same slew rate is used for both up and down ramps if internal to the Talons. Using slew rate to prevent brownouts on increasing speed causes unacceptable “coasting” when trying to stop. Using slew rate on decreasing speed causes sluggish starts. We’ve code our own when two different rates are needed on one motor controller.
