Motors, settings, media and visualization

Motors: manual operation

Open #/motors. Motors are grouped by configured assembly/group; the page shows configuration count and latest state. Enable Manual Control changes actuator control mode. Sliders display degrees but convert values to radians before sending the posture command. Updates are debounced per motor by about 90 ms in the inspected UI.

The global Torque switch requests all-motor torque state; individual switches target one named motor. Unknown live torque state is displayed differently from confirmed on/off. Do not infer torque from a missing state value.

Reset All to Neutral in this WebUI sets local selected values to zero and, when manual control is enabled, sends those zero pose values for eligible motors. It skips motors with sort number above 1000. This is not the console's servo EEPROM/neutral calibration action. The same word “neutral” in different interfaces has different physical/persistent effects.

Before moving: select the intended robot, verify bounds/calibration, ensure competing behavior owners are understood, enable the correct control/torque deliberately, then move a prepared motor. Disabling manual control, disabling torque and stopping a performance are separate actions.

Motors Admin

Open More → Motors Admin (#/admin/motors). The table edits configuration, not only live slider values. It supports Add, select/delete rows, filter by name, structured-field dialogs and Save.

Columns cover identity/assembly/group/order, hardware family, motor ID/topic, raw min/init/max, speed/acceleration, gear ratio, parser/parameter, mapping function and structured extras/other functions. Supported hardware labels include Pololu, Dynamixel, Feetech variants, input and virtual mappings. Structured fields accept validated JSON-like content through their editor.

Save submits the full cleaned motor rows. The backend groups by configured assembly, writes settings/generated motor files, updates shared motor state and requests driver reload. Inspect returned warnings; unknown assemblies or unmatched rows are not silently valid calibration. Deleting selected rows changes the draft before saving. Back up calibrated assembly files first.

Settings: live versus saved

Open #/settings. Search/filter the node tree or use a deep link to a returned namespace. The UI remembers a selected node, loads its schema and values, and polls live configuration when not paused for editing.

Field edits can update the live runtime immediately. Read the result toast and current values. Save writes the node's configuration file through the manager; it is separate from a live edit. Reset restores runtime defaults and, if a saved override exists, offers a separate deletion confirmation. Deleting that file does not mean an already-running node has been reset unless reset was also performed.

Schema-driven editors can expose enums, structured JSON, arrays and tool/natural-action mappings. Follow descriptions/units from the selected node. If an editor falls back to raw structure, validate the complete object and preserve required keys rather than treating it as free text.

If a value reappears after restart, inspect saved overrides and source defaults. If live edit works but save fails, inspect the configuration manager, permissions and mount mode. Backend details.

TTS Files and ASR Files

Open More → TTS Files or ASR Files. Both browsers support refresh, folder navigation, parent folder, file sizes/modification times and audio access. Hash paths preserve folder selection; path segments are encoded before requests.

TTS files are generated speech artifacts. ASR files include current recordings and dated archives. Loading/playing a file is different from issuing a new synthesis or conversation request. Browser autoplay/download behavior depends on its media controls and permissions. Missing files can reflect retention/cleanup or an incorrect runtime storage path.

ASR final recordings can contain private speech. Do not copy them to the public documentation host. Listing a file successfully does not prove the corresponding provider session is still active.

Visualization and Unity

Open More → Visualization (#/virtual). The page requests /api/virtual-project, loads the returned Unity build and reports status. Controls include Head Only, Full Body, Full Screen, and a toggled operator Chat surface. Desktop chat is an overlay; at compact widths it moves to a bottom layout. Escape/focus handling supports closing the chat surface without losing the trigger context.

View buttons call Unity component methods; a missing scene method produces a UI result rather than changing a physical robot camera. Fullscreen requires browser support/user interaction. Unity asset availability, WebGL startup and animation socket connection are independent stages.

The embedded operator chat can issue actual robot/conversation actions. Rendering the virtual character does not switch the platform into simulation. See Unity protocol and UI controls.

Primary navigation includes TeleOps, Performances, Motors and Settings. More contains System Console, Visualization, TTS Files, ASR Files, Faces and Motors Admin. Speaker/microphone switches are tab-local and independent from physical speaker configuration. The API connection overlay is driven by health-query state; check adapter/provider status separately.

Evidence: head-ros-nodes/ros/webui/frontend/src/{App.jsx,pages/MotorsPage.jsx,pages/SettingsPage.jsx,pages/TTSFilesPage.jsx,pages/ASRFilesPage.jsx,pages/VisualizationPage.jsx} and associated backend handlers.