Interesting observation on motor runs

[Digital-Dominators]

Our team has noticed this for a while and hasn't have good solution to resolve it.

Here is the code:

left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.B)
drive_base = DriveBase(left_motor, right_motor, wheel_diameter=62.4, axle_track=112)

drive_base.settings(400, 100, 350, 370)
drive_base.turn(-90)
drive_base.straight(-50)

It is simply make a 90 degree turn and back a small distance(50mm). What we observed is when it backs, the 2 motors don't run at the same time, there is always one starting earlier which causes the motor swing a little bit instead of moving straight. Our guess is the PID kicks in but the distance is too small to make it fully work, so you can see that small swing at the beginning.
Here is the video:
Turn and Move

However, if we move the turn and just let the robot go back, even with a small distance (same 50mm), it can go straight without that swing. Then we guess it is because of the turn prior to the straight. There must be something introduced by the turn function to the motor that makes the PID kicks in with a huge initial error it thinks it should correct.

And we changed our code to this:

left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.B)
drive_base = DriveBase(left_motor, right_motor, wheel_diameter=62.4, axle_track=112)

drive_base.settings(400, 100, 350, 370)
drive_base.turn(-90)

##Added part
wait(50)
left_motor.close()
right_motor.close()
left_motor = Motor(Port.C, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.B)
drive_base = DriveBase(left_motor, right_motor, wheel_diameter=62.4,
                       axle_track=112)

drive_base.straight(-50)

It basically adds the motor close and re-initiate then create a new drive base. It magically resolves the problem.

Here is the video: Turn and move with motor resetting

Hope it can help other teams. Also could someone help to explain this to us and let us know if there is better way to do it?

[abliss]

PXL_20250603_181748298.3.mp4

I have noticed something very similar. I am testing a very simple program which has the drivebase go straight back, then hold 250ms, then straight forward. After the hold, one motor always starts just a moment before the other, causing a waggle. It's always the same motor, so the waggle is always in the same direction. If I switch the motors to each other's ports, the waggle then goes in the opposite direction, so I wonder if it might something inside the motor itself that's responsible?

[dlech]

It looks like you tried to upload a video, but it didn't complete.

[abliss]

thanks. Did it work now?

[laurensvalk]

By default, all drive base motions use Stop.HOLD. When you do subsequent movements, it will continue to adjust.

Since the motors can wiggle around a bit, this can appear to cause some movement, but it is generally better for performance overall. Basically, it is able to make additional corrections the next time it gets moving.

If you'd rather not have this, you can use Stop.COAST. Or just call drivebase.stop().

You generally shouldn't reset or reinitialize motors. If it appears to help here, that is likely because resetting them will happen to also coast them.

[abliss]

thanks, but changing to COAST does not seem to make much difference. I still see the same very reliable waggle from one motor always starting before the other. (If I go back and forward repeatedly, 250mm each time, this results in a slight "S" shape, such that the robot gradually but steadily creeps sideways away from its starting location, always in the same direction.)

[abliss]

Here's a simplified repro. I'm running this code:

from pybricks.hubs import PrimeHub
from pybricks.parameters import Axis, Direction, Port, Stop
from pybricks.pupdevices import Motor
from pybricks.robotics import DriveBase
from pybricks.tools import multitask, run_task, wait


# Set up all devices.
prime_hub = PrimeHub(top_side=Axis.Z, front_side=Axis.X)
motor_r = Motor(Port.A, Direction.CLOCKWISE)
motor_l = Motor(Port.B, Direction.COUNTERCLOCKWISE)
drive_base = DriveBase(motor_l, motor_r, 56, 114)


# Initialize variables.
accel = 100
delay = 0


async def main():
   drive_base.use_gyro(True)
   motor_r.control.limits(acceleration=accel)
   motor_l.control.limits(acceleration=accel)
   drive_base.settings(straight_acceleration=accel)
   for count in range(500):
       await wait(0)
       await multitask(
           motor_l.run_angle(500, 360, Stop.COAST),
           motor_r.run_angle(500, 360, Stop.COAST),
       )
       await wait(250)
       await multitask(
           motor_l.run_angle(500, -360, Stop.COAST),
           motor_r.run_angle(500, -360, Stop.COAST),
       )
       await wait(250)
run_task(main())

Here you can see the video, with the robot upright so there's no load:
https://github.com/user-attachments/assets/13b41fc2-bc7b-4006-9e76-7326eeafc44b
It doesn't happen every cycle, but more often than not, one motor (always the one on the left of the video--even if I switch the ports) activates before the other.

I've found I can work around it by adding a wait(1) on the eager motor. (If I use wait(0), the robot eventually S-curves sideways from its original position. If I use wait(5), it S-curves in the opposite direction.) So I guess the eager motor starts on average about 1ms earlier than the other one.

But this workaround limits me to using direct motor control, not the drive-base controls. Might there be any way to configure the drive base to introduce a 1ms lag before activating a particular motor, to compensate for this?

[abliss]

Actually, it seems like maybe I can fix this with motor_l.control.pid(). Increasing the integral dead zone seems to help. But is there any way to do this in the block language?

[laurensvalk]

Right, I didn't mean Stop.COAST would make it go away, just that resetting the motors as suggested by OP happens to have the same effect (and it is better not to reset the motors).

These motors have a lot of slack (just move the motors around to feel it). The problem is that it measures the wiggle at the far end but it doesn't have the full ability to control it since the motor is in the back end with a flexible gear train in between. When attempting to start two motors at the same time, one internal gear chain may be fully engaged while the other might not be, and there isn't a way to know.

To experiment with this, try a single straight or turn but manually engage the wheels one way, the other way, or in the opposite way and see how this affects the getaway.

Actually, it seems like maybe I can fix this with motor_l.control.pid(). Increasing the integral dead zone seems to help. But is there any way to do this in the block language?

So indeed, depending on the robot design there can be ways to tweak so that it is either more or less responsive to this sort of thing. Due to the inherent motor design there is unfortunately no universal solution (we've gotten pretty far as it is 😄)

Yes, you can call Python functions from blocks. We're making good progress in our user guides to eventually cover this there. Let me know if you'd like an example.