Translation PID Causing Drift to the right

[matursam]

Hello, The team I mentor is having a very peculiar issue with tuning their robot and we're starting to run out of things to check.

We have a mecanum drivetrain and a two wheel odometry configuration. Our feedforward tuning works quite well, and our heading PID does as well. Unfortunately, as soon as we enable the translational follower PID, our robot starts steadily drifting to the right while following trajectories. This is happens consistently in both FollowerPIDTuner and in BackAndForth.

We've gone back and tested / verified our localization using LocalizationTest multiple times. As far as we can tell it is close to perfect. The robot's reported position on the field in FTC dashboard barely drifts at all even after driving the robot around randomly (including strafing, driving forward and backward, and turning) for a minute or two. So I'm struggling to accept that there's enough error in the localization of the robot to cause this drift.

Any suggestions on more tests to run or possible causes?

Thanks!

[8toAutomate]

We have the same exact issue as well (see issue 196). The robot can drift quite a bit to the side, even a full ti,e, but the robot's reported position is perfect. When we test the localiser, everything looks correct. The situation improved when we changed from Feed Forward PID to Velocity PID, but it is still there. Adding transnational PID Kp value above 1 messes up an otherwise perfect heading PID.

[rbrott]

Hello.

Unfortunately, as soon as we enable the translational follower PID, our robot starts steadily drifting to the right while following trajectories.

This is a symptom of poor localization.

We've gone back and tested / verified our localization using LocalizationTest multiple times. As far as we can tell it is close to perfect.

Is there any shaking or vibration in the automated movements that might induce different errors than from human driving?

So I'm struggling to accept that there's enough error in the localization of the robot to cause this drift.

I'm not really sure how else to slice it. Feedback is the first step where localization actually comes into play, and control code for mecanum drives has seen extensive use.

[matursam]

The robot does sort of jitter rotationally as it stops during back and forth test. We mitigated this somewhat by lowering the max velocity a lot. I suspect at least some of that rotational instability comes from the dynamics of mecanum wheels under braking, and it's possible we were just trying to go too fast. However even after slowing it down the drift was still there.

Another interesting tidbit, we've tried running our robot with a 2 wheel odometry configuration and a 3 wheel configuration now. We saw this same behavior with both. I'm not sure if that helps narrow down where we've gone wrong with our localization. I'm thinking there must be something wrong with our tuning process since we've apparently done it wrong twice now.

Thanks for taking the time to respond. If you've got any other suggestions for possible culprits I'm all ears, otherwise feel free to close the issue since I agree it's very unlikely to be a problem with the quickstart code.

[LeastOne]

@matursam the team I mentor is experiencing the identical issue you describe. Several iterations of re-tunning have produced the same result again again. Using two wheel or three wheel odometry, using velo pid or feed forward the robot in any of these combinations (with slight variation) while running the BackAndForth opmode the robot will drift approximately one tile. Sometimes left, sometimes right. The best result achieved has been with two wheel odometry with "slightly higher" spring tension on the dead wheels, in this configuration the robot will drift 4-8 inches instead of 24.

Interestingly the perpendicular encoder shows that the robot has moved laterally 60-80% of the actual movement (i.e. the robot has moved 6 inches and the perpendicular encoder reports having moved 3.5 inches) resulting in two other strange and seemingly conflicting observations. 1) The robot is able to execute the strafe test perfectly (as well as the straight test). 2) Despite the perpendicular encoder being aware of at least 3.5 inches of movement roadrunner localization observed via dashboard doesn't show or indicate any lateral movement.

If while running the BackAndForth opmode the robot is shoved laterally dashboard does detect that motion and the robot corrects back on a course within it its broad 4-8 inch lateral range. Equally interesting is that disabling dead wheel localization and resorting to drive encoder localization the robot executes the BackAndForth test flawlessly. Of course it performs poorly on other tests that involve turning or strafing.

The team is using the Rev Through Bore Encoders, having noted the resolution / velocity issues I do have some concerns that the estimated velocities could be inaccurate, but I've done only enough exploration of this to know that the raw values are certainly problematic, easily illustrated by attempting to graph them.

I have no doubt others will have their suspicions and doubts about these outcomes as user error. I certainly won't rule out something easy and obvious as the root culprit, actually I would gladly welcome anyone to tell us our obvious error in order to put an end to this grueling exercise. All I can say is that many long hours and late nights have been sunk into this and all attempts thus far have produced suboptimal results.

I welcome anyone to reach out to me if they'd like to compare notes on similar phenomenon. Its clear this problem is not unique to our team this season:

• https://www.reddit.com/r/FTC/comments/105fdvj/weird_road_runner_y_drift/
• https://www.reddit.com/r/FTC/comments/z2zzbp/help_with_road_runner/

