setVelocity or setPower

[wangxdflight]

This is basically a question not really issue reporting. It seems that currently RR's output/activation to wheel motor is based on setPower API. If we use RUN_USING_ENCODER, shouldn't we use setVelocity instead of setPower? Or it doesn't matter?

Another side question, Is transitional PID used to adjust both xError and yError? Can we use a separate set of transnational PID for yError?

Thanks.

[rbrott]

It seems that currently RR's output/activation to wheel motor is based on setPower API. If we use RUN_USING_ENCODER, shouldn't we use setVelocity instead of setPower? Or it doesn't matter?

You're correct that it doesn't really matter. setPower() is necessary for open loop voltage control, and it's helpful to use the same drive API methods.

Another side question, Is transitional PID used to adjust both xError and yError?

Yes, it's for both.

Can we use a separate set of transnational PID for yError?

Of course. You'll want to modify this line.

[wangxdflight]

Really appreciate your prompt reply. That clarified a lot. Another question, in our experience, strafing is difficult to be accurate and consistent as moving forward straight. We think of using separate set of PIDs and different velocity and acceleration constraint for strafe move. It will be another instance of drive class. Seems that trajectory builder is not supposed to support two drive instances.

Errors in previous move should carry on and be corrected continuously in the next move, right? If this is the case, it is hard to use two drive distances.

Any suggestions on how to work around it?

[rbrott]

We think of using separate set of PIDs and different velocity and acceleration constraint for strafe move.

The best way to accomplish this is by writing your own custom velocity/acceleration constraints that enforce different limits for lateral movement. Look at the MecanumConstraints for guidance.

[wangxdflight]

Maybe it is confusing as I asked about Y dimension translational PID in my earlier post. I already did X transitional PID and Y transitional PID, and they helped moving straight. My understanding is that Y PID helps correct Y dimension off.

But these parameters don’t work for strafe move at all. One reason might be that we are using odometry wheel for tracking. This is why we want to create a separate drive class just for strafing. But is having a hard time to use two drive instances with trajectory builder.

Were you suggesting to still use one drive class, but with a separate drive constraints for strafe move? Not sure sharing the same set of PIDs with straight move will work.

[rbrott]

Maybe it is confusing as I asked about Y dimension translational PID in my earlier post. I already did X transitional PID and Y transitional PID, and they helped moving straight. My understanding is that Y PID helps correct Y dimension off.

The PID controllers in the holonomic follower operate in the robot frame, not the field frame. X in this context is forward/back, and Y is left/right.

But these parameters don’t work for strafe move at all. This is why we want to create a separate drive class just for strafing. But is having a hard time to use two drive instances with trajectory builder.

I don't think you need to have multiple drive instances. You should be able to have two separate sets of coefficients with two independent followers that share one drive instance. Depending on the move, you can alternate between each follower without interference. On the trajectory generation side, you can either maintain two sets of constraints and switch between them or, even better, create your own constraints that incorporates the anisotropy of the drive mechanism with different limiting for the lateral and longitudinal/axial dimensions.

[wangxdflight]

Thanks. Will need some time to explore it.

[wangxdflight]

Thanks...switching follower works.