Our team has just started preparing for VEX Robotics In the Zone and we were wondering if we could calculate some stuff. One problem we already had last year was the fact that, when programming the autonomous with encoders, the motors stopped at the right moment, but there was so much inertia that the robot was moving 15/20 cms further. Does anyone know how can we calculate that inertia and program our robot according to it? We guess we’ll need to know the friction coefficient of our wheels in order to that so, if anybody knew how to calculate it, it’d also be really helpful.
You may want to do a search on programming PID (proportional, integral, derivative) control which is programming that tells your motors to slow down as the encoders get closer to the destination. Loads of PID discussions on this forum.
I’m the programmer for my team and I just do really simple programming to stop drift. All I do is run the motors in the opposite direction for a very little amount of time, usually 50-100 msec on a very slow speed such as -5. I don’t know if this is what you’re looking for but its a simple solution to the drifting problem.
It depends if your robot is skidding or rolling the extra distance (when skidding, the wheels are sliding over the ground, when rolling, the momentum of the robot is causing the wheels to keep spinning for a little bit after power is cut. Regardless, PID is a good place to start. If tuned right, your drive should slow down a little bit before you reach your target distance, do that way your robot has time to slow down.
Apologies if this sounds rude, but you’re going about this completely the wrong way. I don’t really even see how knowing the coefficient of friction would allow you to find the robot’s calculated drift.
To mitigate this problem of drift, you need to be using some motor control algorithm to slow down as you reach the target like PID or TBH.
From the sounds of the solution, the motors were being turned off and the robot kept moving, but if the motors were forced the other way it stopped OK.
Being able to stop OK means its is not an issue of friction with the surface.
Suddenly throwing the motors from (presumably) 127 to -5 while the robot is moving along is really bad for the motors.
Do as others here have suggested: PID. You don’t even need to do much for it. You could just cut down incrementally at certain distances from your target. Dropping about 25 at a time each 5 cm away starting 20 cm away is probably a simple version that will get you what you want.
I’ve done a combination of “giving the motor a reverse pulse of current as a break” and PI distance control when programming my auton. As ways to make autonomous consistent and to stop the “slipping” you talked about in some necessary scenarios.
Take the first 15 seconds of the video as an example. I programmed the red robot 3921A.
You can see that:
The robot drives forward to pick up the cube. In order to stop precisely and cleanly in front of the cube just so that the robot doesn’t knock it over, I gave the base motors a reverse signal with magnitude of 30 (I believe) for 200ms to break, and then roll up the cube.
The robot drives forward into position and PI controls itself to move back from overshoot. Encoder driven.
The robot strafes sideways, no PI control, no break, simply encoder controlled. Strafing is slow and the way mecanum wheels are means it doesn’t slip overshoot significantly.
The robot goes forward and turns. Both moves PI controlled. Going forward is encoder controlled, turning is gyro controlled. In both moves you can see overshooting and notable amount of re-adjusting done by feedback control.
The robot goes forward to score. Moving forward is very slow and is simply encoder controlled.
I’ll throw the program here just in case you wanna see it. Robot is gone, but program lasts. (I think I’m the only one on this forum who’s ever just posted robotc codes and called it a “program reveal”. l.o.l.) https://vexforum.com/t/3921a-skyrise-program-reveal/29377/1