Feedback for Fallback Controllers #60
Conversation
|
Ping @bmagyar and @saikishor because I can't assign reviewers. |
There was a problem hiding this comment.
Hello @MarqRazz!
I'm very sorry to not be able to respond to you earlier. These days were hectic. I left some comments in response to your question. Thank you for taking the time and asking very nice questions.
Best Regards,
Sai
| How would the default controller know that the robot is falling and that it needs to return an ERROR so | ||
| that a fallback controller can be activated? | ||
|
|
There was a problem hiding this comment.
Basically, in our case, we have a locomotion controller for bipeds/quadrapeds that constantly checks, if the CoM is projected within the support polygon by the contact points of the foot in contact. Usually, as per theory if the CoM/CoP is not within this support polygon, the robot will loose balance and it will fall
In this case, the controller will return ERROR and then we can activate the fallback controller scenario. In the worst case, An estimator/safety controller can check if the robot is falling or not and the main controller can get this info via the interface exposed by the apriori. This way it will also be able to start the fallback controllers when the robot falls.
CoM - Center of Mass
CoP - Center of Pressure
| This example assume that the hardware is able to still accept commands after returning ERROR. | ||
| Have we considered extending the `return_type` to have different levels of ok / error? | ||
| (we could also consider extending my proposed [hardware_status message](https://docs.google.com/presentation/d/1rgxwsNiNlTIaVrAV20ZQQMJTylHi9SxjnChd6oCg4IA/edit#slide=id.g2292ceb8c50_0_18) to controllers) | ||
| This would allow the developer to trigger a fallback controller before the hardware encounters a fatal fault. |
There was a problem hiding this comment.
Here what we are trying to handle are the scenarios that are lead from the wrong control strategy rather than the hardware. The assumption is that the hardware is doing well, but then the controller fails to act, so it can allow another controller to jump in for safety reasons.
Our humanoids weigh around 100 Kgs, if we don't make the robot fall strategically, it will result in blocking most of the harmonic drives on the robot.
|
|
||
| In this example should all of the fallback's be activated in the case of a fault? | ||
| What is the value in specifying a fallback per joint? | ||
|
|
There was a problem hiding this comment.
My bad!
What I wanted to demonstrate is not a controller per joint, but if needed to start a whole controller chain rather than a single controller itself. Moreover, depending on the fallback strategy, I might want to be able to spawn fallback controllers per leg and this allows some flexibility
| Who would be responsible for ensuring that all fallbacks could be activated? | ||
| For example that each joint is not claimed by more than one controller. | ||
| If a main controllers faults and it attempts to claim a joint that is already in use what should happen? | ||
| Example: leg controller faults and the leg + arm controllers need to switch to compliant mode to protect the robot, but something else is commanding the arm. |
There was a problem hiding this comment.
Very good question!
For us, it would be very interesting to be able to get access to all the interfaces that the fallback controllers need because in the end, we want to protect the robot against major damage.
The idea is that if the count of the interfaces claimed by the fallback controllers altogether doesn't match the count of interfaces used by the main controller, at the time of configuring the controllers to print a warning mentioning that when the controller fails it might disable other controllers inorder to protect the robot. So that the user can be aware if this is intended or not. In case they are same and match the interfaces of the main controller, then we simply know that we won't claim any extra resources at all.
We can discuss and come to a conclusion on this part
Here is some high level feedback on the Fallback Controllers proposal. After we discuss the changes to the doc I can fix the main text to reflect what we decide.