Skip to content

Commit

Permalink
Add feedback to Fallback Controllers
Browse files Browse the repository at this point in the history
  • Loading branch information
MarqRazz committed Nov 15, 2023
1 parent a4ebb7b commit c319932
Showing 1 changed file with 32 additions and 0 deletions.
32 changes: 32 additions & 0 deletions design_drafts/fallback_controllers.md
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?

---

### 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.

---

## 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?

---

``` 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.

---


### The `update()` method

Expand Down

0 comments on commit c319932

Please sign in to comment.