[Roadrunner V1.0] Manual Feedforward Tuner Weird Data

[karsteny]

(originally from the unofficial FTC Discord)
My team's been tuning roadrunner for the past couple hours, and everything up to this point has been going according to plan. However, upon getting to the ManualFeedforwardTuner step, it tells us to adjust kA until the lines match, but the v0 graph makes no sense. Adjusting kA doesn't seem to change the graph.

Any clue what's going on? We checked and make sure the deadwheels were making good contact (that had been an issue resulting in bad data earlier, but we redid the tuning upon discovering this). Nothing else seems to be an issue, except when running this test, the robot does instantly go from 0 to full power, then when it switches back it goes from full power to reverse full power without any transition. Not too sure if that's supposed to be happening.

Here's our parameters, in case you need them:

[rbrott]

Can you get a robot log please? https://rr.brott.dev/docs/v1-0/tuning/#getting-help

[karsteny]

Here's 8 different robot logs:
2023_12_15__17_48_22_925__ManualFeedforwardTuner.log
2023_12_15__17_45_00_669__ManualFeedforwardTuner.log
2023_12_15__17_43_52_577__ManualFeedforwardTuner.log
2023_12_15__17_43_44_468__ManualFeedforwardTuner.log
2023_12_15__17_39_49_296__ManualFeedforwardTuner.log
2023_12_15__18_07_42_321__ManualFeedforwardTuner.log
2023_12_15__18_08_37_097__ManualFeedforwardTuner.log
2023_12_15__18_10_05_060__ManualFeedforwardTuner.log

Also here's tuning logs from all 3 tuning pages with graphs:
angular-ramp-1702690296009.json
lateral-ramp-1702690031999.json
forward-ramp-1702689808731.json

[rbrott]

There's not enough information in the log for me to see what's going on (thanks for retrieving them though). I would recommend updating to the latest version of the library: com.acmerobotics.roadrunner:ftc:0.1.10. And then if you still see this pattern, collect a log from ManualFeedbackTuner which should have more data.

Separately, there are some issues with the tuning data. The forward ramp regression plot is much noiser than it should be:

Something is wrong with your dead wheels. I would check that they aren't bouncing / are sprung correctly. The points in that plot should be much more tightly clustered in a single line. Based on the other directions, par0 looks good while par1 and perp are struggling. And lateralInPerTick should always be positive, so you should flip the sign.

[karsteny]

Alright, we'll look into this (although it's gonna be a couple weeks as the team is taking a break). I do recall that we had the deadwheels sprung in a bit of a weird way, so we'll look into redoing the springing.

Our robot sometimes has a slight pull to one direction (which was observed during the tuning). Would that make the par1 and perp values be strange?

I'll let you know in a few weeks when we've tried some of this and attempted a retune. Thanks!

[rbrott]

Our robot sometimes has a slight pull to one direction (which was observed during the tuning). Would that make the par1 and perp values be strange?

The robot pulling in a direction shouldn't necessarily affect the encoder readings on something like the angular ramp logger/regression. Noise in those measurements is most likely coming from wheels bouncing up and down/losing contact with the ground or wobbling back and forth perpendicular to the rotation.

[karsteny]

Okay. We attempted to retune after looking at our springing yesterday. It didn't seem like the deadwheels were bouncing, but maybe we just missed it.
The forward ramp regression plot looked much better than before as well. Here are the regression files:
angular-ramp
lateral-ramp
forward-ramp
Also, par1 was much closer to expected (around 8200, and perp was also around 8300).

However, our manual feedforward tuning still didn't look right. Although tuning was cut short of trying more than a few values of kA, none of them seemed any closer.
Here's an example:

It does look different compared to before, but still not much better.

The only difference we observed with that test was when we used the suggested initial value of 0.0000001. There, the v0 graph had 2 states: a relatively flat (with some noise) line around +-20, when driving at a constant speed, and then a lot of big up/down spikes, when it would abruptly change directions. I don't have any images of the graph, but it would look similar to the graph already shown, except where the green boxes are, it would be a flat line with the noise like seen briefly multiple times.

Unfortunately, we forgot to update to the latest version. We are running com.acmerobotics.roadrunner:ftc:0.1.3. We can try updating to the latest version, if you think that will make a big difference here. If not, any other ideas as to what could be wrong?

[karsteny]

Minor update: We tried to update the roadrunner version to 0.1.10, but then in TuningOpModes an error gets thrown that says "MotorFeedforward cannot be converted to FeedforwardFactory". No idea what's happening there.

Also, here's an example image with the ManualFeedforwardTuner with a kA value of 0.0000001, to demonstrate the flat parts outlined in the previous message.

Higher kA values seem to lead to

• The blue graph becoming noisier
• Changing when along the red graph the robot changes direction. With low kA values, it changes direction at around when vref equals zero. Higher kA values shift it to a different point on that graph. For example, a kA value of 1 had the robot change direction at or around the peaks/troughs of the vref graph. The robot is still instantly going from full power one direction then full power the other direction, causing a lot of slippage (and noise).

[rbrott]

• I suspect your inPerTick is wrong. Your maximum velocity in in/s is inPerTick / kV ~= 5.
• Your encoders seem to be overflowing. Make sure they're wrapped in OverflowEncoder() objects (this is now the default)
• You should upgrade from 0.1.3 as you noticed. To fix the errors, you need to change code in the quickstart itself. See the latest quickstart / commit history for guidance,

[karsteny]

Alright. It appears that all of those issues, and we got past the that part of the tuning. Thank you so much for your help with that issue!

But now, we're stuck on ManualFeedbackTuner.

We're not super experienced in terms of how the feedforward/feedback works, so we have no idea how to react to the telemetry and the issues the robot is having. When driving back and forth, it has some minor drifts, which we don't quite know how to account for as setting any of the gains to 1 just makes it worse. The main issue is that sometimes the x-position kinda bounces around +-a few inches for a second while moving (thus being way off), or it just drifts over time, leading to the distance traveled in the back and forth eventually increasing to an insane degree. None of this happened with the ManualFeedforwardTuner (unless we just didn't run it long enough for the errors to occur).

Any guidance on how we can go about this step? Thanks.

[rbrott]

When driving back and forth, it has some minor drifts, which we don't quite know how to account for as setting any of the gains to 1 just makes it worse. T

Usually this means something is wrong (possibly reversed?). Can you send a robot log?

[karsteny]

Hey,

Turns out we've been having a deadwheel that was slipping (but hard to identify), which was causing the program to think that the robot was turning, which seemed to completely mess it up.

We're going to retune again, and I'll send over some logs if the issues persist.