Random Gain

[rishabshah0]

In Mecanum.java there is a hardcoded doubling of the pathing vectors after all normalization and clamping logic has been performed. This is doubling what the PIDs say to correct for, and it causes a lot of clamping. This should either be in Constants as a gain value (and part of the tuning process) or should be removed.

• It reduces the linear control range of the PID (e.g., a calculated power of 0.6 becomes 1.2 and clips to 1.0 immediately).
• This makes small corrections unnecessarily jerky.

// Mecanum.java
truePathingVectors[0] = truePathingVectors[0].times(2.0);
truePathingVectors[1] = truePathingVectors[1].times(2.0);

[BeepBot99]

I don't know why this is done and I will let havish answer that part, but this will not make small corrections unnecessarily jerky as you say. This is because doubling the output of a pid can be compensated by halving the gains, so if you tune with the output doubled your gains will naturally be halved firm what they would be otherwise.

[rishabshah0]

Yes, it can be doubled, but the PIDF still cannot recommend any power above 0.5, and below 1, which the robot will follow. If it tries to ask for say, 0.51, 0.75, or 0.9, they will all be set to 1.0. We tried using our PIDF heading values for a custom robot task and were confused why the robot didn't move until we realized all the PIDF values were half.

[junkjunk123]

The true pathing powers are supposed to represent the powers for each side of the drivetrain (left and right). Since there are two motors, we multiply these values by 2 before performing our calculations.

[rishabshah0]

As the code stands, any value greater than half of maxPowerScaling is treated as maxPowerScaling. These powers are used for motor powers, not for side powers, so losing half the control range isn't ideal.

As an example, if we assume maxPowerScaling is 1, because of the doubling, any PID command in the range [0.5, 1.0] results in a raw value greater than 1. The normalization code immediately clamps it down to 1:

// Mecanum.java
        if (wheelPowerMax > maxPowerScaling) {
            wheelPowers[0] = (wheelPowers[0] / wheelPowerMax) * maxPowerScaling;
            ...

Whether the PID asks for 60% effort or 100% effort, the motors receive the exact same command.

I'd say the best way to fix this while maintaining compatibility is to set 2 as a gain in Constants (which can be changed to 1 in the next major release), and add a note in the docs, notes, and Discord that teams can set the gain to 1 and double all their PID values for more linear control.

[BeepBot99]

FYI this is still being discussed internally.