Pathfinder Magic numbers in wiki

Technical Programming
1

So, we were able to get our code working for the most part. But there are 2 things we had to do, that I don’t understand why, other than it works.


double l = left.calculate(encoder_position_left);
double r = right.calculate(encoder_position_right);

double gyro_heading = ... your gyro code here ...    // Assuming the gyro is giving a value in degrees
double desired_heading = Pathfinder.r2d(left.getHeading());  // Should also be in degrees

double angleDifference = Pathfinder.boundHalfDegrees(desired_heading - gyro_heading);
double turn = 0.8 * (-1.0/80.0) * angleDifference;

setLeftMotors(l + turn);
setRightMotors(r - turn);

what are the magic numbers or formula in: 0.8 * (-1.0/80.0) * angleDifference;

For the “…your gyro code here…” we used the navx GetYaw(), but that caused problems. Our gentle S curve from center to switch, when using getYaw(), caused the bot to turn almost 90 degrees and head towards the corner. If we used -getYaw() it worked.

I’m afraid the ‘fix’ will work on our current path, and when we try another path it might break.

Brian

2

That magic number originated from The Poofs and happened to work really well on the default drivetrain. As for what the number itself represents, it’s a kP gain on the Gyroscope. Units are %output / degree. The 1/80 reduces it from degrees to 1/4.5th of a circle, and 0.8 is the actual gain.

What it’s saying is “at 80 degrees of error, make this term worth 0.8”

Adding a negative sign or not depends on your gyro / drivetrain setup, it’s perfectly normal. You can also tune that value above to your liking. There’s no ‘catch all’ number that will work for every drive system.

3

Thanks. for the reply. Looking forward for the new release.

My goal this year for our programmers is to work on software engineering concepts. So coding to interfaces instead of classes, so you can isolate code to test. Interfaces to the common classes would be great.

Thanks again to you and 254 for the great framework.

4