Stopping the simulation does not stop the robot if the motors are running

[humbug99]

Pressing the stop button in the simPanel stops execution of the python code, but if the robot motors are on, they will stay on.

Simple example:

pen_in5.down() steering_drive.on(10, 10)

Press stop. The robot keeps driving and drawing the pen trace.

Expected behavior: The robot stops moving where it it.

The current behavior makes it hard to debug issues on worlds without walls. For instance, on the line following examples, if the robot is moving, pressing stop causes the robot to keep moving and eventually drive off the world. This makes debugging a problem difficult, because it's not possible to see where the robot was at the time the simulation was stopped.

[QuirkyCort]

That is the behaviour in ev3dev. In a real ev3 running ev3dev, stopping the program does not automatically stop the robot. The motors are controlled by the OS. When the program is stopped, no new commands are sent to the OS, so the last command remains in effect. To stop the robot, an explicit stop command must be issued. Such behaviours isn't that uncommon where the high level code is sending commands to low level code that is running separately.

I think brickman issues a stop command when you stop a program through it, but I haven't played around with ev3dev in quite a while now (...and I usually run the program via ssh). Can anyone confirm?

Whether I should continue to follow the ev3dev behaviour is up for discussion. The surprise of having the motor continue running when the program stops is something that students may likely encounter sooner or later. With the current behaviour, it is "sooner", but perhaps "later" may be better.

[shravan01]

Can there be a pause option just to hold all values as is and unpause will continue where it left.

On Tue, 5 Jan 2021, 08:21 Cort, notifications@github.com wrote:

That is the behaviour in ev3dev. In a real ev3 running ev3dev, stopping the program does not automatically stop the robot. The motors are controlled by the OS. When the program is stopped, no new commands are sent to the OS, so the last command remains in effect. To stop the robot, an explicit stop command must be issued. Such behaviours isn't that uncommon where the high level code is sending commands to low level code that is running separately.

I think brickman issues a stop command when you stop a program through it, but I haven't played around with ev3dev in quite a while now (...and I usually run the program via ssh). Can anyone confirm?

Whether I should continue to follow the ev3dev behaviour is up for discussion. The surprise of having the motor continue running when the program stops is something that students may likely encounter sooner or later. With the current behaviour, it is "sooner", but perhaps "later" may be better.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/QuirkyCort/gears/issues/48#issuecomment-754453937, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABM6OC4IAJRQZ7SQQCD534LSYK4XNANCNFSM4VUJ3AFQ .

[humbug99]

Huh. That's different than I remember from EV3-G and MicroPython. Let me do some testing with ev3dev and a brick.

[QuirkyCort]

EV3-G automatically send a stop motor command when the program is terminated. By micropython, I assume you're referring to PyBricks. I've never used that before. The on-brick user interface (Brickman?) probably sends the stop command when it detects that the program ended.

[humbug99]

I did some testing with last year's robot, which was running the version of EV3 Micropython which was linked from the Lego Education website last year. It said "Brickman" (and also "EV3Dev") during the boot stage. I don't know what to call this, so will use the term "2019 EV3 Micropython/Brickman" until someone suggests something better.
On this platform, If you abort a program while it is running by pressing the Back button on the robot, the wheels come to a stop. It appeared to be a stop without a hard brake, but I'd have to do further testing to verify that.

I haven't yet tested the behavior with the current ev3dev2 + on-brick interface, but will do so.

Even just going off of the behavior of EV3-G and the 2019 EV3 Micropython/Brickman, the current simulator behavior seems confusing to me. There are two cases that I see: 1) Program code finishes while a motor command (move_tank, move_steering, ...) is active.
2) Program code is running with motor command active and user presses the simulator's stop button.

In both cases, it seems to me that the simulator should do what the robot platform being simulated would do. If there are different behaviors, I suggest that it should be possible to configure the simulator to act like a particular robot platform, something like

configure_simulator( platform ) , where platform is a string such as 'EV3-G', 'Brickman', 'Brickman-ssh', etc.

Then the code invoked by the simulator stop button can call different functions depending on the platform.

The idea of a Pause button is interesting, but I think that is a different feature.