Quote:
Originally Posted by Jared Russell
Do you mean angular displacement? (Gyros measure angular rate, which then must be integrated to obtain angular displacement). With commonly available FRC gyros based on an Invensense MPU-9250 (NavX, CTRE Pigeon) or Analog Devices ADXRS-450/451 (FIRST Choice gyro, WCP Spartan board) you can measure angular displacement *very* accurately...you will only drift a handful of degrees over an entire match under most conditions (e.g. level field). You can generate a turn-in-place motion profile just as you would using encoders.
A gyro can't help you measure translational motion, of course. If you use a multi-DOF IMU with gyros AND accelerometers, you can measure linear acceleration...but trying to obtain precise translational displacement from these is not going to work well (maybe this is what you were referring to). But you can combine a gyro with encoders to give you the "best of both worlds" and follow a profiled path while correcting for yaw errors. As long as the profile contains yaw information, you can use a PID controller (often a P controller is enough) to add a bit of velocity to one side and subtract it from the other to keep you on track.
|
I think there was a misunderstanding here. I was talking about using a gyro/accelerometer (the navX in particular) to measure translational displacement, which we both agree is too inaccurate for motion profiling. However, I do have one concern with the alternative you suggest, using the PID loop together with your profile follower. Isn't there a concern that the PID loop could correct in such a way that you end up over/undershooting your goal for the profile?
Our system is to run an independent profile on each side of the robot, where each wheel follows the profile and corrects itself based on the error from the end point. This way, at the end of the loop, the setpoint for each side is the endpoint of the profile, so it ends up correcting itself to the right place.
I guess what I'm saying is that when you use the gyro to go straight (based on yaw) you're adding a new variable (yaw) instead of interpreting yaw as a difference of distances. How do you ensure that that doesn't become a problem?
Hope this makes some sense.