ev3dev
Keyword argument brake in Motor.on() and Motor.off()
- ev3dev version: 4.14.59-ev3dev-2.2.2-rpi2
- ev3dev-lang-python version: python3-ev3dev 1.2.0
Methods Motor.on() and Motor.off() do have optional keyword argument brake. Default value is True. But when brake=True the motor won't stop with stop_action 'brake' but with stop_action 'hold'. That's a bit confusing (or a bug?).
In ev3dev-lang-python/ev3dev2/motor.py lines 890-894 it says:
def _set_brake(self, brake):
if brake:
self.stop_action = self.STOP_ACTION_HOLD
else:
self.stop_action = self.STOP_ACTION_COAST
Isn't it better to change it to:
def _set_brake(self, brake):
if brake:
self.stop_action = self.STOP_ACTION_BRAKE
else:
self.stop_action = self.STOP_ACTION_COAST
Or else, change keyword argument brake in hold.
It's called "brake" because A) that's the common word people will expect and B) that's the term EV3-G uses. If we expected people to frequently use the underlying brake mode I think this would be an issue, but in general hold is what people will be using. That being said, we could rename it if there's enough support for it.
Someone else expressed the same confusion to me recently, so you're not the only one to ask. What do others think? If we are going to rename it, we have to do it now.
What if in _set_brake we made the arg being passed “coast” and if that is false we set the stop action to HOLD? Seems like that would be a little less confusing
You're suggesting we could rename the brake parameter to coast (the inverse) in our public APIs? I like the change but I'm worried it might be too disruptive.
One thing odd with how we have done this is you can only specify 2 of the 3 possible settings. We could do something where if the arg passed in is one of the 3 possible stop_actions we set it, else we verify that the arg passed is a bool and act the way we do today. If the arg is not a valid stop_action and not a bool we raise an exception. Brainstorming...
A point of clarification: Are 'hold' and 'brake' the same thing? From this thread, it seems they are, but the documentation has a different description for 'hold' that makes it seem different from 'brake'.
My team have been trying to get their robot to keep a fixed position on a ramp (to prevent being pushed off). When they set the DriveMotors.off(brake=True), their 1.5kg robot will roll off the bridge and down the ramp if pushed sufficiently (FLL said seems to have said "To hell with coopertition" and gone full Robot Wars this season).
There are three options internally:
-
coastjust turn off power to the motor -
braketurn off power to the motor and actively hit the brakes but don't hold the brake down -
holdturn off power to the motor and actively hit the brakes AND hold the brake down so the motor cannot move
We really only expose coast and hold though, this is done via our brake arg to on() and off()
It sounds like you are doing the right thing...when you call DriverMotors.off(brake=True) pick the robot up and see if you can turn the motors easily with your hand? You shouldn't be able to.
@dwalton76 Works like a charm. 1.5kg robot doesn't slide back down the ramp.
My kids and I thank you for the help.
Worked like a charm. At the tournament, the robot made it up the ramp, but only partially due to a distance error...and stayed on the incline WITHOUT rolling backwards.
On Thu, Jan 16, 2020 at 11:37 AM Daniel Walton [email protected] wrote:
It sounds like you are doing the right thing...when you call DriverMotors.off(brake=True) pick the robot up and see if you can turn the motors easily with your hand? You shouldn't be able to.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ev3dev/ev3dev-lang-python/issues/503?email_source=notifications&email_token=AFBYYSSWSFQLKORC246TSKTQ6CELTA5CNFSM4FTWWBH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJEWVFI#issuecomment-575236757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBYYSQNVLHBKYV6SJT7RETQ6CELTANCNFSM4FTWWBHQ .