Section 50.1: Robots among humans

A hallway robot that is technically correct can still be socially terrible.

A Social Navigation Planner

A robot can clear every obstacle, hit every waypoint, and still send a nurse lunging for the wall: so how do you write a contract for "did not frighten anyone" the way you write one for "did not collide"? This section specifies that closed-loop contract for a robot operating among people: the named interface it exposes, the replayable scenario it is tested on, the failure diagnostic that catches social errors, and the artifact that records what changed in the action loop. The deliverable is a system that is socially legible (that is, its motion lets a bystander correctly infer what it is about to do), not merely collision-free.

The key question is practical: Which human-facing risks are observable, which are controllable, and which require a conservative fallback?

Theory

The practical design rule for a social navigation stack is to make the planner interface inspectable before you tune a single cost weight. On a ROS 2 platform like a TIAGo or a Savioke Relay, the recorded rosbag must show every part of that interface. It records the planner's inputs (pedestrian position and velocity on /people, the robot's pose in the map frame) and its outputs (the selected arc and the LED intent state). It also records the units and frame of every field, the end-to-end latency from perception to commanded velocity (typically 80 to 150 ms on a mobile base), the comfort and clearance bounds, and the four structured failure labels. If a startle event later shows up in a deployment, you replay that bag and read off exactly which input went stale or which cost term dominated, rather than guessing.

Worked Example

Consider a hospital delivery robot entering a hallway. It must predict pedestrian motion, yield near doorways, communicate intent, and log why it slowed down or stopped. "Communicate intent" here means the robot's motion is legible: a bystander can tell what it is about to do before it finishes doing it; the Technical Core section below defines this property mechanically.

Consider a specific case. A Savioke Relay robot (0.45 m wide, max 1.0 m/s) approaches a nurse walking at 1.2 m/s toward a doorway 4 m ahead. The social-force planner assigns a personal-space radius of 1.5 m to the nurse. It scores the straight-line path at 0.3 m clearance, below the 0.8 m comfort threshold. The planner then generates an arc that raises clearance to 1.6 m at the cost of 1.2 extra seconds, and the robot simultaneously activates its LED ring to signal a rightward yield. The interaction log shows: closest nurse proximity 1.1 m, no startle event, no operator takeover, comfort rating 4.5 out of 5. The 1.2-second delay is acceptable because the human-facing metrics improve: clearance nearly doubles, and the nurse understood the robot's intent before it moved.

# Social-force comfort scoring: compare straight-line vs. arc path for a hospital robot
import numpy as np

# Robot and pedestrian parameters (Savioke Relay scenario)
ROBOT_WIDTH = 0.45        # metres
COMFORT_THRESHOLD = 0.8   # minimum acceptable clearance in metres
PERSONAL_SPACE = 1.5      # pedestrian personal-space radius in metres

def path_clearance(robot_positions, pedestrian_pos):
    """Return minimum distance from any robot waypoint to the pedestrian."""
    dists = np.linalg.norm(robot_positions - pedestrian_pos, axis=1)
    return float(np.min(dists))

def comfort_score(clearance, threshold=COMFORT_THRESHOLD):
    """Map clearance to a 0-5 comfort rating (linear, capped)."""
    return float(np.clip(5.0 * clearance / threshold, 0.0, 5.0))

# Hallway geometry: robot travels 6 m, pedestrian is 1.5 m off the robot's axis
start = np.array([0.0, 0.0])
goal  = np.array([6.0, 0.0])
ped   = np.array([3.0, 1.5])   # nurse crossing mid-corridor

# Straight-line path (50 waypoints)
t = np.linspace(0, 1, 50)
straight = np.column_stack([start[0] + t * (goal[0] - start[0]),
                             np.zeros(50)])

# Arc path: yield rightward by 0.8 m at the midpoint
arc_y = -0.8 * np.sin(np.pi * t)   # negative = rightward offset
arc   = np.column_stack([straight[:, 0], arc_y])

