V5 Motors: Is PID programming still necessary?

I’m part of a second year VEX team that competed with a Cortex system last season. We’re getting a V5 system this summer, but unfortunately, since we’re a school team, we can’t play around with it until fall.

I know what PID is, and last season we used it in our autonomous using our encoder values to move a certain distance (which was only somewhat successful because we couldn’t figure out how to fix our drifting problem).

For teams that currently have v5 systems, did you find it necessary to program your own PID-controlled autonomous and drift correction, or does v5 make this a non-issue now? I want to start programming some fundamental parts in the summer and want to know whether it’s worth spending time writing code for this.

2 Likes

Yes it’s necessary. My team has v5 but last season our autonomous didn’t go well because the foam tiles at competitions have different surface friction. We plan to use PID and position tracking this year.

2 Likes

We don’t know what was happening with our motors since it only happened to our team (at our school), but our auton was terribly inconsistent for most of the season. After missing our worlds invite, we re-wrote our auton with pid and it worked every time. The other teams from my school didn’t have this problem though, so you might be able to get away without using it. If you have the time to tune it however, there’s no reason not to use it.

PID is necessary regardless of the kind of motor you use. Friction, mass variances, etc all contribute to inconsistency. If you know anything about physics, being able to control the speed of the robot relative to the target position is extremely helpful because of the way momentum and friction work on a mass. It may be easy to believe that what you tell the robot to do (move the motors x amount of distance) will translate perfectly in practice, however this is not the case.

Consistency is a consequence of extensive precautionary measures. You may find that your autonomous may work once or twice by just feeding encoder values to the brain, however, when battery voltages vary and real world variables come into play, you will soon find that you need to aid your robot’s autonomous execution with motion control algorithms.

The short answer: yes.

3 Likes

TL;DR: For drivetrains? Nope. For other stuff? Probably not.

To preface this, in case you didn’t know: V5 motors include their own encoders and their own motor controllers, and can run their own PID loops internally.

Most of the autonomous inconsistency people are describing is due to wheels slipping on the foam field tiles when the robot abruptly starts or stops. Invictus, the world skills champions last year, used 2D motion profiling in order to limit the acceleration of their robot. Because of this, they were able to achieve very accurate autonomous routines without writing their own PID loop. I would highly recommend using PROS and OkapiLib to accomplish this. Check out their YouTube video of their skills run, specifically the comment section, if you want more information.

For drivetrains, you should not code your own PID loop, full stop. If you run your own PID loop on the V5 brain, your loop will have to wait for the 10ms delay to get encoder data and then wait for the 10ms delay to send motor data. This is far slower than the PID built into the V5 motor, and if you try to implement it, you will either end up with a very slow-moving drivetrain or end up with oscillations due to the loop latency depending on how you tune your PID constants.

For other mechanisms (lifts, arms, etc.), it’s a bit more complicated. You can either use the motor’s built-in encoder coupled with a limit switch, or you can use an external potentiometer. Neither option is very good.

Using the motor’s integrated encoder gives you very good PID loop performance, but will make your mechanism’s movements less accurate overall if there is too much chain slack or gear slack between the motor and the mechanism (lift, arm, or whatever it is). Because the rotation sensor is mounted to the motor shaft, not the output shaft, any slack between the two will result in incorrect readings and inaccurate movements.

On the other hand, you could mount a potentiometer to the output shaft and run your own PID loop. If you do this, you end up with the same oscillation and slowness issues as before, but at least your movements will be accurate.

I’d prefer the first option if the mechanism uses gears, but if the mechanism uses chain, I’d go with the second option. Or try and redesign the mechanism to not use chain.

Edit: On the topic of drift correction, Invictus again had a great idea. They periodically read the motor encoder values from each side of their drivetrain, calculated their absolute angle since the start of their routine, and turned to compensate for it. This fixed the rotational drift issues. For position drift, they periodically lined themselves up using other field objects, such as the poles in Turning Point.

6 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.