Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Feedback for Fallback Controllers #60

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Feedback for Fallback Controllers #60

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions design_drafts/fallback_controllers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,25 @@ Right now, we don't have a way to manage controllers when they fail to perform t
### Example 1
A walking controller for a humanoid is also responsible for maintaining the balance of the robot along with footstep execution, however, there might be cases where the robot might fall after a few steps due to miscalibration or due to flexibility in some joints or it could be a different reason. In this case, we might want the robot to go to a safe position and be compliant enough for the impact, if not it might damage some joints or sensors onboard.

---

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?

Comment on lines +12 to +14
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

---

### Example 2
A mobile manipulator is performing a trajectory hits an obstacle and continues to apply force. In this case, we might want to switch to be more compliant mode, so that it doesn't damage the robot's joints.

---

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.
Comment on lines +22 to +25
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


---

## Current implementation

The current implementation fetches the return type from the current controller update cycle and then decides the return type status of the controller_manager's update cycle.
Expand Down Expand Up @@ -50,6 +66,13 @@ controller_manager:
fallback_controllers: ["joint1_position_controller", "joint2_position_controller"]
```

---

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?

Comment on lines +70 to +73
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

---

``` c++
struct ControllerInfo
{
Expand All @@ -76,6 +99,15 @@ When trying to activate the controller with fallback controllers, the following

If any of the above checks fail, then activation of the primary controller fails. The user will always be able to run the primary controller without configuring the fallback controller.

---

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.
Comment on lines +104 to +107
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


---


### The `update()` method

Expand Down
Loading