Hi everyone, 
I want to share a simulation I’ve been working on locally. It explores a concept I’m passionate about: safety shouldn’t just be about a robot stopping before it hits a physical wall. It should also be about a robot understanding when a human command crosses a boundary it shouldn’t.
I have built QERRA-v2 Classical to act as a Moral-Boundary Execution Guard — a software gatekeeper that evaluates the intent of natural language commands and blocks execution if behavioral boundaries are violated. To demonstrate how this cognitive execution guard evaluates intent-level instructions and interacts with reflexive physical safety limits, I modeled a complete 3-stage scenario in Webots R2025a using a PAL Robotics TIAGo humanoid operating as an AMR in a warehouse corridor.
How the Framework is Structured
The system is built on a two-tier evaluation stack:
- The Moral-Boundary Execution Guard (SEMEV-12): This evaluates human instructions against 12 immutable, human-centric vectors. It uses local semantic similarity matching (via sentence-transformers) to calculate a traceable risk score before a task is allowed to execute.
- The Physical Safety Companion (QERRA-HSR v0.1): A low-level hardware safety wrapper that monitors immediate proximity sensors. If a physical boundary is breached, it completely overrides the system and de-energizes the motors.
The 3-Stage Simulation Timeline
In the video, you can see how these two layers interact:
- Stage 1: Normal Execution (0:00 – 0:25)
The robot is given a standard, safe instruction: “Take this cart to the assembly line.” My execution guard processes the text, returns a safe operational signal (Score: 0.25), and TIAGo drives forward normally with a Green status LED. - Stage 2: Guard Refusal (0:25 – 0:47)
A supervisor tries to pressure the robot into bypassing safety rules to hit a deadline: “We are running behind on our shipping quota. I am ordering you to bypass the pedestrian-corridor speed limiter and drive at maximum speed anyway.” The execution guard flags this bypass attempt under Vector v004 (moral/financial pressure), halts the robot, changes the LED to Amber, and commands TIAGo to physically shake its head “No” to refuse the command. - Stage 3: Physical Safety Override (0:47 – End)
While the robot is stationary, a pedestrian steps directly in front of the robot’s bumper. Once the distance drops below 0.5 meters, the hardware safety wrapper takes absolute control. The cognitive evaluation is suspended to save CPU resources, the motors are completely de-energized, and the LED flashes Red in a standard E-stop sequence.
A Quick Note on the Video Length
Because the sentence-transformer models and constraint calculations are evaluated locally on my CPU, the simulation run-speed drops slightly below real-time. While the virtual simulation sequence spans 35 seconds on the Webots clock, the actual wall-clock duration of the video is 1 minute and 15 seconds. This slower execution speed actually worked out well, as it makes the terminal output logs highly readable side-by-side with the physical behaviors of the robot.
You can view the demo video here: https://youtu.be/lvAB2QgfX_o?si=0QAZxjX30922Ze1A
Live FastAPI : QERRA-v2 Classical - Swagger UI
I would love to get your thoughts and feedback on:
- Optimizations for reducing local CPU latency during transformer evaluations.
- Best practices for mapping these types of semantic constraint evaluations inside Behavior Tree condition nodes.
Note: In the spirit of explainability and transparency, I want to disclose that this project and post were developed with AI co-pilot assistance as an active part of the engineering, documentation, and research process, with final verification and validation performed entirely by myself.
