navX MXP without PID control

[sagrossm]

Is it possible to use gyro with navX to rotate to a certain angle without using PID control?

[Ether]

Originally Posted by sagrossm

Is it possible to use gyro with navX to rotate to a certain angle without using PID control?

Sure. You can use any form of closed-loop control that you like. It doesn't have to be PID.

[samfruth]

Yes. And IMO PID isn't actually the best option when rotating to an angle. PID is good for maintaining something like flow rate or temperature over time. What we have done in the past is take the error (or difference between current yaw and desired yaw) and feed that number through as our motor power after it has been either divided or multiplied by some number to make it be in range of 1 to -1 as the motors only operate on those values. Its definitely rudimentary but it gets the job done with some tweaking.

[sagrossm]

Ok, we've been trying to implement it and it's just been really inconsistent (usually turning too far). Looked online for help and I can only find examples with PID, that's why I made that assumption. So is there anything I can do to make it more accurate and reduce error? This is a button that we have:

if((driveStick.getRawButton(12) == true)) {

if(gyro.getYaw() > -140){
leftFront.set(0.3);
leftRear.set(0.3);
rightFront(-0.3);
rightRear.set(-0.3);
}

else if(gyro.getYaw() <= -140){
leftFront.set(0.0);
leftRear.set(0.0);
rightFront(0.0);
rightRear.set(0.0);
}
}

[sagrossm]

samfruth, what you said makes sense I'll try something like that.

[Jefferson]

Originally Posted by samfruth

Yes. And IMO PID isn't actually the best option when rotating to an angle. PID is good for maintaining something like flow rate or temperature over time. What we have done in the past is take the error (or difference between current yaw and desired yaw) and feed that number through as our motor power after it has been either divided or multiplied by some number to make it be in range of 1 to -1 as the motors only operate on those values. Its definitely rudimentary but it gets the job done with some tweaking.

Can you explain how what you're doing is different than just proportional control, i.e. I, D, and F gains are zero.

[Jefferson]

Originally Posted by sagrossm

Ok, we've been trying to implement it and it's just been really inconsistent (usually turning too far). Looked online for help and I can only find examples with PID, that's why I made that assumption. So is there anything I can do to make it more accurate and reduce error? This is a button that we have:

if((driveStick.getRawButton(12) == true)) {

if(gyro.getYaw() > -140){
leftFront.set(0.3);
leftRear.set(0.3);
rightFront(-0.3);
rightRear.set(-0.3);
}

else if(gyro.getYaw() <= -140){
leftFront.set(0.0);
leftRear.set(0.0);
rightFront(0.0);
rightRear.set(0.0);
}
}

I've not had good luck with very basic control methods like you've described, usually because of overshoot. I've found the D parameter to be necessary to slow the rotation as your robot picks up rotational speed during the turn.
Is there a reason you don't want to use PID? The WPILib PIDController is very capable and pretty easy to use.

[samfruth]

Originally Posted by Jefferson

Can you explain how what you're doing is different than just proportional control, i.e. I, D, and F gains are zero.

That is exactly what it is.

[dougwilliams]

Originally Posted by sagrossm

Ok, we've been trying to implement it and it's just been really inconsistent (usually turning too far). Looked online for help and I can only find examples with PID, that's why I made that assumption. So is there anything I can do to make it more accurate and reduce error? This is a button that we have:

if((driveStick.getRawButton(12) == true)) {

if(gyro.getYaw() > -140){
leftFront.set(0.3);
leftRear.set(0.3);
rightFront(-0.3);
rightRear.set(-0.3);
}

else if(gyro.getYaw() <= -140){
leftFront.set(0.0);
leftRear.set(0.0);
rightFront(0.0);
rightRear.set(0.0);
}
}

We take an easy piecewise linear approach when rotating to angle using the NavX yaw as the input. We had a lot of overshoot with pure proportional, so we set angle limits similar to what you are doing and set a speed. If it needs to rotate more than 90 degrees it can be set to rotate at full speed. When it has 45 degrees left to rotate it needs to be scaled down to .4 speed. Once you are within 20 degrees the rotational speed needs to be scaled down to only .2. There is a lot of robot inertia in the spin - and that needs to be accounted for. (All those numbers are made up, but the idea is roughly what we implement).

This way was an easier first step rather than explaining a full PID loop and how to implement that in software. Most students are able to read the code and understand what it's doing.



Also - looking at your code - do the angles work in that scenario? What angle are you trying to rotate to? Maybe to zero - but then when you are less than -140 degrees it stops. That seems backwards to me.

And I think in the NavX 180 and -180 are the same position, and you need t account for that in your math.

[Ether]

Originally Posted by dougwilliams

We take an easy piecewise linear approach ... If it needs to rotate more than 90 degrees it can be set to rotate at full speed. When it has 45 degrees left to rotate it needs to be scaled down to .4 speed. Once you are within 20 degrees the rotational speed needs to be scaled down to only .2

Yes an approach like that can be quite effective in many situations.

Also - looking at your code - do the angles work in that scenario? What angle are you trying to rotate to? Maybe to zero - but then when you are less than -140 degrees it stops. That seems backwards to me.

And I think in the NavX 180 and -180 are the same position, and you need t account for that in your math.

The gyro_reading and your desired_angle need to share the same zero position, and rotation direction. Given that, it's simple to compute the shortest angle to your destination:

angle_error = desired_angle - gyro_reading;
shortest_angle = angle_error - 360*floor(0.5+angle_error/360);

If your compiler supports the REMAINDER function "x REM y" per IEC 60559 as specified on Page 235 Section 7.12.10.2 of ISO/IEC 9899:TC3 (which java does I believe), then the following single line of code should work:

shortest_angle = Math.IEEEremainder(desired_angle-gyro_reading,360.0);

The above works regardless of the range of either the desired_angle or the gyro_reading (as long as they share the same zero and rotation direction, as mentioned above).

So for example if your desired_angle is -3 degrees and the gyro is reading 359 degrees, the shortest angle will be -2 degrees.