Feature Request: Have `wait=False` option in `run_until_stalled()`

[strichter]

For me at least, it seems that run_until_stalled is a nice way of resetting your robot when it is in an unknown state. It would be nice if I could run all resets at the same time, but I need to be able to not wait for the stall to happen to achieve that.

[laurensvalk]

I'll get back to you on why we currently don't have this (it is intentional), but here's how you can do the same in another way.

run_until_stalled is essentially a convenience function for something you can make (and customize) using these ingredients:

mtr = Motor(Port.A)
mtr.run(speed)
while not mtr.control.stalled():
   wait(10)
mtr.stop()
mtr.angle() # This value is returned on completion

[laurensvalk]

Side note in case you run into this - the brake() and hold() methods in the docs are not included with the current beta yet. That will follow later this week.

[strichter]

Ah, I did not know about control. I thought I had seen it but when I grepped for it yesterday it did not come up.

[strichter]

Is there another way to simulate hold(). In my experiments yesterday I noticed how it "bounces" back after stalling and that bounce is different based on slight physical differences, so I end up in an uneven state.

(I am building a robot dog and I am using the stalled detection to reset the legs and get into a known state.)

[laurensvalk]

Yes, you can give Stop.HOLD as an argument on most motor commands, including run_until_stalled.

It is default everywhere except for run_until_stalled, because it might leave a mechanism in a highly loaded state.

[laurensvalk]

You can also experiment with the duty_limit setting, so it doesn't try to use 100% torque during this maneuver.

[laurensvalk]

Oh, and hold() (added in next beta) is essentially just a shortcut for running by 0 degrees and holding there. So to stop and hold right here, right now, you can do: run_angle(500, 0).

[strichter]

Perfect, I should have tried that. But then I thought it might ignore a 0 angle input.

[strichter]

@laurensvalk if I am writing my own run_until_stalled() (which I am since I am running two motors at the same time), how can I set the duty_limit? Is it the same as actuation in limits()?

[laurensvalk]

Yes, it’s the same.

Run until stalled just applies the limit temporarily and sets it back when done. It is indeed exactly the convenience function for the use case you describe: resetting a mechanism.

And often the duty limit is only desirable during the reset. This allows you to easily reset even heavily geared mechanisms which would otherwise happily twist your axles permanently :)

[laurensvalk]

Also, a new beta is available. All stop-related stuff now matches the docs again.

[laurensvalk]

I'll get back to you on why we currently don't have this (it is intentional)

And now for the long awaited promised answer (pun intended). In the long run we might to drop the wait=False technique in favor of more common techniques such as async/await.

In particular, run_until_stalled returns a value at the end which it could not do with wait=False. Also, since it is intended to make mechanisms stall, we figured might not be recommended with a fire-and-forget approach like wait=False.

There is no technical limitation, though, as it it really does just use the same controller as run, which runs in the background by definition. So we could still add it in principle.

[strichter]

MMh, the return value is an argument. But then your docs do not say anything about a return argument.

Anyways, in my case I am resetting 8 motors (over two bricks) at the same time, so I really do not want to wait.

[laurensvalk]

MMh, the return value is an argument. But then your docs do not say anything about a return argument.

That must be missing - thanks!

Another reason is resetting the actuation limit at the end again. That is somehow technically possible of course, but it means doing all kinds of things in background tasks.

Anyways, in my case I am resetting 8 motors (over two bricks) at the same time, so I really do not want to wait.

Agreed - but just to add, even with wait=False, you'd still need some code just like you made, to make them wait for all to finish, especially across bricks.

So it is a convenience function that is helpful for a few common use cases, but not everything, so that's why the ingredients are available for further customization. (No other EV3 language has a reliable stalled method/flag or configurable actuation limits as far as I know.)