for label, path in [("Straight", straight), ("Arc (yield)", arc)]:
    clr = path_clearance(path, ped)
    rating = comfort_score(clr)
    status = "PASS" if clr >= COMFORT_THRESHOLD else "FAIL"
    print(f"{label:14s}  clearance={clr:.2f} m  comfort={rating:.1f}/5  [{status}]")

# Extra travel cost of the arc (Euclidean path length)
straight_len = np.sum(np.linalg.norm(np.diff(straight, axis=0), axis=1))
arc_len      = np.sum(np.linalg.norm(np.diff(arc,      axis=0), axis=1))
robot_speed  = 1.0   # m/s
extra_time   = (arc_len - straight_len) / robot_speed
print(f"\nExtra travel time for arc: {extra_time:.2f} s  "
      f"(straight {straight_len:.2f} m, arc {arc_len:.2f} m)")

Straight        clearance=1.50 m  comfort=5.0/5  [PASS]
Arc (yield)     clearance=2.28 m  comfort=5.0/5  [PASS]

Extra travel time for arc: 0.27 s  (straight 6.00 m, arc 6.27 m)

Practical Recipe

1. Fix the observation schema before choosing a planner: publish pedestrian position, velocity, and heading at 10 Hz on a ROS 2 /people topic using the people_msgs/People message type so that latency and drop-outs are visible in the bag before you tune any cost weights.
2. Start with a static-obstacle comfort baseline using a fixed personal-space radius of 1.0 m (roughly the inner boundary of the "social zone" in Proxemics, the study of how people use interpersonal distance, where the social zone spans about 1.2 to 3.6 m). Confirm the planner rejects paths with less than 0.6 m clearance on your specific platform width before adding any prediction model. For a Savioke Relay (0.45 m wide) this means rejecting any path center-line within 0.825 m of a person.
3. Add a constant-velocity pedestrian predictor (Constant Turn Rate and Velocity, CTRV model, 0.5 s horizon) only after the static baseline passes a Wizard-of-Oz trial with at least five different approach angles. CTRV is sufficient for corridor encounters; replace it with a Social LSTM or Trajectron++ only when measured prediction error at 0.5 s exceeds 0.15 m RMS (root mean square, a standard way to summarize average prediction error magnitude) on your recorded foot-traffic data.
4. Record failures with four structured fields: (a) minimum recorded clearance in metres, (b) whether a startle event or operator takeover occurred, (c) the pedestrian approach angle at the moment the planner first reacted, and (d) which cost term dominated the path score. This schema maps failures directly to planner parameters rather than to vague "interaction quality."
5. Run three perturbation tests before deploying to a new site: sudden direction reversal at 2 m range, two pedestrians approaching from opposite sides simultaneously, and a stationary person blocking 60 percent of corridor width. On a Franka-mobile or TIAGo platform, the last case forces the planner into a slow-approach or request-to-pass mode; confirm the LED intent signal fires at least 1.5 s before the robot reaches the 0.8 m comfort boundary.

Robots among humans becomes useful when it is tied to a closed-loop contract for Human-Robot Interaction. The contract names the participants, observations, action authority, timing budget, logging artifact, and recovery rule. Without that contract, a system can look capable in a notebook while failing the first time a partner delays, a person corrects it, or a deployment scene changes.

Separate the conceptual claim, the systems claim, and the evidence claim. A plausible mechanism, a clean interface, and a closed-loop result are different claims; the section should keep their evidence separate.

The baseline and maintained-tool version should produce the same artifact schema and run on one task panel. That requirement keeps a systems comparison from becoming a collage of incompatible runs.

1. Write a one-paragraph task contract with observation, action, success, and failure fields.
2. Start with the smallest simulator, dataset, or wrapper that exposes the task contract faithfully.
3. Run one deterministic smoke test and one perturbation test before scaling.
4. Save a single result artifact containing configuration, seed, metrics, videos or traces, and failure labels.
5. Compare methods only when one script evaluates them on the same task panel.

When Robots among humans fails, avoid labeling the whole method as weak. First assign the failure to perception, communication, human input, memory, planning, control, timing, data coverage, safety, or evaluation. Then rerun one controlled perturbation that isolates the suspected cause. This pattern turns a disappointing rollout into a reusable diagnostic asset.