Has anyone tried using accelerometer output/gyro rate output for PID control? We’ve only ever used angle output from our IMU in the past.
I was wondering how well using PID controllers with feed forward terms would be for acting as “brakes” with mecanum wheels. For example, if our driver suddenly stopped pushing forwards on the joystick and translated right, could I use a PID which reads acceleration with a setpoint of 0 to prevent the robot from rolling forwards or backwards as the driver translates?
Additionally, how well would using gyro degrees/sec with a feed forwards capable PID controller perform for angle holding?
Up to roundoff error, a P loop running on the rate would be equivalent to adding D gain to your loop running on the position.
I’m not sure there’s any particular reason to do this, though - the only thing it gains you (apart from avoiding potential roundoff error problems) is the ability to use a second derivative term in your loop (at the cost of being able to use an integral term, which instead becomes what was the P term in the ordinary loop), but I’ve yet to hear of a situation in FRC where this is necessary. Of course, just because I’ve never heard of it does not mean it doesn’t exist.
Were you intending to run your PID loop directly off of the accelerometer output, or off the IMU (that is merged/synthesized) output? I read OP as the second, but think Oblarg read it as the first.
Assuming you mean the IMU output: If you are intending to use the output speeds and rotation rates from the IMU as your process variables, this should work well, as long as you are not looking for good precision driving to an absolute position (e.g. for an inertial autonomous routine); if you want to drive to an absolute position, use the integrated position outputs from the IMU, at least for the final stage of approach.
In any case, if you are running mecanum in PID mode where you are using wheel velocities as your process variable, it will automatically “brake” forward motion when you set a target velocity which is sideways or in reverse.
One minor adjustment - you are looking for 0 velocity, not 0 acceleration. To use the accelerometer to get 0 velocity would require integrating it to calculate your actual velocity, then controlling around that. In general, I’ve had very poor luck integrating accelerometers - unless you have a very expensive one, the noise builds up over time and makes your velocity/position reading very wrong. As mentioned, controlling based on wheel rotation might be the better approach here? Even still, the system may not be intuitive for the driver to control… This might make a good summer project to fiddle around with, and see what works best
We do this every year (abet without the feedforward) - Gyro integration tends to work better than accelerometer integration (with a $70 gyro, we get only ~2 degrees of drift over a match). Note that if you’re servoing to a specific angle with your robot, you won’t want to use feed-forward (feed forward will take the command signal and directly feed it into the output - a desired angle of 180 doesn’t mean you should always be running your motors).
What we’ve had success with is a decently high P gain, and a fairly high I gain, but we turn off the integrators unless we’re within a few degrees of the setpoint. P gets us the first 90% of the way, then I really kicks in over the last 10% to overcome stiction. In this case, D (as a damping term on P) doesn’t help much.
Edit:
Also, check out what Team Titanium did for their mechanum drive control this year - they had an extra set of idler omni wheels (attached only to encoders, just resting on the ground) which measured actual distance traveled in both x/y directions - I don’t think they used them during teleop, but they were crucial for getting the autonomous routine distances correct, even when wheels were slipping against the ground.
I was talking more about the “gyro rate” half of his question. The same logic applies for the accelerometers, however.
When running a loop on the IMU’s angle reading, the I term behaves like an I term in an ordinary position control loop.
When running a loop in the IMU’s angular rate reading (presumably this is just the scaled output from the gyro), the I term behaves like the P term of an ordinary position control loop, and you’d need a double integral term to do what you were doing with the I term in an ordinary position control loop.
Differentiating/integrating your process variable, in a PID controller, is very nearly the same (again, there may be roundoff errors) as differentiating/integrating all of the errors used for the various gains. So, if I differentiate all of my terms, I becomes P (a la Fundamental Theorem of Calculus, derivative of the integral is the function itself), P becomes D (derivative of the function is, well, the derivative), and D becomes a second derivative.
I think we’re going to pick up a navX micro… does this have the “merged/synthesized” output? Ideally, which should we use?
Would using accelerometer output work for braking (setpoint of 0, feed forwards component)? Or do we have to invest in some encoders to measure wheel rotational velocities?
Definitely do the latter. Accelerometer drift (if you integrate it) is substantial. Encoders are reasonably cheap and once you start using them you’ll never stop.
Note that running velo PID on the wheels is easy to set up using Talon SRX motor controllers, but has its own set of design concerns. You should spend at least one offseason playing with it before fielding it on a robot.
That’s the goal… to iron out teleop over the summer for our driver
Would this mean we need encoders on our wheels? Is there a way I could do this with solely a navX micro and CANTalons?
I really like this idea… might give it a shot. I think it would make PID control a lot easier. However, I feel like there might be issues if you make any mistakes measuring the radius of your idler omnis from the center of the robot.
I’m putting together a parts list of things to order to figure out over the summer. So far I have a navX micro, Talon SRXs, and encoders on it. Anything else I’m missing?
Conceptually, how do the Talon SRX ESCs interact with the encoders? Could I theoretically have velocity PIDs handled almost completely off of the rRIO?
You will still have to handle turn-to-angle loops and the like on the RIO. But if you are running velocity control on your drive, those loops become “cascading” loops (as their outputs are fed as setpoints to the velocity controllers), and become much easier to tune and much less sensitive to the RIO’s slower loop execution speed.
Mainly for wiring purposes, but because we have a Rev More Board we would prefer to not stack MXP boards.
Wow, this is awesome. Wish I knew about this implementation earlier. Google search will probably yield the same answer, but are there any encoders you recommend for the SRX in particular?
It’s definitely theoretically possible - what you’re looking to measure is the robot’s COM velocity. You just send commands to the motors (via PID) to adjust that COM velocity as you desire.
Both drivetrain encoders and a navX can tell you COM velocity, but neither of them do it directly. They get the info by making different assumptions - Encoders have to presume your wheels don’t slip against the ground, and accelerometers have to presume the integrated noise in your output is negligible.
I have generally found that wheel encoders make the more reasonable assumption, but that is application-dependent.
If you do want to do some experiments and have the budget, I’d recommend getting the encoders anyways - especially if your gearboxes already have a mounting point, it should be pretty easy to have the extra info available in case you want to control around it.
For a drive, any quadrature encoder with at least 256 CPR (that’s cycles, not pulses) should work fine. Grayhill 63Rs are very popular, as are various US Digital encoders (we’re sort of atypical and use some big honking US Digital encoders, as they have locking connectors and are very hard to break, at the cost of space - I can dig up the model for you, if you’d like).
You’ll need a breakout board to connect the Talons to a quad encoder, as the ribbon cable is designed for the SRX mag encoder (which also will work fine, but is a bit harder to mount on a drive than a standard quad encoder). You can buy said boards on AndyMark.
If you need help with the SRX library, let me know - we have a fair bit of experience with it, now.
256 CPR is high enough that the encoder resolution will probably not be a significant limiting factor for any reasonable FRC wheel size (8’’ and below), in my experience.
