Nodes/VLM_nodes/VLA Action Safety Gate
ComfyUI Node Runs on cloud

VLA Action Safety Gate

The gate between 'the model wants to' and 'the robot actually does'

By gokayfem·Created 3 years ago·Updated 9 days ago· 583
VLA Action Safety Gate
  • actions
  • embodiment
  • safe_actions
  • safety_report
  • safe_for_handoff
modeBlock unsafe
execution_horizon8
previous_action_json

A VLA policy is a neural network that outputs numbers. Those numbers get really interesting the moment a robot arm executes them, which is why the pack puts a Safety Gate between the model and anything downstream. VLA Action Safety validates action chunks against your embodiment's contract - dimensions, finite values, bounds, per-step deltas, and execution horizon - and then does what you tell it to do about violations.

First, the disclaimer the node itself insists on: this is not a hardware safety controller. A real robot needs an independent deadman, watchdog, e-stop, collision limits, and command-freshness checks enforced by a controller you trust. This node validates that the numbers leaving your workflow are sane according to the declared profile. safe_for_handoff=true means the ComfyUI-side checks passed, nothing more. Read that as the pack drawing a bright line: the safety gate protects your pipeline from a bad model output, not your arm from physics.

The inputs: actions (a VLA_ACTIONS handle) and embodiment (the VLA_EMBODIMENT profile - this is why the profile is a typed socket and not a string; the gate needs the bounds). execution_horizon (default 8) caps how many steps get executed per chunk, and previous_action_json lets you feed the last executed action so the gate can also check that the new chunk starts from a continuous place.

The mode dropdown is where you decide the policy on violations:

  • Block unsafe - reject the chunk entirely
  • Clamp safely - push out-of-bounds values back within limits
  • Hold position on unsafe - freeze at the current state instead of executing
  • Report only - log violations and pass through anyway (for data collection)

Outputs are safe_actions (the validated/clamped VLA_ACTIONS), safety_report (a string explaining exactly what failed and what the gate did about it), and safe_for_handoff (a BOOLEAN - the flag your downstream controller bridge should gate on).

Installing it

In the main pack - ComfyUI Manager (search "ComfyUI VLM nodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI_VLM_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_VLM_nodes/requirements.txt

No robotics SDKs required - the gate is pure validation over the typed sockets.

Common issues

  • Everything gets blocked → your embodiment bounds are too tight for what the policy emits. max_delta_json is the usual suspect: if the policy outputs absolute positions and your profile caps per-step deltas, it'll never pass. Re-check units (radians vs degrees) and bounds against a real recorded trajectory.
  • safe_for_handoff is false and you don't know why → read safety_report. It's the whole point of the node - the report tells you the exact field and value that failed.
  • Clamp mode still yields wild motion → clamping values doesn't fix a dimension mismatch. If action_dim is wrong, clamp just squeezes garbage; fix the profile instead.
  • "It passed the gate and the robot still did something bad" → see the disclaimer above. The gate validates against your declared contract; if the contract itself is wrong (wrong limits, wrong action mode), no gate catches it. The pack says it plainly, and it's worth repeating.

The intended pattern: Policy node → Safety Gate → inspect/plot/record or your own supervised controller bridge. Never skip the gate for anything that might reach hardware, and treat its safe_for_handoff output as an input your real controller honors.

CategoryVLM Nodes/Robotics/Safety

Inputs (5)

NameTypeDefaultDescription
actionsVLA_ACTIONS
embodimentVLA_EMBODIMENT
modeCOMBOBlock unsafe4 options: Block unsafe, Clamp safely, Hold position on unsafe, Report only
execution_horizonINT81–4096
previous_action_jsonSTRING

Outputs (3)

NameTypeDescription
safe_actionsVLA_ACTIONS
safety_reportSTRING
safe_for_handoffBOOLEAN