run_target() with Stop.HOLD interferes with imu.stationary() ??

[vascolp]

Hi, here I am again... This time a small program and hopefully reproduceable.

If I do a run_target(… Stop.HOLD…) before I call a imu.stationary(), the imu.stationary() will always return false. Tried with Technic and Prime hubs, pybricks 3.6.1. The same with Stop.BRAKE.
It happens even with: angular_velocity_threshold=20, and/or acceleration_threshold=5000, so I suppose it has nothing to do with it.

By the way, it seems that the order of the returned values of imu.settings() is not exactly the same as stated in documentation… the heading_correction is in the end.

The sample program:

from pybricks.hubs import ThisHub
from pybricks.pupdevices import Motor
from pybricks.parameters import Port, Stop, Color
from pybricks.tools import wait

hub = ThisHub()

#hub.imu.settings(angular_velocity_threshold=20, acceleration_threshold=5000)
print('IMU settings:', hub.imu.settings())
m=Motor(Port.A)
m.run_target(400,  300, then=Stop.HOLD, wait=False)
wait(800)
while not hub.imu.stationary():
    hub.light.on(Color.RED)
    wait(50)
    hub.light.on(Color.ORANGE)
    wait(50)
    # program stucks here if above is HOLD or BRAKE

hub.light.on(Color.GREEN)
wait(4000)

[BertLindeman]

What kind of robot do you use.
As I do not see what influence the motor has on the hub.
Solid underground?

[vascolp]

My feeling is it has nothing to do with stability.
Check the program above, put a hub in stable table with a motor in port A and run it. You will get the problem.
What I am doing: I am doing a Stweart Platform controlled by a hub IMU... I had already the initial motors calibration and was trying to incorporate the IMU, which I tested previously standalone, and it worked. Then I called the IMU after the motors calibration and got this. I found that replacing the Stop.HOLD with a Stop.COAST solved it.

[BertLindeman]

I think you are right.

• Technic hub on a stable underground version 3.6.1 and later at git hash 0f065bbd
• motor attached so the motor movement (if any) does not influence the hub
• running the program above with STOP= NONE / HOLD / BRAKE keeps the loop running,
  maybe hub.imu.stationary() is no longer updated?

Your remark about the order of the values of imu.settings() is valid.
That is why the doc urges to use keyword arguments.

Bert

[vascolp]

Your remark about the order of the values of imu.settings() is valid. That is why the doc urges to use keyword arguments.

The problem is not with the arguments but when you call settings() without arguments. In that case you receive a list of values that does not match the docummented order. It might confuse some users...

[laurensvalk]

When motors are being actively controlled, stationary returns false. Put another way, the IMU won't recalibrate itself when motors are active.

But I can see why this would be inconvenient if you want to test stationary for other purposes. Maybe we should remove this restriction for the user command?

[vascolp]

To me, refering that in the stationary() method documentation would be enough.
I don’t have a use case for that situation, it just happened…