Dashboard Integration

A handful of variable names are reserved by the dashboard: publishing telemetry under these keys drives specific UI surfaces instead of being rendered as a generic parameter. You normally don’t set these keys directly — use the helper functions below, which publish them for you.

Helper Functions

declare_scene(kind="default", **config)

from omniloop import declare_scene

declare_scene(
    kind="humanoid",
    joints=["left_hip_pitch", "right_hip_pitch",
            "left_knee", "right_knee",
            "left_shoulder_pitch", "right_shoulder_pitch"],
)

Declares the 3D scene type rendered by the dashboard’s spatial canvas. Publishes the __scene__ variable.

• kind="default" — grid, velocity vector, trajectory trace, and lidar scatter. No robot rendered; works with any telemetry.
• kind="humanoid" — adds a stick-figure rig. Pass joints as a list of joint variable-name prefixes; the canvas reads joint_<prefix> from telemetry for each one. Without joints, an analytic walking animation driven by velocity is shown, labelled “DEMO”.

declare_execution_graph(nodes)

from omniloop import declare_execution_graph

declare_execution_graph([
    {"id": "preprocess", "desc": "Preprocess inputs"},
    {"id": "forward", "desc": "Forward pass"},
    {"id": "backward", "desc": "Backward pass"},
])

Declares the list of execution-graph nodes shown in the dashboard’s left sidebar. Publishes the __exec_nodes__ variable.

tracker.set_active_node(node_id)

from omniloop import tracker

tracker.set_active_node("forward")

Marks which declared execution-graph node is currently active, highlighting it in the sidebar. Publishes the __exec_active__ variable. Unlike declare_scene/declare_execution_graph, this is a tracker method rather than a top-level import — call it as often as your active node changes (e.g. once per graph step).

Reserved Telemetry Keys

These keys are populated by the helpers above (or internally by the SDK) and consumed directly by dashboard components. Publishing a value under one of these keys yourself will be interpreted the same way.

Key	Set by	Consumed by	Payload
__scene__	declare_scene()	Spatial Canvas	JSON scene descriptor: {"kind": ..., ...config}
__exec_nodes__	declare_execution_graph()	Left Sidebar	JSON list of {"id", "desc"}
__exec_active__	tracker.set_active_node()	Left Sidebar	The active node’s id string
__source_files__	Set automatically by TrainingLoop/instrumentation when a script path is known	Left Sidebar	JSON list of {"name", "lines": [{"key", "label", "line"}, ...]}, used for “go to line” source navigation
__schema__	Set automatically on every publish_telemetry_raw() call once you’ve declared a schema (see YAML Param Schema)	Dashboard control panel	The declared parameter schema
watch_trip	Set automatically by the core for as long as a watchpoint trip is live	Event Console, /stats	{"name", "condition", "value"}
limit_clamp	Set automatically by TrainingLoop for ~1.5 s after a limits= clamp is enforced (see Limit Enforcement)	Clamp badge on the control, Event Console	{"name", "requested", "clamped", "min", "max"}

Note

All reserved keys ride along on the normal telemetry channel — there’s no separate “publish the scene” or “publish the graph” step, and no risk of them being dropped by the channel’s latest-wins semantics as long as they’re re-published whenever telemetry is.

Caution

watch_trip and limit_clamp both report events rather than state, and both must survive the channel’s single-slot semantics: a value present on only one frame is dropped, not delayed, whenever the loop outruns the consumer’s poll. A trip is re-sent for as long as it is live; a clamp has no such live state, so it is re-sent for a fixed ~1.5 s window instead. Both are stripped from the server’s telemetry cache as soon as a frame arrives without them, both are deduped by content so one occurrence means one Event Console row, and neither is included in the state hash.