[Bug] Running to an absolute angle immediately after boot fails sometimes

[laurensvalk]

Describe the bug
Sometimes, going to an absolute position does not work. Mostly immediately after boot, so when running a program from flash.

To reproduce

I haven't identified a consistent reproducable case yet, but it has happened several times now. I'm also not entirely sure it is only after boot, but it does seem that way. I've only tried on Primehub so far.

Perhaps the motor is synched up, but did not receive its first data value yet.

For example, this script should put two motors 180 degrees apart, but sometimes it puts them in parallel.

from pybricks.pupdevices import Motor
from pybricks.parameters import Port, Direction

SPEED = 150

right_leg = Motor(Port.A, Direction.COUNTERCLOCKWISE)
left_leg = Motor(Port.B)

left_leg.run_target(SPEED, 0)
right_leg.run_target(SPEED, 180)

[laurensvalk]

Perhaps the motor is synched up, but did not receive its first data value yet.

This appears to confirm it. Flash this along with the firmware so you can run it after boot.

The first time you run this it shows 0 for all positions, while it should show the absolute angle instead.

from pybricks.hubs import PrimeHub
from pybricks.pupdevices import Motor
from pybricks.parameters import Port
from pybricks.tools import wait

hub = PrimeHub()

angles = {}

for motor_port in (Port.A, Port.C, Port.D, Port.E):
    motor = Motor(motor_port)
    char = repr(motor_port)[5]
    angles[char] = motor.angle()
    
while True:
    for char, angle in angles.items():
        hub.display.char(char)
        wait(500)
        hub.display.number(angle)
        wait(1000)
        hub.display.off()
        wait(500)

[laurensvalk]

In the setup during pbio_uartdev_update, we wait for (and parse) one full message. But we send the magic command for multi-mode feedback motors only after that, so we don't wait for one full message of that.

Therefore, motor data is not defined even though the motor is synced up and so we read zero.

[laurensvalk]

In short, this series of commits:

• Fixes the original issue of the absolute position being read as 0 soon after boot/plug in.
• Avoids motor ENODEV if a script is run too soon after plugging motor in or booting up, waits instead.
• Avoids sensor ENODEV if a script is run too soon after plugging sensor in or booting up, waits instead.

You'll still get ENODEV if you're so fast that it's still running the device connection manager, but this is much less likely and therefore much less annoying.

Since it fixes a bug and improves the user experience, I think it's worth including this in v3.0. Do you want to review this @dlech before merging?

[dlech]

It all looks reasonable to me. We should probably wait and call what we have now 3.0 though since this isn't a critical bug.

[laurensvalk]

I’d say the rotation sensor giving garbage values is probably a critical bug though. For example, a humanoid robot will fall flat on its face.

[dlech]

FWIW, when I say "critical bug", I mean it frequently affects a large number of users and there is no workaround.

[laurensvalk]

Right, but in robotics I’d include mechanical failures even if they don’t occur very often - safety first. There’s no such thing as a soft reboot if it just jumped off your desk.

For example, depending on the user script, this will try to flip the motor by up to 180 degrees at maximum power, which is probably critical.

And since we have the option to save programs permanently on the hub, this is part of the release features.

[laurensvalk]

Merged, so closing.