TrackwidthTuner for 2 wheel tank drive (RR 0.5.6)

[wangxdflight]

We are using 2 wheel tank drive this year. Kv values were tuned smoothly, and the curve plot on dashboard matched well. And then ran MaxAngularVeloTuner, MaxVelocityTuner. public static double MAX_VEL = 42; public static double MAX_ACCEL = 42; public static double MAX_ANG_VEL = 2.24; public static double MAX_ANG_ACCEL = 2.24;

But we cannot consistently get good track width by running TrackWidthTuner. The measured width using a meausre is 14.5 inches. TrackWidthTuner kept on giving us higher values, and the most concerning thing was that it kept on changing after we update the value according to its output. It reached 23.10 inches even. Even with such a weird value, the 180 degree turn was still not consistent. And when we ran turnTest which turns 90 degree, it was off a lot.

What might be wrong? We did write a manual push and reading encoder ticks opmode code to figure out the wheel radius (1.877 inches). And we use 2 REV HD Hex 20:1 Planetary motoros, and set ticks per REV as 537.6 and max RPM as 312.5.

[wangxdflight]

is it possible these values need to be reduced? as we don't have odometry tracking wheels. public static double MAX_VEL = 42; public static double MAX_ACCEL = 42; public static double MAX_ANG_VEL = 2.24; public static double MAX_ANG_ACCEL = 2.24;

[rbrott]

TrackWidthTuner is known to be pretty terrible. You're probably best off starting with the initial value of 14.5 and manually adjust it until turns look good (see https://learnroadrunner.com/trackwidth-tuning.html).

[wangxdflight]

Thanks for your reply. We have been using that page (great resource). I tried to start from 14.5 inches, but adjusted it manually, but it still didn't give me consistent turn of 180 degree. How close should it be? 1-2 dgree without heading PID, correct? And how far away it can be different from the measured width? 1-2 inches at most, correct?

Do you think our issue might be due to slippage?

[rbrott]

How close should it be? 1-2 dgree without heading PID, correct?

Hopefully it's within a couple degrees. Make sure you aren't "overfitting" on a single turn angle. Varying the angle is important to get a good final result even if it's frustrating to manually adjust.

And how far away it can be different from the measured width? 1-2 inches at most, correct?

The value can be pretty far from the measured width. In general I wouldn't pay much attention to this (though I would expect it to be closer to the measured width for tank drives over mecanum drives).

Do you think our issue might be due to slippage?

Maybe. You can try lowering the acceleration, though I wouldn't lower it too much.

[wangxdflight]

Thanks for the info.

I saw one line below. Why it is needed? What to set if we don't have odometry and have to rely on the driving wheels for localization? // TODO: if you haven't already, set the localizer to something that doesn't depend on // drive encoders for computing the heading

https://github.com/acmerobotics/road-runner-quickstart/blob/f3a1c3a97034030869be673fe6553e835da37117/TeamCode/src/main/java/org/firstinspires/ftc/teamcode/drive/opmode/TrackWidthTuner.java#L38

[rbrott]

You're using drive encoders + IMU to estimate pose (most likely), which means that the IMU alone is used to compute heading. In that case, you can ignore the warning.

[wangxdflight]

Thanks!

I did more tests. Reducing MAX_ANG_VEL and MAX_ANG_ACCEL didn't help. It was interesting to see that the robot didn't turn at all when those values were too small. It seems the setPower value became too small (below 0.15) when those constants were too small. I increased them, it got me better results. MAX_ANG_VEL = 2.28 is the recommended value from MaxAngularVeloTuner. I blindly set MAX_ANG_VEL to be almost to 2x. Not sure if there is explanation behind it.

public static double MAX_VEL = 50;    // based from maxRPM * 0.5
public static double MAX_ACCEL = 45;   //
public static double MAX_ANG_VEL = 2.28; // Math.toRadians(133);    // 2.344 = 133 degree
public static double MAX_ANG_ACCEL = 4.58;

[wangxdflight]

You're using drive encoders + IMU to estimate pose (most likely), which means that the IMU alone is used to compute heading. In that case, you can ignore the warning.

Yes, we specifically added this line in SampleTankDrive: setLocalizer(new TankLocalizer(this, true));

[rbrott]

I did more tests. Reducing MAX_ANG_VEL and MAX_ANG_ACCEL didn't help. It was interesting to see that the robot didn't turn at all when those values were too small.

Sounds like the feedforward is off. The static parameter should guarantee the robot moves for any power barely above zero.

MAX_ANG_VEL = 2.28 is the recommended value from MaxAngularVeloTuner. I blindly set MAX_ANG_VEL to be almost to 2x. Not sure if there is explanation behind it.

2x the value given by the tuner? The tuner is supposed to provide the absolute maximum velocity at the steady-state voltage, and you should reduce it by at least 15% to give headroom before the robot starts falling behind.

[wangxdflight]

When you say feedforward, you mean kV, kA, kStatic values? When you say static paramter, you mean kStatic?

I did run ManualFeedforwardTuner. The 2 curves in dashboard matched well though.

I had a typo, what I meant was set MAX_ANG_ACCEL to be 2 * MAX_ANG_VEL, where MAX_ANG_VEL is set as the recommended value from MaxAngularVeloTuner. I think it is already 15% less the max ang vel. Is MAX_ANG_ACCEL supposed to be larger than MAX_ANG_VEL?

[wangxdflight]

I have been disabled encoder. While enabling encoder, tring drive velocity test, the plot doesn't match well. It seems some parameters were still wrong. Any pointers?