[rbrott]

2) Despite the perpendicular encoder being aware of at least 3.5 inches of movement roadrunner localization observed via dashboard doesn't show or indicate any lateral movement.

Strange. It would be great to see a log if you can reproduce this behavior (you can download them from http://192.168.43.1:8080/logs in recent versions).

The team is using the Rev Through Bore Encoders, having noted the resolution / velocity issues I do have some concerns that the estimated velocities could be inaccurate, but I've done only enough exploration of this to know that the raw values are certainly problematic, easily illustrated by attempting to graph them.

Localization is done with positions alone so it's (fortunately) not affected by velocity overflow.

I have no doubt others will have their suspicions and doubts about these outcomes as user error.

The user is always right 😃

actually I would gladly welcome anyone to tell us our obvious error in order to put an end to this grueling exercise. All I can say is that many long hours and late nights have been sunk into this and all attempts thus far have produced suboptimal results.

Sorry to hear that.

[beersteiner]

We are experience precisely the same problem. Just thought I'd add a comment for solidarity and in case anyone comes up with a root cause or workaround.

[GongInvaders]

Hey, we are also having this exact same problem. Tuning through every step up to FollowerPID works flawlessly, but when messing with PID it just keeps drifting around to the right. This would normally be ok but the drift is random between runs and seems to be heavily dependent on battery level. When increasing the kD values for heading and translation PID, it seems to lose tracking of its heading steadily, which is significantly harder to adapt to.

[GongInvaders]

Just following up, we ran our robot in December for our National comp and it worked nearly flawlessly with RR, basically no drift. Since then we have made some changes to the robot but none to odometry. Also wanted to add that the battery inconsistency is significantly more apparent as well. Our main consistency comes from around 13.4-12.8V but any higher or lower would often over or undershoot respectively. The main problem is that this drift is not the same between runs, so we cannot account for it by offsetting our points.

[rbrott]

This would normally be ok but the drift is random between runs and seems to be heavily dependent on battery level.

There is no voltage compensation in the quickstart feedforward.

[SriramKalki]

We have the same problem. I have attached videos here as well.

https://user-images.githubusercontent.com/79238833/235279127-2aa16318-1be1-4e30-b98c-5855ca247c7f.mov

https://user-images.githubusercontent.com/79238833/235279128-7ef0bcd7-34f3-49fd-9014-3b9e67bdcfb7.mov

https://user-images.githubusercontent.com/79238833/235279129-9839bc5d-c230-43de-86c4-abfc5805c756.mov

[shishghate]

Were people able to find solutions to their drift issues? If so what were they as we were drifting to the left with 2 wheel odo. It was somewhat consistent, so we ended up coding around it.

Not pretty, but it worked. But now that we have more time, we are trying to get this nailed down for next year.

[SriramKalki]

@shishghate how exactly did you do it? Was the drift error constant?

We use 3 wheel odo, drift is random for us

[SriramKalki]

Also, how heavy are your bots? We're kinda heavy and use a lot of power in a match.

[SriramKalki]

Sorry to bother you, but what exactly made you think that there were faulty encoders on the bot? I am trying to track these inconsistencies. Thanks!

[rbrott]

You may be able to reduce consistent errors/biases with better wheel positions. I would suggest determining the wheel positions by spinning the robot in place. Start slowly and gradually increase the speed, collecting encoder data and IMU/gyro angular velocity all the time. Then conduct a regression of encoder velocity against angular velocity. Under RR's kinematic model, the relationship should be linear with zero intercept and a slope equal to the wheel position from the rotational center.

I've incorporated this method into the quickstart for RR 1.0. The tuning instructions still need some elaboration, but the code is already there in the dead wheel version of AngularRampLogger.

There may still be errors even with perfect calibration. Models never capture reality entirely. Most FTC teams deal with this gap by bringing their hardware more in line with the expectations of the model. The RR model assumes that wheels are always in contact with the ground, never slip, and never wobble (especially transverse to the direction of travel). Here observations of the robot behavior (e.g., slow motion video) and targeted experiments can help eliminate possible defects. There's no canned checklist of steps to follow -- this is the province of the scientific method. The best I can do is to drop a cite to the classic Box paper and to encourage some searches/questions on the FTC Discord.

[SriramKalki]

Thanks rbrott!

I got a question for everyone with the problem: How close are your battery wires to the odo wires? https://www.youtube.com/watch?v=hYOi2e7qJT4 this video (timestamp: ~9:10) says that battery wires being close created the problem. Other teams like 12993 have said the same. Our battery wires are very close to our odo wires.

[shishghate]

@shishghate how exactly did you do it? Was the drift error constant?

We use 3 wheel odo, drift is random for us

It was fairly constant, so we just adjusted the X, Y accordingly.