Twitchy and Sometimes Delayed

Software Blocks
1

Our team uses blocks and have defined functions for most of our movements, in which we use the “RUN_TO_POSITION” mode. An issue we run into at times, is that once it basically reaches the targeted tick, motors will independently twitch. I believe it is making some very small adjustments to get to the exact position, for example if the position was 1000, but it went to 1002, it goes backwards for 2, which may then affect another motor so it has to adjust. This causes the robot to spend some extra time sitting there doing the adjustments. Below is an example function we use (copied by using the Java Code window). As you can see, we stay in the function until all of the motors are no longer busy. Is there maybe a better way to handle this, as sometimes it gets to its target point, then will maybe adjust for another second or two - where you see one or more motors twitching. And other times, it just seems to sit there doing nothing for a second or two, and then goes to the next function. And if you run the same exact program 10 times it may do it perfectly 5 times, then a couple where it twitches but runs perfectly, and a couple where it just seems to wait a second or two between functions.

private void moveForward(int ticks, double power) {
leftFront.setPower(power);
leftRear.setPower(power);
rightFront.setPower(power);
rightRear.setPower(power);
leftFront.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
leftRear.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
rightFront.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
rightRear.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
leftFront.setTargetPosition(ticks);
leftRear.setTargetPosition(ticks);
rightFront.setTargetPosition(ticks);
rightRear.setTargetPosition(ticks);
leftFront.setMode(DcMotor.RunMode.RUN_TO_POSITION);
leftRear.setMode(DcMotor.RunMode.RUN_TO_POSITION);
rightFront.setMode(DcMotor.RunMode.RUN_TO_POSITION);
rightRear.setMode(DcMotor.RunMode.RUN_TO_POSITION);
while (!isStopRequested() && (leftFront.isBusy() || leftRear.isBusy() || rightFront.isBusy() || rightRear.isBusy())) {
telemetry.addData(“Progam”, “FORWARD”);
telemetry.update();
}

2

…we stay in the function until all of the motors are no longer busy.

… which may then affect another motor so it has to adjust.

These two statements can guide you to another path to pursue.

Your observations confirm what is happening: your OR logic requires that all encoders are satisfied, which happens only when they all settle down and stop perturbing each other. Which can be a somewhat random and prolonged process, given the tiny adjustments at that point.

So, would you be satisfied if fewer than 4 motors have reached their target? Maybe only one? If so, which one(s) to select? Does that choice depend on the driving action being concluded? Is the result less random than what you have now? These questions can be fun for students to consider and test.

Try testing fewer motors and/or changing your OR expressions to AND. Stop all motors after exiting the loop.

For development and debugging, it’s useful to display live telemetry in a 10-second loop after stopping the motors. The final encoder values may guide your choices in terminating the driving loop.

================

This is another example of realizing that (in robotics) sometimes you can be happy with “repeatable”, rather than always requiring “accurate”.

3

Forgot to mention, setPower() should follow setMode(RTP).

4

Thanks for the quick reply. That is kind of what we were thinking and thanks to your confirmation will perform some testing as you advised. Thanks also for the tip on putting power after setting the position. We’ll look at reordering those too.

5

Great! It’s a good ‘science project’, very approachable for Blocks teams.

And fruitful, as your Autonomous can become much more reliable.

I might also suggest adding a short pause (e.g. 200-500 ms) after each driving action, if you can afford it. This gives the robot a chance to stabilize (after braking and oscillating) before the next driving action, further reducing random variation from run to run.