EV3-G API: motors

[dwalton76]

[ddemidov]

We could merge various on_for_* methods into

m.on_for(rotations=3, brake=True)
m.on_for(degrees=45, power=75)
m.on_for(seconds=1)

Here on_for could be defined as

def m.on_for(rotations=None, degrees=None, seconds=None, **kwargs):
  # set attributes from kwargs
  ...
  if rotations is not None:
    ...
  elif degrees is not None:
    ...

[dwalton76]

Does EV3-G not provide a way to specify STOP_ACTION_HOLD when using their Motor, MoveTank, MoveSteering blocks? It doesn't look like they do which seems a little odd.

I am trying to get EV3-G running via wine so that I can check for this kind of stuff but no luck yet

[ddemidov]

I think hold is ev3dev specific.

[dlech]

brake is ev3dev-specific. hold in ev3dev == Brake in EV3-G.

http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-stretch/motors.html#sysfs

[laurensvalk]

I came across this thread after being tagged in something so hopefully I'm not taking this too far off topic...

Quoting from the table for the yellow blocks:

current_power = m.measure_current_power()

I understand the idea here is to obtain functionality close to EV3-G, and I could live with power and speed being used interchangeably for the green blocks, but this one is quite exceptional.

Measuring "current power" in EV3-G gives you the speed (no relation to current or power at all).

The wording is kind of justifiable in English (current = instantaneous), but if you'd install the German version of EV3-G, you'd literally see "Measure electrical current" (But it still gives you the speed 😄)

---

tldr; Keep the picture in the table as is, but maybe just write: speed = m.measure_speed()

[dlech]

Totally on topic. The tables show word-for-word in Python, what the EV3-G blocks says just for clarity. The idea is that in the actual implementation, they get cleaned up where appropriate.

[dwalton76]

If default is hold and the user ctrl-C their program we will leave the motor with power being applied to hold it in place. Thoughts on how we can gracefully set the stop_action to coast when the program exits (without the user coding this into their program)? We could add a __del__ to the Motor class that does this but from googling folks think that implementing a __del__ in python is a horrible sin.

[dlech]

That is why you run your program with brickrun, it stops motors, sound, etc.

__del__ is for releasing unmanaged resources, like file handles, when an object is garbage collected. There is no guarantee when or even if an object is garbage collected, so it cannot be relied upon for anything that must happen.

[dwalton76]

Does brickman set the stop_action to coast? If so that sounds good to me. I

[dlech]

brickrun totally resets the motor, including removing power (setting to to coast)

[dwalton76]

For all of these on_for_XYZ() functions do we want the power that we pass it to be a percentage of max_speed from -100% to 100% or do we want this to be the actual speed_sp? Make take is they should be a percentage from -100 to 100 but we need to reach a consensus on this.

[WasabiFan]

On one hand, we could switch to our own scientific units; it would make the behavior of "speed" better-defined than if it were a percentage, but that requires documentation and it's easy to miss. On the other hand, using percentages would make the interface dramatically more intuitive for a typical user.

I think it comes down to this question: can we adequately document the special behavior? Where would we put the info?