Getting to the yellow mogo is quite an essential strategy, and getting there fast is really important in ensuring an autonomous win. If we go slowly then it’s fine, but if we go fast our robot hits the goal which knocks it away and means our claw can’t reach it - our claw needs to be right up over the mogo.
We’re using a PID control for it (0.0014, 0.00165, 0.0002) but even so it doesn’t slow down enough before impact. Is it possible to tune this to do that? Or do people use other strategies to not knock it?
Mabry you could look into a pad. This theoretical pad would allow for the impact to be softened so that it doesn’t send the goal flying. You could look into usin something like grip mat wrapped around a piece of C channel or a cleverly setup bumper with some smaller flex wheels. Or mabey some stretched rubber bands to absorb the blow.
Or you could set the speed 100% for the majority of the journey to the MOGO, but after you’re about 20mm away make the speed much slower…
In your code you could make it so you can go fast for most of the distance to it and then change your velocity to be slower when you’re a few inches away from the goal so you dont move it when you bump it
Oh yeah - I should’ve mentioned the third thing we’ve tried, which kind of works: going right up to it, stopping, then limiting max speed and completing the distance. The PID takes a while to settle though so it ends up being annoying
Did you mean to say PID? Or is it a physical pad on the robot?
A physical bumper 20 char
If you are using a coasting break mode, then you could try using break.
Also, the K constants for PID are relative to your gear ratios and drivetrain design, so there is no right answer that would apply to different robots. Nevertheless, your Kp seems low for any drivetrain. You might want to do some research on tuning the Kp. For this application, I don’t think you will want to use an i_gain (Ki) or d_gain (Kd), just zero those out and try the p_gain by itself.
Any higher than that and it was oscillating a lot
For a driving forward command, oscillating would be going backward after it reaches the target, is that what’s happening?
Yeah if kP is too high a PID controller oscillates. That’s why I don’t have the kP higher. Also too high a kP would only result in it going faster which is suboptimal here
When your forward driving command reaches the target you should exist the PID loop, don’t ever go backwards. Once the target it reached the move is done.
I suspect that something is not right with the p_gain.
I think you’re misunderstanding, oscillation is not a problem I’m having.
If you use a sensor to determine when you touch a goal with your clamp (such as a limit switch or bumper sensor), you can make it so your robot instantly clamps on as soon as it detects the goal, before the goal has time to fall over or get knocked away. This would allow you to do away with pid all together and simply floor it with full speed towards the goal until it detects that contact.
A similar solution exists(and the one that I preferrer bc its the one I made) that uses a deployment type of mechanism. Have lever that when pushed will activate a clamp.
One of our teams first designs for a clamp(and latter ones as well) follow this idea.
As the course of the season progressed we have iterated on the design and have ended up with a pneumatically operated “pressure sensitive” clamp thing. The pressures sensitive part only works on deploy, which is a bit of downside but greatly simplifies auton.
And this is just an excuse to talk about my clamp