Hey all, I received a question about turning correctly, and I thought I’d share my response, so I put it up on our team’s website. Enjoy!
Great tutorial. Thanks very much. Few questions:
Did you guys use purely P controller for any base movement? If so, how does the actual translated value correspond to your real world measurement and expectation? In another words, how is the accuracy?
I assume you set a speed limit for your P controller to allow adjustments. Is this a hard limit? It doesn’t seem adjustable in your matches or description.
Keep it simple. Now I get it. I wrote full blown PID encoder/gyro error correcting controllers with adjustable power and wait time parameters, but they are not as accurate as this because I kick up the autonomous speed limit too high to save some time.
Plus, after a season’s experience with gyro and IME, I don’t trust them anymore. IME is okay if set up correctly, but because it does not directly measure the putput axle, in my experiment the error can be ± 30. Gyro is just, uhh, a huge pain… you can’t move your robot when program is starting… we had to write LCD codes to manually initialize it every time before match just to make sure… you have to make a separate task to process the gyro value to be able to zero it in a snap just like encoders… we forgot to start that task in autonomous and lost matches… and, the gyro’s reading is in fact scaled up or down based on temperature. This is in the gyro fact sheet. This created major pain for us.
Not to say these sensors are not awesome. I enjoyed programming them greatly, facing these challenges. But… Keep it simple, guys.
Big Red Encoders are now my favorite.
Correct, purely P. Of course, you wouldn’t use I without D, so the question is, why not use D? I’ve found spending time making sure you are perfectly where you want to be simply isn’t fast enough. In general, if your robot is quick, D will never converge no matter how fast you try to make it, to the point where it’s better off just not using it.
To counter-act the slight in-accuracy, don’t reset your encoders completely after each action. Save what they are, then reset them, and use your saved values to help influence and correct your position during your next movement. As far as accuracy goes, it was very consistent. After 10x (Forward 1 meter, right 90 degrees, left 90 degrees, back 1 meter), it was off by 5 degrees - but even that was consistent across multiple runs of the routine.
The distance proportion had a hard limit of 120, and the wheel difference P wasn’t capped. Otherwise distance proportion has a tenancy to completely overpower the diff P is all.
This made my day. I’m expecting big things from your team next year. Big things.
Are you just allowing the robot to come to a stop on its own (no “breaking”/reversing the motors) then?
In other words, do you just go from the minimum value needed to make it move to 0 when the error is 0 are do you go to the minimum value in the opposite direction or something else?
Ah, that’s something I forgot to touch on in the tutorial - but I did mean to. When the absolute error between the two encoders is <= 15, it sets the motors to go in the opposite direction by 1 power, which is just to give it some resistance so it doesn’t continue.
Well this is a brilliant idea. I never had much experience with this method, so sounds very appealing to me. I wonder if you would like to explain that a little further, or some sample codes would get me really pumped up. But you really don’t have to.
Thanks for the compliment. I am still uncertain whether I will actually be building NBN robots and competing in VEXU-- currently there’s no VEXU team I can play in, and although I plan to start one, there’s too much uncertainty. But no matter what happens, I will keep designing robots and more advanced control methods to enhance our overall skill set.
After you set the motor to 1 in the opposite direction, how did you decide when to continue to the next move of the robot? Also, did you have any problems with wheel slippage when relying on the encoders?
For the wheel slippage, I would assume according to my experience that it is not a problem. The shape of Omni wheels allow them to have insanely good grip on foam tile if the rollers are kept clean.
Also, I would like to hear some further explaination on the brake feature with 1 power.
Nice stuff Kairus, great work at worlds. I really like the page you linked. Our kids had the same issues with deadband and minimum motor move. However, one comment above, that you would need to use D if you use I is a bit mis-leading. There are a lot of control loops that use just PI, P, by definition, cannot get you to a 0 error, so a low value I can close that tolerance for battery voltage, friction, etc… Our kids will most likely use that if we have a spinning wheel launcher. D is normally the last thing that we will add, it tends to be noisy based upon the resolution of the sensor and the update rate. I use it sparingly in controls in the consumer/medical world.
The deadband is the biggest challenge in these motors and their controls, in my opinion. One other thing that helps in moving to position is to use a sigmoid multiplier to give good smooth takeoff and landing from point to point and deceleration.
Correct, wheel slip isn’t a big issue, if you accelerate up to your max speed over ~.4 of a second, and slow down to minimum driving speed as you reach your target, your wheels never leave the ground. With 269 vex motors, at 0 power, they don’t provide much resistance at all because the motor’s brushes don’t shift, and it allows the robot to continue rolling. Using a power of -1 provides a lot more resistance, as it shifts the brushes into the opposite direction. -1 is also never going to be enough to move your robot, so it’s similar to turning off motors, but with more resistance.
I mean, I wouldn’t use PI on a drive. I’m not a fan of PI for the same reason I don’t use PID on vex robots drives. The issue is that PID doesn’t converge fast enough on quick robots/movements no matter how fast you make it, and when this happens, you are at an inconsistent angle when you reach your destination. PI converges slower, thus is more likely to still be converging when you reach the destination. In my mind, in all situations where PI is appropriate, such as controlling the speed of a ball launcher, to me, PID is more valid. By all means though, feel free to try it
Also, I agree, acceleration is very important.
Some I can be quick, just depends upon the situation. A couple of suggestions in using I is in handling integrator windup. A couple things that help are:
Don’t just compare to a MAX/MIN value to clamp the integrator.
If just the P portion of the PI exceeds 100% output power (+/-), then reset the integrator accumulator.
If P and I are contributing to the output power and the sum is > 100% output, then reduce the I accumulator by the value required to be capped at 100%. This gives P priority for better response as the error changes.
Run P as fast as you can (simulating analog), run I or D at consistent timed intervals that allow enough information from the sensor being used to be useful. Too fast on D is a noise generator since you can’t see much change.
I liked how some code I’ve seen on the forum measures the time lapse for I and D. Lots of people forget that this directly affects the gain.
Some good points here, perhaps next time I find having D in there isn’t quite cutting it, I’ll give PI a shot