acmerobotics / road-runner

Wheeled mobile robot motion planning library designed for FTC
MIT License
224 stars 77 forks source link

Tunnig issues #14

Closed thedeath154 closed 5 years ago

thedeath154 commented 5 years ago

I and my friends were trying the feedforwardtune +the straight test and we notices something wrong , while adjusting the kv, kstatic and ka , the robot would not do the straight test , instead of going for the 60 in track , it only moves 0.1 in back and forward , but when we accidentally put the kstatic value on ka and the ka value on k static , it actually moves about 40 in but it has some x,y and heading errors ,they may be reverse in code ,somehow! Also we have a lot of problems with track wide values and drive constants and wheel localization ex: track_width 11,09 kv0.02846 , ka0.00188,kstatic 0.04183 ;

If it is possible to help us understanding the process of tuning and what values we need to use (like in track_width 51.12(SE 12.1)) we use the 51 value or the 12 value ? Can we talk in private to see what we are doing wrong and what to do to be right ? Here is my discord TheDeath154#2565 and here is the ftc team discord CNDRobotics#1965.

bweis commented 5 years ago

Sounds like your motors are reversed from what is expected? Maybe? It is hard to debug without more details.

thedeath154 commented 5 years ago

It dose not seam like it , we even reverse on purpose the left motors (leftRear and leftFront);

thedeath154 commented 5 years ago

so it goes forward when we use the drive

thedeath154 commented 5 years ago

i can leave the entire code as it is if you want

bweis commented 5 years ago

Sure. If you share your repo I can take a look or give you a CR.

thedeath154 commented 5 years ago

https://wetransfer.com/downloads/dc464fe6ae23fe0043c71a7b45e35bef20190809202547/24b519

bweis commented 5 years ago

Will take a look tomorrow when I am not on my work laptop. 👍

David10238 commented 5 years ago

kA transfers acceleration to motor power kStatic overcomes the static force applied on the motor kV transfers velocity to motor power trackWidth defines the relationship between robot rotation and wheel deltas, the larger the track width, the more the wheel will rotate when turning. I would hand tune this to turn close to your target and use either odometry or a gyro for feedback. In theory track width is distance between the two sides of the drive train, but friction from turning scrub can change what it actually is. if you are using RUN_USING_ENCODERS (velocity PID) set kStatic and kA to 0.0, using them will mess stuff up. set kV to 1.0 / (listedMaxMotorRPM / 60.0 wheelRadius TAU) of course you will have to adjust for gear ratio if you do external gearing, and the velo pid should be enough to get it very close to your target with some minor variations, using PID feedback to close the loop around distance will be the only way to get it perfect. also before tuning double check your localization to make sure it's near 100% accurate (the ticks per rotation in the sdk are slightly off, as it's for 20:1 not 19.2:1). Feedback will be the last thing you tune. If you use RUN_WITHOUT_ENCODER tuning will be harder and require tuning feedforward constants instead of just calculating them. also make sure maxVelocity and maxAcceleration are set to reasonable values. 20 might be a good spot for initial testing to make it slow, after open loop is working, raise them up to be closer to what your bot can physically do but leave a little leeway for feedback. I cannot express how important it is to keep things consistent if one unit is off on a value that will mess something up somewhere. also when testing motor directions keep in mind the joystick returns a negated value for some weird reason

rbrott commented 5 years ago

I and my friends were trying the feedforwardtune +the straight test and we notices something wrong , while adjusting the kv, kstatic and ka , the robot would not do the straight test , instead of going for the 60 in track , it only moves 0.1 in back and forward , but when we accidentally put the kstatic value on ka and the ka value on k static , it actually moves about 40 in but it has some x,y and heading errors ,they may be reverse in code ,somehow!

Looking at your code, I spotted a potential issue with the kV value:

public static double kV = 0.02947 / rpmToVelocity(getMaxRpm());

If you tune kV, you should replace the entire expression with the value:

public static double kV = 0.02947;

Also we have a lot of problems with track wide values and drive constants and wheel localization ex: track_width 11,09 kv0.02846 , ka0.00188,kstatic 0.04183 ;

Those values all seem to be roughly correct; there's nothing obviously wrong with them.

If it is possible to help us understanding the process of tuning and what values we need to use (like in track_width 51.12(SE 12.1)) we use the 51 value or the 12 value ?

You want to use the first value (i.e., 51.12). The value in the parentheses is an estimate of the standard error. This number is useful for determining the validity of the measurement (lower values are better). That being said, both of the values seem oddly large -- I suspect there's something wrong (the earlier track width measurement of 11.09 seems much better).

Going forward, I would recommend you use RUN_USING_ENCODER if you have encoders on your motors as @David10238 mentioned. It eliminates a step from the tuning process and will likely give you better performance down the line.

From your code, I assume you have a mecanum drivetrain with REV hardware. If this is the case, you should definitely uncomment the following line in SampleMecanumDriveREV:

//      motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);

Your drivetrain will not function properly if the motors are floating and there is no velocity control. I caution beginning users against modifying parts of the drive class that aren't clearly delineated with // TODO comments.

I assume you've found the docs already, but here is the quickstart tuning guide nonetheless.

Good luck with the tuning process.