Standard Positional PID Loop for Drive Base Movement?

#1

I’d like to preface this post by saying I understand that closed loop velocity control, along with some form of motion profiling and path planning, is the ideal method of autonomous movement. But would it be feasible to/has anyone ever ran a simple positional PID loop on the drive motors of their robot for autonomous movement?

There would be a lot more to it than just 1 PID loop, you would probably have to have at least 2 (if you’re running a tank drive), along with another to handle your field relative angle. I’d imagine that you’d run into problems related to wheel slippage and inconsistency, but I think if you tuned the PID loop properly, it would be a viable option for autonomous movement.

The reason I ask is that I’ve heard people are having many problems tuning velocity PID loops with the Spark Maxes and the Neos due to the low resolution of their internal encoders. We have also experienced such issues.

“Why not just switch to CIMs and Talons?”
Our team uses Neos for the drive motors on our swerve drive, and due to their low weight and amazing output torque, we don’t consider switching back to CIMs an option. So we’re searching for a more robust method with which to localize during autonomous using the Neos.

Thoughts, comments, and counterarguments are all appreciated.

Edit: And before someone suggests using Jaci’s Pathfinder, I have tried implementing that in LabView (the language we use), and although it may be possible to use Pathfinder in LabView, I would rather spend hours ripping my hair out over another method.

1 Like
#2

Yep, and very effectively, with the method you suggest. If the issue for you is mainly one of the encoders, then you could easily add them to one of your wheel output shafts.

The theory is pretty simple. Where you get into the headaches is dealing with tuning the drive and turn PID’s - a PID-only turn closed on a gyro poses all sorts of challenges, most of which come down to stiction/friction and not ending turns exactly where you would like. The forward/reverse drive pid’s are much easier.

I would much rather do the PID’s you are talking about with velocity control utilizing an external sensor to mitigate the stiction/friction issue.

The other issue is that driving curves are totally dependent on guesswork. Educated guesswork, but still you’re crossing your fingers that the robot will turn just like it did when you were tuning everything.

All that said, yes they are perfectly workable and can get you to where 85% of the other teams in FRC are.

#3

That’s the main problem with the Neos, you are only able to drive them using the Spark Maxes. And per the limitations of the Spark Max software, you are only able to use the internal encoder of the Neo when performing any kind of intelligent control of the motor. They do have a feature that will allow you to use external encoders in that fashion under development. But last I checked their Trello card, it’s at the bottom of a long list of other features also being developed.

Edit:

That makes sense, but I think/hope that won’t be as big of an issue with swerve drive, because when using field oriented drive, the field relative angle of your chassis is basically irrelevant as it pertains to the movement of the robot.

#4

You don’t need to close the loop inside the motor controller. So you can run the PID’s in your code and send the command values to the motor controllers.

By the way - you shouldn’t be afraid of Pi. We don’t bite…

#5

A position and velocity feedback controller (PD controller) with a step change in setpoint is harder to tune than one with a motion profile and nominal feedforward due to the robot not being able to follow the setpoint dynamics (step changes are impossible to track exactly). This is especially true for mechanisms with high inertia like drivetrains. You’ll have even less success than the recommended way, in my opinion.

For what it’s worth, WPILib has PRs for motion profiling stuff for 2020 (TrapezoidProfile, ProfiledPIDController, and quintic hermite splines), but that doesn’t help those using LabVIEW…

#6

In the past, we’ve done relatively successful drive straight + turn-in-place autos with encoders and gyro alone. I’d think that you could be relatively successful, in part because your swerve drive won’t have many of the effects that makes even basic drive straight autos difficult with tank drive.

At least with tank drive, we would give 90% power to a single PID loop using the average encoder error and 10% power to another PID loop on IMU yaw error. This prevents the distance controller from saturating your motors. In other words, we did,

output = (0.9 * distance_PID()) + (0.1 * yaw_PID())

For the record, we’ve also done this on an elevator that was lifted by two, separate chain runs. While it’s definitely not as good as motion profiling with independent PID loops for each side, it helped prevent many of the carriage jamming issues we had experienced.

#7

I guess an appropriate follow up question would be, has anyone successfully implemented a velocity control loop for autonomous movement using the Spark Maxes and Neos? If so, what gear ratio and PID constants did you use?

#8

The PID constants are robot-specific. Yes, people have used it successfully. It’s just harder to implement (but easier to tune if your outer loops are designed well).

#9

I realize that I won’t be able to use someone elses PID values. My intent wasn’t to find a set of PID values that will just “work” for me, as I’ll have to tune any given machine myself. I’m simply interested in learning what values have worked for other people. I’m also interested in looking at the ratios of the P, I, and D values to see if there are any general ranges of values that are common among different robots.

1 Like
#10

We have used a PID loop to control the drive every year except for 2017.This year we used NEOs but had the CTRE mag encoders wired to the RIO and used those for the feedback.

#11

As an anecdote, we used a system quite similar to what you are describing in 2018, and we were able to do a 4 cube auto.