Documentation for Quickstart2 Configuration

[EddieDL]

I love what has been done with Quickstart2.

I am confused about how to configure all of the settings. Below is what I think these mean, but the documentation and comments don't seem to clarify this for me.

MechanumDrive

• inPerTick: The number of inches the robot travels forward and backward per tick counted by the encoder (it isn't clear to me if this is the localization encoders or the motor encoders)
• lateralInPerTick: The number of inches the robot travels laterally per tick counted by the encoder (it isn't clear to me if this is the localization encoders or the motor encoders)
• maxWheelVel: the maximum velocity possible for the wheels (it isn't clear if this really the velocity of the wheels vs the robot velocity also is it in ticks/s?)
• minProfileAccel: This seems to be the allowable "slowdown" acceleration?
• maxProfileAccel: This seems to be the allowable "speed up" acceleration?
• maxAngVel: this seems to be the same as before the max turning velocity in radians/s
• maxAngAccel: this seems to be the same as before the max turning acceleration in radians/s/s
• Path controller gains: It isn't 100% clear what any of these are. I am pretty sure one has to do with how far off the pose is and the other is how far off the velocity is.

TwoDeadWheelLocalizer

• PAR_Y_TICKS and PAR_X_TICKS: Seems like it is some sort of conversion factor between the inPerTick defined in the MechanumDrive and what the dead wheels use?

Also, where do we define the position of the dead axel wheels now? Perhaps the new tuning procedure removes the need to figure this out?

[rbrott]

• inPerTick: The number of inches the robot travels forward and backward per tick counted by the encoder (it isn't clear to me if this is the localization encoders or the motor encoders)
• lateralInPerTick: The number of inches the robot travels laterally per tick counted by the encoder (it isn't clear to me if this is the localization encoders or the motor encoders)

Correct. The notion of "inches the robot travels laterally per encoder tick" might be strange/confusing for some people. You can also think of it as inPerTick = lateralMultiplier * lateralInPerTick.

The ticks here are always localization encoders. The quickstart is now designed to handle dead wheels without motor encoders.

• maxWheelVel: the maximum velocity possible for the wheels (it isn't clear if this really the velocity of the wheels vs the robot velocity also is it in ticks/s?)

Like the old MAX_VEL, maxWheelVel is not the maximum velocity your wheels are capable of. It's rather a self-imposed limit on the wheel velocities of the robot when planning trajectories. The distance units here are inches (I'll see about adding that in a comment).

• minProfileAccel: This seems to be the allowable "slowdown" acceleration?
• maxProfileAccel: This seems to be the allowable "speed up" acceleration?
• maxAngVel: this seems to be the same as before the max turning velocity in radians/s
• maxAngAccel: this seems to be the same as before the max turning acceleration in radians/s/s

Correct

• Path controller gains: It isn't 100% clear what any of these are. I am pretty sure one has to do with how far off the pose is and the other is how far off the velocity is.

• axialGain / lateralGain are TRANSLATIONAL_PID.kP split out into the two robot-centric components
• axialVelGain / lateralVelGain are TRANSLATIONAL_PID.kD split out similarly
• headingGain is HEADING_PID.kD and headingVelGain is HEADING_PID.kD

• PAR_Y_TICKS and PAR_X_TICKS: Seems like it is some sort of conversion factor between the inPerTick defined in the MechanumDrive and what the dead wheels use?

PAR_Y_TICKS is the y-position of a dead wheel placed parallel to the forward axis in the units of ticks. PERP_X_TICKS is the analogous quantity for the x-position of perpendicular dead wheels.

Also, where do we define the position of the dead axel wheels now? Perhaps the new tuning procedure removes the need to figure this out?

Yes, you're supposed to tune those positions in the angular ramp step.

[EddieDL]

@rbrott This is super helpful. Some follow up questions and one new issue.

• When I look at the documentation for the lateralInPerTick tuning it says "mecanum drive encoders only". We are only using dead wheel localizer. Am I correct that we do not need to fill this in? Does the current quickstart work without drive while encoders?
• We are running the forward ramp test but nothing ever loads in the dashboard. We are trying a few more things and I am going to look through the issues, but I thought I would ask about it here as well. We also tested the lateral ramp test and we are having the same results. Also on the forward test page it says Lateral, but it is for sure different than the lateral test.

[EddieDL]

We figured out the second question. It looks like you updated the dependencies about 2 hours ago and that solved the problems.

[rbrott]

Does the current quickstart work without drive while encoders?

Yes, it should work with any combination of (mecanum, tank) and (drive encoder, dead wheel) localization.

When I look at the documentation for the lateralInPerTick tuning it says "mecanum drive encoders only". We are only using dead wheel localizer. Am I correct that we do not need to fill this in?

You do need to fill in lateralInPerTick even if you're using dead wheels. While it won't be used for localization, it will be incorporated into the feedforward to supply extra voltage while strafing.

You're correct that LateralPushTest shouldn't be used with dead wheels. Instead you should use LateralRampLogger.

[EddieDL]

Okay I think we have sorted out all of those questions. But there didn't seem to be a way to find the per/par x/y value. So we measured and converted the inches to ticks. If there is a way to find these let me know.

Is there any setting changes we have to do when we aren't using drive encoders? I can't see where it would set the motors to run with or run without encoders. Also, it isn't 100% clear to me if the set power commands will use -1.0 - 1.0. We seem to be having a situation where the manual feedforward tuner is just always running full power.

[EddieDL]

Another piece of information. We skipped ahead to the spline test and everything works pretty good. The heading is the worst off, but everything else is within probably 5 inches.

Also, I can't seem to add additional logging so that I can see what it is doing. I probably need to split this out into another issue, but it seems like we are getting close.

[rbrott]

Okay I think we have sorted out all of those questions. But there didn't seem to be a way to find the per/par x/y value. So we measured and converted the inches to ticks. If there is a way to find these let me know.

They should be displayed in dead-wheel-angular-ramp.html. If they didn't, there may be some bug. Would be super helpful to see the web console messages in that case.

Is there any setting changes we have to do when we aren't using drive encoders?

Nothing besides localizer =.

I can't see where it would set the motors to run with or run without encoders.

There is no RUN_USING_ENCODERS parameter anymore, and the default is to not use the built-in SDK/hub velocity PID.

Also, it isn't 100% clear to me if the set power commands will use -1.0 - 1.0. We seem to be having a situation where the manual feedforward tuner is just always running full power.

Oops there's a bug in setDrivePowers(). Fixed in 0.1.5.

[EddieDL]

All great stuff. As usual you are very helpful.

We are done with our meeting for today and I am going to be out for a few weeks, but I will work with the team to see if they can get some details for you on the dead-wheel-angular-ramp.html page. I am 99% sure that it didn't display but I can't say for sure.

[EddieDL]

Oh wait! The dead-wheel-angular-ramp.html works. It just wasn't clear that you need to scroll down to see more graphs and data. Now that I am at home with a bigger monitor I saw them all. I do have a few questions about them still:

• The graphs display both an X and a Y for both the per and par wheels. The old version of the QuickStart uses both, but this one doesn't appear to. What is correct?
• Our robot doesn't exactly turn on the center of the robot. I presume that is why we are getting colocations like the image below. Should we try to get those tuned in or just go with the regression line?

[rbrott]

• The graphs display both an X and a Y for both the per and par wheels. The old version of the QuickStart uses both, but this one doesn't appear to. What is correct?

With the dead-wheel kinematic model RR uses, only the y-position (resp. x-position) of parallel (perpendicular) dead wheels actually matters. In general, once the orientation of the wheel is fixed, the only necessary measurement is the perpendicular distance to the center of rotation.

• Our robot doesn't exactly turn on the center of the robot. I presume that is why we are getting colocations like the image below. Should we try to get those tuned in or just go with the regression line?

It's fine for the rotational center of the robot to not match the center of the drivetrain (in principle you could use that information to get better feedforward, but it's more important that the localization is accurate). Not really sure what the oscillations are in the robot frame, though they might not be significant enough to matter much.

[EddieDL]

I think this probably answers everything.

I had completely wrong per/par positions for the dead wheels and we skipped the feedforward tuning (because it was not working) and tried the spline test. I was surprised how well it did. I would expect it to be significantly better going forward, but this is what it looked like with some not great values (if you are interested). https://youtu.be/L-7lP8KMMpQ https://youtu.be/8AcTxOJB8Zw