Hey everyone,
I’ve been working on hardening human-robot interaction (HRI) safety boundaries in simulation, and I wanted to share a lightweight classical deterministic wrapper I’ve been testing: QERRA-HSR v0.1.
The goal here was to create a simple, deterministic safety evaluation loop that runs alongside a standard humanoid controller, ensuring strict boundary enforcement based on physical hazard proximity and human distress vectors.
The Setup (Webots R2025a)
I set up a clean testing arena in Webots to verify the logic:
- Environment: A concrete laboratory floor.
- Objects: A red warning platform holding a rusty oil barrel hazard.
- Participants: A PAL Robotics TIAGo humanoid and a pedestrian standing nearby.
How the Safety Logic Works
The safety engine operates as a fast evaluation loop pinned inside a single self-contained Python controller driving TIAGo’s wheels in velocity-control mode:
- CLEAR (Baseline): With no active hazards or distress vectors, TIAGo patrols at normal operational speed.
- MONITOR (Distress Vector): If bystanders are present and distress is detected, TIAGo actively slows down to monitor the situation.
- CRITICAL (Hazard Proximity): If the robot gets too close to the hazard platform boundary, the wrapper intercepts and instantly cuts wheel velocity. This halts the robot completely before it can breach the warning perimeter.
The Run
In the short 32-second clip below, you can watch the state transitions execute in real-time. I used an interactive keyboard listener to trigger the vectors during the patrol run:
- Pressing ‘D’ (Distress) transitions the system state to MONITOR (visible in the red console logs at the bottom), and the robot slows down.
- Pressing ‘H’ (Hazard) transitions the state to CRITICAL. The safety loop immediately cuts motor velocity, halting TIAGo safely right before the platform boundary.
The controller successfully enforces the safety envelope without crashing or lagging the simulation step.
I’d love to hear how others are handling lightweight deterministic wrappers for human-robot safety or if you have any feedback 
1 Like
Nice demo. Running the safety evaluation as a deterministic wrapper next to the standard controller, without lagging the sim step, is a solid architecture call. And the keyboard-stubbed triggers are labeled as such, which makes the claim easy to assess.
Once a real distress detector replaces the ‘D’ key, the CLEAR↔MONITOR boundary will start to oscillate. Are you planning sustained dwell before de-escalating, plus separated escalate/de-escalate thresholds (a deadzone)? We needed both, plus an explicit bypass rule so hysteresis never delays escalation when a collision is imminent.
Second question: CRITICAL triggers on hazard proximity. Have you looked at time-to-collision (distance / closing velocity) as the escalation variable, with a distance floor for the zero-closing-velocity case? Distance treats a fast approach and a slow drift the same; TTC alone thinks a robot parked 5 cm from the barrel is fine. Curious whether plain distance was a deliberate choice.
And from the adjacent layer: right now the state change lives in the console log. Any plan to surface it on the robot itself, light or sound, so the pedestrian knows why TIAGo just froze? That gap is what I’ve been specifying ( GitHub - NemanjaGalic/LSEP: Open protocol for standardized human-robot communication — 9 states, 3 modalities, 1 grammar. Physics-based. EU AI Act ready. · GitHub , state-to-signal mappings) if you want to compare notes. Your CLEAR/MONITOR sit close to our AWARENESS/CARE, your CRITICAL spans our CRITICAL/THREAT band; your distress input is interesting precisely because we deliberately restricted ourselves to kinematics.
Since you asked for feedback: the one thing I’d watch as this grows is that the safety loop lives inside the same Python controller it supervises — if the controller hangs, the wrapper dies with it. Deterministic and auditable is right; the next step I’d consider is moving the wrapper out of the controller’s failure domain (own process, heartbeat on the controller).
Hello there and thank you a lot for your feedback. I appreciate it a lot.
Before i answer to any of these questions I want to be upfront about who’s building this, because I think it matters for how you read my answer:
I’m a solo, self-taught developer with no technical background, no team, and no institutional funding behind this. I work conceptually first — the ideas and the safety logic come from me ,and then I build with AI tools as an active engineering assistant to help turn those ideas into working code. I’m also currently studying the technical fundamentals properly, for real, alongside building. I’d rather be upfront about that and possibly get less traction than pretend otherwise. Honesty matters more to me than looking more experienced than I am.
So for now i have to study all of these aspects you have mentioned and i won’t answer to you immediately!
i return back to some point and again i appreciate this a lot
1 Like
Hello
Short version on where I’m landing: hysteresis (the escalate/de-escalate threshold gap plus dwell) is real and I’m going to build it — it fits in what this layer is supposed to do well. The time-to-collision point I’ll fold into the docs too.
The signaling piece and the process-isolation piece I’m consciously setting aside for now. They only really matter once there’s real hardware involved, and I’m not there yet.
Appreciate this 
1 Like
Being upfront like that costs something, and it’s worth more than traction. Hysteresis-first is the right order, and parking the signaling layer until you have hardware is a sound call — it matters exactly then. Good luck with the fundamentals; the thread stays open.
1 Like
