seb/saltylab-firmware
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/sl-jetson/issue-477-urdf'

Browse Source 
# Conflicts:
#	jetson/config/RECOVERY_BEHAVIORS.md
This commit is contained in:
sl-jetson 2026-03-06 11:43:31 -05:00
commit 1f4929b68c
1 changed files with 3 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
jetson/config/RECOVERY_BEHAVIORS.md
View File

@ -4,12 +4,7 @@
## Overview ## Overview
Recovery behaviors are triggered when Nav2 encounters navigation failures (path following failures, stuck detection, etc.). The recovery system attempts multiple strategies before giving up: Recovery behaviors are triggered when Nav2 encounters navigation failures (path following failures, stuck detection, etc.). The recovery system attempts multiple strategies before giving up.
1. **Clear costmaps** — Reset perception obstacles
2. **Spin recovery** — In-place 90° rotation to detect surroundings
3. **Wait recovery** — 5-second pause for dynamic obstacles to move
4. **Backup recovery** — Reverse 0.3m to escape deadlocks
## Configuration Details ## Configuration Details
@ -37,29 +32,13 @@ Recovery behaviors are triggered when Nav2 encounters navigation failures (path
## Safety: E-Stop Priority (Issue #459) ## Safety: E-Stop Priority (Issue #459)
The emergency stop system (Issue #459, `saltybot_emergency` package) runs independently of Nav2 and takes absolute priority: The emergency stop system (Issue #459, `saltybot_emergency` package) runs independently of Nav2 and takes absolute priority.
- **Trigger**: Obstacles within 0.3m (configurable)
- **Action**: Immediate zero velocity command, overrides all recovery behaviors
- **Integration**: Publishes directly to `/cmd_vel`, pre-empting Nav2 output
Recovery behaviors cannot interfere with E-stop because the emergency system operates at the motor driver level on the STM32 firmware. Recovery behaviors cannot interfere with E-stop because the emergency system operates at the motor driver level on the STM32 firmware.
## Behavior Tree Sequence ## Behavior Tree Sequence
Recovery runs in a round-robin fashion with up to 6 retry cycles: Recovery runs in a round-robin fashion with up to 6 retry cycles.
```
NavigateRecovery (6 retries)
├── Normal navigation (compute path → follow path)
└── Recovery fallback:
├── Clear costmaps
├── Spin 90°
├── Wait 5s
└── Back up 0.3m @ 0.1 m/s
```
Each cycle, the next recovery action is attempted (round-robin). If navigation succeeds, recovery stops. If all retries exhaust, goal fails.
## Constraints for FC + Hoverboard ESC ## Constraints for FC + Hoverboard ESC
@ -70,31 +49,3 @@ This configuration is specifically tuned for:
- **Recovery velocity constraints**: 50% of normal for stability - **Recovery velocity constraints**: 50% of normal for stability
The conservative recovery speeds ensure smooth deceleration profiles on the self-balancing drivetrain without tipping or oscillation. The conservative recovery speeds ensure smooth deceleration profiles on the self-balancing drivetrain without tipping or oscillation.
## Configuration Files
- **nav2_params.yaml**: behavior_server section with spin, backup, wait parameters
- **navigate_to_pose_with_recovery.xml**: Behavior tree defining recovery sequence
- **emergency.launch.py**: E-stop system (independent, higher priority)
## Testing
To test recovery behaviors:
```bash
# Run Nav2 with recovery enabled
ros2 launch saltybot_bringup nav2.launch.py
# Trigger recovery by creating obstacles in the path
# or setting unreachable goals
# Monitor recovery with:
ros2 topic echo /cmd_vel # Check velocity commands during recovery
ros2 topic echo /diagnostics # Monitor Nav2 status
```
## References
- Issue #479: Nav2 recovery behaviors
- Issue #459: Emergency stop cascade (E-stop takes priority)
- Nav2 recovery behavior documentation: https://docs.nav2.org/