-
Notifications
You must be signed in to change notification settings - Fork 371
Deactivate the controller chain upon failed group activation #2669
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
Deactivate the controller chain upon failed group activation #2669
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #2669 +/- ##
==========================================
+ Coverage 89.40% 89.46% +0.05%
==========================================
Files 152 152
Lines 17223 17320 +97
Branches 1432 1434 +2
==========================================
+ Hits 15399 15496 +97
- Misses 1244 1246 +2
+ Partials 580 578 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
(cherry picked from commit a2e56e4)
(cherry picked from commit a2e56e4)
We had an issue recently that one of the upper-level torque reference provider controllers failed to activate, and this has caused the other controllers in the chain to have an invalid zero reference to tracking and which closely destroyed our robot. For this reason, I'm proposing this behaviour, while using
BEST_EFFORTstrictness, it should be similar to the current approach and however, with theSTRICTstrictness, if one of them fails to activate, then just deactivate all of the group.I'll need to handle the same situation when it happens in the
updatecycle, that I'll do it in a different PR