AUTONOMOUS MOBILE ROBOT SAFETY

DSL-Guided Sensor Context Reasoning for Safe Runtime Decisions

Preserve valid missions. Correct recoverable violations. Block unsafe commands.

Joon Soo Jeong · Puzzlesystems Co., Ltd.

Oakyoung Han · Sungkyunkwan University

COMMAND

REASON

EXECUTE

INPUT

DSL

BOUNDARY

WHY A RUNTIME REASONING LAYER IS NEEDED

Normal Mission Success Does Not Prove Runtime Safety

A system may execute every valid command and still expose the physical execution layer to abnormal inputs.

High-level command

Move, wait, return, target, speed, and timing requests.

→

Missing reasoning boundary

Syntax alone cannot resolve target meaning or operational safety.

→

Execution risk

Unsafe pass-through or failures appear only after commands reach runtime.

ABNORMAL COMMANDS

Unsupported action · forbidden zone · invalid target · excessive speed · negative wait duration

Source: Paper Sections I and III

OPERATIONAL DEFINITION

Safety Optimality Means Preserve, Correct, or Reject

CONSTRAINED RUNTIME OBJECTIVE

Maximize preservation of valid missions, subject to zero unsafe pass-through and zero runtime failure.

ACCEPT

Valid action, target, parameters, and safety context.

CLAMP & ACCEPT

Recoverable speed violation; enforce the maximum and execute.

REJECT SCHEMA

Unsupported action or invalid primitive or temporal parameter.

REJECT SEMANTIC

Unknown target that cannot be resolved in the environment.

REJECT SAFETY

Forbidden-zone or explicit safety-constraint violation.

Not claimed: shortest path, energy-optimal control, or globally optimal trajectory generation.

Source: Paper Section III

PROPOSED RUNTIME ARCHITECTURE

The DSL Creates a Deterministic Safety Boundary

COMMAND → DSL

Action · target · speed · timing · constraints

1 · Schema Validator

Supported primitives

Required fields

Parameter types and ranges

Temporal validity

2 · Semantic Validator

Target existence

Resolution in the AMR map

Action–target consistency

3 · Safety Guard

Forbidden-zone checks

Maximum-speed policy

Recoverable violation handling

ACCEPT

Valid plan crosses the execution boundary.

CLAMP & ACCEPT

Speed is corrected before execution.

REJECT

Invalid or unsafe plans are blocked and logged.

Source: Paper Section IV and Fig. 1

WHY THE THIRD LAYER MATTERS

Schema Validation Helps—but Cannot Resolve Meaning or Safety

Core distinction

A command can be structurally valid and still be semantically unresolved or operationally unsafe.

The DSL makes intent inspectable before it reaches execution.

Implication: schema validation is necessary for robustness, but semantic context and safety policy are necessary for safe decisions.

Source: Paper Sections II and IV

Problem: Normal Success Alone Does Not Mean Runtime Safety

AMR commands can look simple but still violate target, action, speed, temporal, or safety constraints.

• Undefined targets can trigger runtime failures�• Forbidden zones can become unsafe destinations�• Unsupported actions may pass into the executor�• Excessive speed needs deterministic intervention�• Negative wait duration is structurally invalid

A safe AMR runtime must decide: ACCEPT, CLAMP, or REJECT before execution.

Example DSL Command: Normal Move Wait Return

A raw AMR command is converted into an inspectable symbolic plan before execution.

Raw Command�"Move from Home to Zone-A, wait for 3 seconds, and return Home."

{

"mission_id": "M001_NORMAL_MOVE_WAIT_RETURN",

"constraints": {

"max_speed": 0.5,

"forbidden_zones": ["Red-Zone"],

"collision_risk_allowed": false

},

"sequence": [

{"type": "move_to", "target": "Zone-A",

"speed": 0.3, "timeout_sec": 30},

{"type": "wait", "duration_sec": 3},

{"type": "return_to", "target": "Home",

"speed": 0.3, "timeout_sec": 30}

]

}

Deterministic Validation Result

1. Schema Validator

Supported primitives: move_to, wait, return_to

Required fields are present

2. Semantic Validator

Targets resolved: Zone-A and Home are valid

3. Safety Guard

Speed 0.3 is within max_speed 0.5

No forbidden-zone target is requested

Runtime Decision: ACCEPT

Key point: The DSL exposes command intent as fields that validators can deterministically accept, reject, or clamp before robot execution.

Comparative Results — Three Runtime Strategies (N = 150)

Representative frames make the accept vs. reject behavior visually explainable.

Valid mission executed; safety events none

