-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Change definition of stalled #1069
Comments
Instead of changing the definition, can we just add a new I think an overload condition is also useful for discovering that you are trying to run at a speed that the motor is not physically capable of. |
Part of this is getting mixed in with pybricks/pybricks-micropython#166 to make some progress. I need to pull out the motor servo stuff, then rebase that PR. |
Yes, as mentioned something like I'm wondering if it is acceptable to deprecate Although pbio-derivatives will probably want to keep |
This is an alternate way to use temporary limits in pbio (no nlr buf) but without a breaking change in the definition of duty limit or stall. See pybricks/support#1069
This is an alternate way to use temporary limits in pbio (no nlr buf) but without a breaking change in the definition of duty limit or stall. See pybricks/support#1069
This is an alternate way to use temporary limits in pbio (no nlr buf) but without a breaking change in the definition of duty limit or stall. See pybricks/support#1069
This is an alternate way to use temporary limits in pbio (no nlr buf) but without a breaking change in the definition of duty limit or stall. See pybricks/support#1069
Maybe not 100% on this item, but as a simple user I would expect True as the result of Currently running this on
which shows:
|
By default, If you change it to |
It does not. |
Current implementation
Currently stalled is true if:
Suggested improvement: Drop condition 2
Stall detection is mostly used to detect over load in order to stop. We don't need to wait until we are physically stopped to test this.
Doing this makes the stall detection more sensitive, and it makes
run_until_stalled
work better. We can use a configurable torque limit (test 1 above) instead of a duty limit. This means you can run at any speed and still safely detect soft endpoints. Withduty_limit
today, this doesn't work because capping it at say 30% means you can't run fast.I think it is still consistent with our current definition:
Drawbacks
Maybe this is no longer called "stalled" this way, since it may not be fully stopped?
It would also raise the
stall
flag way sooner when running very fast. This is not technically an issue since all other maneuvers don't look at this flag but it is a bit odd.Maybe
loaded
is a better term. Not sure if we need both though.The text was updated successfully, but these errors were encountered: