Runtime Services

ros2_fault_injection exposes runtime services under the /fault_injection namespace.

Use these services to list faults, inspect state, read current config values, activate or deactivate faults, update config values, and reload the scenario file without restarting the node.

List Faults

Service:

/fault_injection/list_faults

Type:

ros2_fault_injection/srv/ListFaults

Request:

---

Response:

string[] fault_ids
string[] active_fault_ids

Example:

ros2 service call /fault_injection/list_faults ros2_fault_injection/srv/ListFaults {}

Use this when you only need the known fault IDs and which of those are currently active.

Get Fault Status

Service:

/fault_injection/get_fault_status

Type:

ros2_fault_injection/srv/GetFaultStatus

Request:

---

Response:

ros2_fault_injection/FaultStatus[] faults

Each FaultStatus contains:

string fault_id
string injector_id
string state
string details

Example:

ros2 service call /fault_injection/get_fault_status ros2_fault_injection/srv/GetFaultStatus {}

Example response:

faults:
- fault_id: odom_bias
  injector_id: odom
  state: inactive
  details: "scheduled, start=5000ms, duration=10000ms, config={x_bias=1.0}"

Use this for UI panels, debugging, and logs where the injector ID and human-readable fault details matter.

Set Fault State

Service:

/fault_injection/set_fault_state

Type:

ros2_fault_injection/srv/SetFaultState

Request:

string fault_id
bool active
---

Response:

bool success
string message

Activate a fault:

ros2 service call /fault_injection/set_fault_state ros2_fault_injection/srv/SetFaultState \
  "{fault_id: odom_bias, active: true}"

Deactivate a fault:

ros2 service call /fault_injection/set_fault_state ros2_fault_injection/srv/SetFaultState \
  "{fault_id: odom_bias, active: false}"

Successful calls publish a FaultEvent with state set to active or inactive and source set to manual.

Get Fault Config Schema

Service:

/fault_injection/get_fault_schema

Type:

ros2_fault_injection/srv/GetFaultSchema

Request:

string fault_id
---

Response:

bool success
string message
string injector_id
string injector_type
string[] keys

Example:

ros2 service call /fault_injection/get_fault_schema ros2_fault_injection/srv/GetFaultSchema \
  "{fault_id: odom_bias}"

Use this service when a UI or script needs to discover which config keys are valid for a fault before sending a runtime update.

Get Fault Config

Service:

/fault_injection/get_fault_config

Type:

ros2_fault_injection/srv/GetFaultConfig

Request:

string fault_id
---

Response:

bool success
string message
string injector_id
string injector_type
string[] keys
string[] values

Example:

ros2 service call /fault_injection/get_fault_config ros2_fault_injection/srv/GetFaultConfig \
  "{fault_id: odom_bias}"

Example response:

success: true
message: retrieved config for fault_id: odom_bias
injector_id: odom
injector_type: odom
keys:
- drop_probability
- x_bias
values:
- '0.0'
- '1.0'

keys and values are parallel arrays because ROS 2 service definitions do not support map fields directly. Use this service when a UI or script needs the current runtime value for a fault config key.

Set Fault Config

Service:

/fault_injection/set_fault_config

Type:

ros2_fault_injection/srv/SetFaultConfig

Request:

string fault_id
string key
string value
---

Response:

bool success
string message

Example:

ros2 service call /fault_injection/set_fault_config ros2_fault_injection/srv/SetFaultConfig \
  "{fault_id: odom_bias, key: x_bias, value: '2.0'}"

This changes one entry in the fault’s config map while the node is running.

Only keys and values valid for that injector type are accepted. For example, x_bias is valid for an odom injector, while range_bias is valid for a scan injector. Numeric fields, probabilities, booleans, and non-negative values are validated before the stored config changes.

This service does not change top-level scheduling fields such as start, duration, active_on_startup, id, or injector_id.

Successful calls publish a FaultEvent with state set to config_updated and source set to manual.

Reload Scenario

Service:

/fault_injection/reload_scenario

Type:

ros2_fault_injection/srv/ReloadScenario

Request:

---

Response:

bool success
string message

Example:

ros2 service call /fault_injection/reload_scenario ros2_fault_injection/srv/ReloadScenario {}

Reloads the same scenario file that was passed to fault_injector.launch.py.

Reload can update fault definitions, config values, startup state, and schedules for existing injectors.

Reload cannot change:

  • injector IDs

  • injector types

  • topic input/output endpoints

  • trigger service proxy/target endpoints

  • QoS depth

  • the number of configured injectors

If validation or compatibility checks fail, the currently running scenario remains unchanged.

Fault Events

Topic:

/fault_injection/events

Type:

ros2_fault_injection/msg/FaultEvent

Message:

builtin_interfaces/Time stamp
string fault_id
string injector_id
string state
string source
string details

Example:

ros2 topic echo /fault_injection/events

Events are published when scheduled faults activate or deactivate and when faults are changed through the service API.

Common event states:

State

Meaning

active

Fault became active.

inactive

Fault became inactive.

config_updated

A runtime config value changed.

Common event sources:

Source

Meaning

startup

Fault was activated during scenario startup.

scheduled

Fault changed because of a scheduled start or stop.

manual

Fault changed because of a service call.

Assertion Events

Topic:

/fault_injection/assertion_events

Type:

ros2_fault_injection/msg/AssertionEvent

Message:

builtin_interfaces/Time stamp
string assertion_id
string assertion_type
string state
string message

Example:

ros2 topic echo /fault_injection/assertion_events

Assertion events are published by the assertion runner when an assertion changes from pending to a terminal state.

Common assertion states:

State

Meaning

passed

The expected scenario outcome was observed.

failed

The expected scenario outcome was not observed before its deadline, or otherwise failed.

For a fault_event assertion, assertion_type is fault_event, and the message describes the expected fault ID and state.