Our robot for last year’s challenge has been pretty tippy, a lot of that could most likely be attributed to a higher than normal COG, but I was looking to see if there were any way that I could minimize the effects of this issue in code. I first tried to limit the acceleration but that just made it feel sluggish, although it did fix the issue, the issue seems to be more prominent when the velocity is closer to 0(I don’t know if that has to do with different torques at different speeds). One of the ideas that I had was limiting Jerk, although I didn’t know if that would help at all, especially since I’ve never seen it used in practice. We basically just directly pass the values of our joystick through to the motors after going through deadband, velocity, and acceleration functions. Is anyone else using a more complex drive code, or is it better to keep it simple?
If you have a sensor that tells you how high your elevator is, you can limit your drive speed when your elevator is above a certain point. That’s probably the easiest thing to do. Another thing you could do is have a gyroscope on your elevator carriage that sees when you’re about to tip to bring the entire elevator down to prevent the tipping. You could also have it on a button for the drivers for simplicity.
Great idea, we actually considered this for our first robot idea, but after realizing that the design was overweight, had to rebuild our design and ended up changing it such that it had a permanently high COG(meaning we don’t have an elevator). But otherwise, we were planning on changing the maximum acceleration based on the elevator’s state and possibly helping out the driver by automating our elevator.
We worked extensively with this last year, and found that the only “safe” place to limit acceleration (the actual force that causes the tipping, velocity itself has nothing to do with it), is when going from stopped to moving. This is because if you limit deceleration, you can put yourself in an extremely dangerous situation of not being able to stop because your control system is trying to prevent rapid deceleration, which can cause you to crash into walls, other robots, people, etc.
We ended up limiting deceleration but also having an escape clause that if the joystick goes to zero it bypassses the acceleration limiting function.
Per @Maxcr1 - Even with a super-ideal control system that limits acceleration, or moves the drivetrain in such a way as to attempt to correct for tipping in progress, all of the solutions tend to result in uncommanded motion.
In standard design practices, you’ll generally want to try to prevent the bad behavior from happening first, and only after exhausting these possibilities explore correcting the bad behavior after it occurs.
Solutions I’d try first, as suggested:
- Lower center of gravity if at all possible (more weight on bottom?)
- Inhibit mechanism raise until drivetrain speed is low enough
- Limit maximum motor command while mechanism is raised up
- Automate the raise/place/lower cycle and tune to be as fast as possible, rather than relying on drivers to execute it perfectly each time. Maybe inhibit drivetrain during the cycle?
One of the hardest things to fix in software is a high center of gravity .
Although we never really tried avoiding tipping in code, I believe it can cause an unnatural feeling for the drivers. One big difference between our designs of the 2018 and 2019 robots, is that the electronics board was at the bottom of the robot. In the 2018 season, we didn’t plan in advance where to place the board, and in the end it was pretty high and the robot was very tippy.
So I suggest planning ASAP the location of the electronics board and putting it as low as possible.
Another take on this is to have an acceleration limit tied to your elevator height such that the higher the elevator is, the lower your allowable acceleration. All the way down means full acceleration, all the way up means minimum acceleration.
You can also have a “trim” adjustment on your target speed that changes based on the robot angle out of the gyro (assuming that your drivetrain is on a PID). That way if your robot starts to pitch forward or backward, the drivetrain can respond and get the wheels under the CG.
I’ll note that we haven’t actually tried either of these, but I want to, and they both work in theory.
Once again, we don’t have a motorized mechanism, we just have a really high COG, and unfortunately there’s no way of changing that, but I think it would be worth looking into getting feedback from a gyro to tune it.
whoop that’s what I get for not reading the whole thread prior to responding .
So if you’re going down the stabilization via software route, for accurately detecting tipping behavior and correcting for it, a combination of accelerometer and gyroscope may be good to look into. Accelerometer for detecting when you’re upright vs tipping, gyroscope for detecting motion indicating “about to tip”, and both used to cross-check each other and reject noise. IMU’s and Kalman Filters are some things you’ll see in this area.
When I see folks say stuff like this, I tend toward saying “Maybe true, but prove it” - You may have done this already, but in case not:
One thing I haven’t personally tried, though it might be interesting to work through - do the free-body diagram of the robot in 2D, modeled as a blob with a CG at some height above the floor, floor normal forces at each wheel location, and propulsion forces exerted horizontally. Something like this?
I think the goal would be to solve for the acceleration of that center of gravity as a function of propulsive force, to predict at what point at which the center of mass travels more than W/2 distance in the horizontal direction (and therefor tips).
I’d be curious to see if this could produce an analytical solution to put design parameters on your motor speeds, and figure out how much any particular reduction in CG height (H) helps? Could help inform the design process to say what the benefit of even an inch or two of CG height reduction could do.
For me, I don’t see a software anti-tip solution or swiss-cheesing the higher-up components as a fundamentally different operation. They’re just impacting different variables in the same equation. The key is to prove out which one meets your performance criteria (desired propulsive force) for the least cost (time/money/resources)
Edit 2: Buyer beware. I am fairly certain the analytical solution requires a differential equation.