Fault Resilience

Fault Resilience

High-fidelity health monitoring and driver alerting systems.

On Einstein or at the Championship level, a single wire coming loose can lose a match. MARSLib approaches this challenge with a focus on Innovation and Safety. Our military-grade Two-Layer Fault System is designed to detect failures through Discovery, protect our hardware investment, and ensure that our technical Impact is never compromised due to a single-point failure.

1 The Two-Layer structure

Fault monitoring is split into two distinct responsibilities to ensure zero-latency detection:

Caution

Layer 1: IO-Level Health

This layer lives inside the Hardware Wrapper (e.g., ArmIOKraken). It monitors the lowest level sensor data for “Red Flags”:

• CAN Timeouts: Detecting disconnected motors or CANivore buses.

• Current Spikes: Detecting stalled mechanisms or carpet snags.

• Stale Data: Detecting encoder/IMU disconnects.

Layer 2: User-Facing Alerts

This layer propagates errors to the human team. Active faults are configured using persistent Alert objects and broadcast directly to AdvantageScope or the Driver Station.

2 The Alert System

Instead of relying on easy-to-miss System.out.println statements or generic SmartDashboard booleans, MARSLib uses the Alert class to trigger specific warnings that light up uniquely defined UI widgets.

// Persistent alert declared in a Subsystem
private final Alert m_stallAlert = new Alert("Arm Motor Stalled!", AlertType.ERROR);

@Override
public void periodic() {
    // Logic to detect a stall using IO inputs
    boolean isStalled = inputs.currentAmps > 40.0 && Math.abs(inputs.velocityRadPerSec) < 0.1;
    m_stallAlert.set(isStalled);
}

3 Transparent Structural Fallbacks

Alerting the driver is step 1. But what if the robot needs to keep moving? Because MARSLib strictly defines the IO Layer using a unified Struct data model, we achieve a massive structural advantage: Resiliency.

If a CAN bus wire snaps in the middle of a match—or a Kraken motor spontaneously reboots—the IO layer can catch the CANStatus exception and seamlessly redirect the Inputs struct to read from the internal Physics engine fallback. The Subsystem logic never even knows the hardware failed! It continues calculating the target state organically using mathematical models while broadcasting the fault alert concurrently.

Try clicking SEVER CAN WIRE below to see the math fallback gracefully handle the outage without zeroing out the reported velocity! Notice that the software continues simulating the mechanism’s positional state even when the actual hardware is coasting to a stop.

4 Pre-Match Diagnostics

MARSLib includes MARSDiagnostics, which standardizes running “Sweep Tests” of all registered mechanisms in the pits. It stresses the arm, drives the chassis 10cm, and spins the intake at 10% power to verify that no cables were loosened during transport.

Note

Safety Shutdowns

If a critical error is detected during diagnostic scans (like an over-current spike), MARSLib’s high-level fault controllers will automatically block enabling or scale back voltage limits to prevent permanent motor burnout on the field.

---

📖 Further Reading & External Resources

• WPILib: RoboRIO Brownout Protection - Understanding how hardware handles low voltage.

• CTRE: Phoenix 6 Actuator Limits - Implementing hardware-level current and voltage clamping.