AffectGuard-HRI: emotion-aware robot behavior with a non-overridable safety envelope (ROS 2 Jazzy, pet-project)

Projects
1

Hi all,

I’ve been building AffectGuard-HRI, a pet-project framework on ROS 2 Jazzy for social/home robots that adapt their behavior to a person’s detected emotional state — while keeping a hard safety envelope between “what the robot perceives” and “what it’s actually allowed to do.”

Repo: GitHub - oleg-vdv/affectguard-hri · GitHub

The idea was to build three things together, not in isolation:

  • Multi-modal affect perception — separate video (FER+ ONNX) and audio (MFCC + ONNX) emotion nodes, fused with a confidence-weighted rule into fused_emotion_state.
  • A policy engine whose safety envelope can’t be overridden — the rule engine proposes a movement/voice/face command, but every command is unconditionally clamped by an immutable envelope (max speed, and “no movement during a task flagged critical”) before it reaches actuation. There is no code path that skips it, and it’s covered by a unit test that feeds it an extreme/adversarial input.
  • Security-first handling of biometric data — an SROS2 access-control policy where perception enclaves have no permission entry for the actuation topics at all (perception can’t reach /cmd_vel even if compromised), plus structured JSON audit logging of every state transition, and a threat model covering three attacks.

It runs end-to-end in Gazebo on a turtlebot3, verified live on a headless server (there’s a demo GIF in the README showing speed drop 0.15 → 0.045 on “anger”, then → 0.0 under a critical task).

Honest scope / what’s not done: it’s a pet-project. Emotion models aren’t bundled (the nodes refuse to start without a real .onnx path, by design). The SROS2 policy builds and the topic isolation is structural, but I haven’t yet exercised the full DDS-Security handshake on real hardware. No physical robot port beyond a pluggable driver template.

I’d genuinely appreciate feedback on two things: (1) the safety-envelope approach — is “rules propose, envelope disposes” a sane pattern, or are there sharper ways people do this? (2) the SROS2 policy — anyone with production DDS-Security experience spot gaps in the enclave layout?

Architecture, ADRs, and threat model are all in docs/. Thanks for reading.

1 Like