ManualFeedforwardTuner test and RR 1.8 ( now 1.11) tuning help!!

[pritiarya]

Hello, we are tuning using RR 1.8 and Three Odo and in our ManualFeedforwardTuner test, the robot moves abt 6 inches back and forth instead of 64 inches. Our perpendicular encoder is at the back of the robot and we have the left and the perpendicular encoder direction reversed in code.

We got the following values from the tuning process so far: Forward Push test - after exclusion of points kV: 0.00010724664334916354, kS: 0.9920696529432735

angular ramp logger: trackWidthTicks = 28156.85310706782 inPerTick = 0.02224460305; //this we are using from the GoBilda specs and NOT from the tests lateral in per tick: 0.01387644451932522.

Parallel 0 y-position: -11702.617787599618 Parallel 1 y-position: 11636.31641072519 Perpendicular wheel 0 x-position: -9064.884736187201

During the LateralRamp Logger test, we did not get any graph. Only after we added the kV , ks and in per tick params that we were able to generate graph - is that the correct approach? Also in this test, the robot didnt strafe left but kida moved diagonally.

Do the attached pics looks like the tuning is going good? How do we improve on the lateral test .

[rbrott]

During the LateralRamp Logger test, we did not get any graph. Only after we added the kV , ks and in per tick params that we were able to generate graph - is that the correct approach?

Yes, you need those parameters to make the graph. Any errors in those inputs from earlier steps will compound in this step.

Also in this test, the robot didnt strafe left but kida moved diagonally.

Judging from the plot, your robot seems to struggle a lot with strafing. Do you have any videos of the robot trying to strafe or pictures of the robot in general? I would either avoid strafing or look into mechanical changes.

There's also wobble in the plot which suggests that the perpendicular pod is also moving back and forth. You should also fix that before doing any strafing.

Do the attached pics looks like the tuning is going good?

The forward ramp regression looks fine, but you need to exclude the points on the left to get a better fit. Your kS looks like it should be >1.1 instead of at 0.99. Fixing that won't make a major difference in the other plots, though you should still do it.

[pritiarya]

Attched is a video we took of the lateral ramp test

https://github.com/acmerobotics/road-runner-quickstart/assets/83506653/a1056d76-d0c4-43d4-a702-a0ee594f445f

Also For the angular ramp test - we have par 0 with a -ve slope and par 1 with a +ve slope. However the perpendicular also has a -ve slope. Is that normal?

[rbrott]

Also For the angular ramp test - we have par 0 with a -ve slope and par 1 with a +ve slope. However the perpendicular also has a -ve slope. Is that normal?

That sounds fine. Odometry wheel positions can be positive or negative.

[pritiarya]

Hi, we re-built the drive train again - now geting the following values:

HEllo,

Our manualFeedForwardTuner graph is very spiky, also getting -ve value for kV, are these values Ok (within acceptable range) or does some direction need to be reversed?

kV: -0.00012019244039050385, kS: 0.8507004158989862, k A: 0 (Anything above or below this makes the robot go CRAZY) inPerTick = -0.0005769 lateral in per tick: -0.00049875224848382, y-intercept: 0

track width: -22985.24183518498, y-intercept: 0

par0 and par1 are both -ve par0 graph y-position: -10434.356095299363, y-intercept: 0 par1 graph y-position: -10793.15234628387, y-intercept: 0 perp graph x-position: 9194.789276546897, y-intercept: 0

Also for ManualFeedback tuner, the robot just stafed left so be aborted the tuning !

[rbrott]

kV: -0.00012019244039050385, kS: 0.8507004158989862, k A: 0 (Anything above or below this makes the robot go CRAZY) inPerTick = -0.0005769 lateral in per tick: -0.00049875224848382, y-intercept: 0

track width: -22985.24183518498, y-intercept: 0

kV, inPerTick, lateralInPerTick, and track width should all be positive. Have you reversed your motors properly?

par0 and par1 are both -ve par0 graph y-position: -10434.356095299363, y-intercept: 0 par1 graph y-position: -10793.15234628387, y-intercept: 0 perp graph x-position: 9194.789276546897, y-intercept: 0

These signs are potentially fine, though you should re-run everything after you fix the encoders (see above).

Also for ManualFeedback tuner, the robot just stafed left so be aborted the tuning !

That's a good sign that your IMU is configured improperly. Make sure the orientation is specified correctly. (Also you should upgrade to 0.1.10, the latest version of the com.acmerobotics.roadrunner:ftc library.

[pritiarya]

Thanks! Upgraded to 0.1.10 and running the tests again, trying different combinations to see how to get a +ve value in the ForwardPushTest for inPerTick

In the latest test we got -69.5 ticks for distance travelled of 48 in

We have this in the MeccanumDrive class:

        leftFront = hardwareMap.get(DcMotorEx.class, "LF");
        leftBack = hardwareMap.get(DcMotorEx.class, "LB");
        rightBack = hardwareMap.get(DcMotorEx.class, "RB");
        rightFront = hardwareMap.get(DcMotorEx.class, "RF");

        leftFront.setDirection(DcMotorEx.Direction.REVERSE);
        leftBack.setDirection(DcMotorEx.Direction.REVERSE);
        rightFront.setDirection(DcMotorEx.Direction.FORWARD);
        rightBack.setDirection(DcMotorEx.Direction.FORWARD);

We are using 3-deadwheel localizer:

localizer = new ThreeDeadWheelLocalizer(hardwareMap, PARAMS.inPerTick);