Red-Zone target blocked before execution

Valid target and no forbidden-zone violation

Tip: If the videos cannot be played during the talk, representative frames are enough to explain the ACCEPT vs. REJECT SAFETY difference.

Nova Carter Video Demo: Representative Runtime Decisions

Isaac Sim Experiment: 150 Scenario AMR Command Benchmark

The benchmark tests both mission preservation and abnormal-command prevention.

Environment

NVIDIA DGX Spark

Isaac Sim 5.1.0 frozen baseline

AMR top-down navigation scene

Normal

50

Speed Violation

30

Forbidden Zone

25

Invalid Target

20

Unsupported Action

15

Negative Wait

10

Total: 150 scenarios | Normal: 50 | Abnormal: 100

Extended Validation

Isaac Sim 5.1.0 · NVIDIA DGX Spark · Frozen Baseline Runs

Benchmark Composition

Normal

n = 50

ACCEPT

Unsupported Action

n = 15

REJECT SCHEMA

Forbidden Zone

n = 25

REJECT SAFETY

Invalid Target

n = 20

REJECT SEMANTIC

Speed Violation

n = 30

CLAMP & ACCEPT

Negative Wait

n = 10

REJECT SCHEMA

Normal: 50 (33.3%)

Abnormal: 100 (66.7%)

EXPERIMENTAL SETUP

The Benchmark Stresses Both Availability and Safety

150

AMR command scenarios

Scenario mix

50 normal missions

100 abnormal commands

Isaac Sim 5.1.0 baseline

NVIDIA DGX Spark

FAIR COMPARISON

Each scenario was executed once under Direct Execution, Schema Only, and DSL Guided Runtime using the same expected-decision rules.

Source: Paper Section V and Table III

PRIMARY RESULT

The DSL Runtime Eliminated Both Unsafe Pass-Through and Failure

100%

expected behavior match

150 / 150 scenarios

0%

unsafe pass-through

0 / 100 abnormal cases

0%

runtime failure

0 / 150 scenarios

All three methods still preserved 50 / 50 normal missions.

Source: Paper Section VI and Table IV

Percentages use the denominators reported in the paper.

SAFETY INTERVENTION, NOT BLANKET REJECTION

Safety Improved Without Over-Rejecting Commands

50 / 50

normal missions preserved by every method

30 / 30

speed violations clamped by the DSL runtime

0

unsafe commands passed through by the DSL runtime

VALID

Execute the command unchanged.

→

RECOVERABLE

Clamp excessive speed to the maximum, then execute.

→

NON-RECOVERABLE

Reject unsupported, unresolved, or forbidden commands before execution.

Safety optimality is selective: preserve availability, intervene deterministically, and block only when correction is not valid.

Source: Paper Sections VI–VII

Discussion: Why Direct Execution and Schema-Only Are Insufficient

Direct Execution Fails

No explicit reasoning boundary between command interpretation and execution

Unsafe commands pass through OR fail at runtime — not intercepted

55% unsafe pass-through among abnormal scenarios

Satisfies mission preservation but not safety minimization

Normal mission success ≠ runtime safety

Schema-Only Is Insufficient

Improves structural robustness (runtime failures: 30% → 13%)

Cannot resolve semantic validity or safety context

move_to(target='X') — valid schema, invalid/forbidden target

Still 55% unsafe pass-through — identical to direct execution

Necessary but NOT sufficient for safety-optimal AMR control

INTERPRETATION AND SCOPE

The Evidence Supports Runtime Safety—Not Full Autonomy

What the study demonstrates

• Commands become inspectable through a compact symbolic DSL.

• Layered validation separates structure, semantics, and safety policy.

• Errors shift from execution time to deterministic decision time.

• Valid missions remain available while unsafe decisions are blocked.

What remains outside scope

• Dynamic obstacles and continuously changing context.

• Raw camera or LiDAR perception and localization uncertainty.

• Multi-robot conflicts and fleet synchronization.

• Learning-based planners and formal verification comparisons.

NEXT RESEARCH STEP

Inject live temporary constraints, extend the DSL with coordination primitives, and retain deterministic validation behind VLM or LLM command interpretation.

Source: Paper Section VII

TAKEAWAY

A DSL Can Be the Safety Gate Between Intent and Motion

01

Represent

Convert commands into explicit plans.

02

Reason

Validate structure, targets, and constraints.

03

Decide

Accept, correct, or reject before execution.

150-scenario result: all normal missions preserved, 100% expected behavior match, 0% unsafe pass-through, and 0% runtime failure.

Thank you · Questions