and our encoders are mapped this way. (par0 is the on the left of the robot):

        par0 = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "LF")));
        par1 = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "RB")));
        perp = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "LB")));

        //par0.setDirection(DcMotorEx.Direction.REVERSE);
        par1.setDirection(DcMotorEx.Direction.REVERSE);

Attached pic when the robot is lifted from the front (so hand in the pic is holding the left encoder / par0)

[amjadj]

Did you try setting par0 and par1 direction to forward?

On Thu, Dec 21, 2023 at 10:37 PM pritiarya @.***> wrote:

Thanks! Upgraded to 0.1.10 and running the tests again, trying different combinations to see how to get a +ve value in the ForwardPushTest for inPerTick

In the latest test we got -69.5 ticks for distance travelled of 48 in

We have this in the MeccanumDrive class:

    leftFront = hardwareMap.get(DcMotorEx.class, "LF");
    leftBack = hardwareMap.get(DcMotorEx.class, "LB");
    rightBack = hardwareMap.get(DcMotorEx.class, "RB");
    rightFront = hardwareMap.get(DcMotorEx.class, "RF");

    leftFront.setDirection(DcMotorEx.Direction.REVERSE);
    leftBack.setDirection(DcMotorEx.Direction.REVERSE);
    rightFront.setDirection(DcMotorEx.Direction.FORWARD);
    rightBack.setDirection(DcMotorEx.Direction.FORWARD);

We are using 3-deadwheel localizer:

localizer = new ThreeDeadWheelLocalizer(hardwareMap, PARAMS.inPerTick);

and our encoders are mapped this way. (par0 is the on the left of the robot):

    par0 = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "LF")));
    par1 = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "RB")));
    perp = new OverflowEncoder(new RawEncoder(hardwareMap.get(DcMotorEx.class, "LB")));

    //par0.setDirection(DcMotorEx.Direction.REVERSE);
    par1.setDirection(DcMotorEx.Direction.REVERSE);

Attached pic when the robot is lifted from the front (so hand in the pic is holding the left encoder / par0) IMG_5197.jpeg (view on web) https://github.com/acmerobotics/road-runner-quickstart/assets/83506653/fdc10d88-dbdd-45fb-9521-31295bde6ffb

— Reply to this email directly, view it on GitHub https://github.com/acmerobotics/road-runner-quickstart/issues/329#issuecomment-1867229757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKGCJFLNTNHMQLDQ5UKXII3YKUE7FAVCNFSM6AAAAABAO3NC5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGIZDSNZVG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[aryamaneaditi410]

Hello I'm also a programmer on this team. All of our encoders had to be reversed because when they are forward they provided the negative kV and slope values we didn't want. So far, all of our steps are working except for ManualFeedForward Tuner, which does not move at all when kA = 0, and still moves only one square when kA is high (0.01)

Picture of kA at 0:

Picture of kA at 0.01

[rbrott]

Your inPerTick seems to high. Are you sure that both parallel encoders are going in the right direction?

[pritiarya]

Hello, we switched to RR 1.10, also synced the latest FTCWires fork, however now we are getting the lateral ramp logger and perp encoder as a flat line - does that mean issue with the perpendiculra encoder? We do see values in the JSON file though

We left the lateralInPerTick as 1 and went ahead with the ManualFeedforward and ManualFeedback tuner but the graphs were not good.

lateral-ramp-1703708000378.json forward-ramp-data-2-12-27.json lateral-ramp-data-2-12-27.json

Here's the graph we get for the Manual Feedback tuner - and its nowhere close to the field view . Once I changed the heading gain to 0.5, the robot strafed a lot that we had to stop.

[pritiarya]

OK - we went to using the DriveEncoders and the tests seem to be much better. We could actually do the ManualFeedback and Localizer test. So, we may stick to using the DriveEncoders for now until figure out how to fix the 3-wheel odo and we are tuning at the tuning part for 3-wheel odo for too long.

The SplineTest for the DriveEncoders shows erratic results. attached screenshot and logs $Stop$Robot$ 2023-11-03 22_29_57.csv

Other values With DriveEncoder: inPerTick = Before localization test: 0.023046 After localization test: 0.02258424

lateralInPerTick = 0.02301606 Yet to do StrafeTest

kV: 0.004255915479159497 kS: 1.3975746299296725 KA: 0.0001 track width: 1253.8151615179645

axialGain = 1.0; lateralGain = 1.0; headingGain = 1.0;

Motors are 5203 Yello jacket - 312 RPM GoBilda

[pritiarya]

Team didnt want to give up on dead-wheels yet. Made sure the odopods and connected properly, re-did all the tuning.

While turning for RR 1.10 (3 dead wheel odometry) we see that the graph is all over the place while the robot is pretty much moving straight ( see video) In previous tuning steps we kept kA and the gains ( heading/ axial/ lateral) as 0 as increasing it the robot path become worse . forward-ramp-1703955747181.json lateral-ramp-1703956011299.json angular-ramp-1703956315021.json

https://github.com/acmerobotics/road-runner-quickstart/assets/83506653/f831582b-bc5d-4e98-b6d9-f6541320ccbb

All the other graphs for angular/ lateral and forward ramp were fine.

[pritiarya]

Saw a new debug mode DeadWheelDirectionDebugger and ran it parallel wheel 0 and 1 both have -ve values and big difference between them. Rotated the parallel dead wheel each as if they are moving forward and the values increase ( they are -ve so go closer to 0) . Moving there perp encoder as if it’s going left increases its value

are the values correct/ in range ?