Use this tour beside the terminal guide. Each screenshot is a real retained capture. In the HTML edition, select a numbered marker to jump to its explanation. Open the original image to read small text at full resolution.
The beta terminal has a views rail on the left and opens on Health. The Health image shows that layout. The Topics, Nodes, and launch log images come from an earlier build. The beta adds the views rail on the left, and other details on your screen can differ. Press ? in the terminal for the controls of the current view. For the desktop app, see the Scene Workbench guide.
Health: start here
Press 1 for Health. It lists what needs attention first, then the environment, graph counts, and owned launch state under System at a glance. This image was captured before the beta from an illustrative demo session file, not a live robot. The beta's Health view also shows sampled rates and the processes of an owned launch.
Terminal Health view with the views rail, captured before the beta at 120×36 from an illustrative Nav2 demo session file. Not a live robot. The beta's Health view also shows sampled rates and launch processes. Open original at full resolution.
- Use the views rail. Each view shows its key and a badge. Here Health has 6 errors and TF has one frame with two parents. Click a view or press its number.
- Start with the problems. Launch evidence comes first, then graph checks, most severe first. Each row names its evidence: process state, log pattern, declared check, or graph check.
- Read the verdict and its limits. The first line answers whether the system is ready. GRAPH CHECKS says which checks ran and what was not checked. A graph snapshot shows likely causes, not proof.
- Use the keys for this view. Enter opens the topic or frame a problem names, y copies its check command, and : opens the command palette.
Next: start from Health.
Topics: distinguish discovery from delivery
Press 3, filter with /, and select the exact topic. In this /scan capture, the inspector reports zero publishers and one subscriber. It also retains three previously collected message samples. Read the sample clock, bounds, and collection time before treating those samples as current data.
Terminal capture from an earlier build, before the views rail. The beta adds the views rail on the left; other details can differ. Open original at full resolution.
- Select Topics. Press 3, then choose the exact topic name in the list.
- Check endpoints. The selected /scan has zero publishers and one subscriber in this observation. A topic name can exist without a current publisher.
- Inspect received samples. Read message count, bounds, clock, and field values together. A retained sample does not prove the publisher is active now.
Next: investigate the lidar example.
Nodes: inspect endpoints and limits
Press 4 and choose a node. The inspector shows connections and captured QoS settings. A discovered /panda_arm_controller can still fail to activate. This capture has no source declaration linked to the node; unknown source mapping should stay unknown.
Terminal capture from an earlier build, before the views rail. The beta adds the views rail on the left; other details can differ. Open original at full resolution.
- Select the node. Nodes lists discovered names. Here /panda_arm_controller is selected.
- Read the inspector. Check its topic endpoints and QoS. This node can still be present while its controller fails to activate.
- Check mapping limits. Source mapping is unknown in this capture. Do not infer a source file from the node name.
Next: investigate the controller failure.
Launch log: retain the cause
Press L during an owned launch. Read the state and log path, then preserve the actual error and nearby lines. Here MoveIt reports an invalid planner plugin. Use Esc to return to the investigation. The beta log view also has search, filters, and paging; see the launch log guide.
Terminal capture from an earlier build, before the views rail. The beta adds the views rail on the left; other details can differ. Open original at full resolution.
- Identify the owned launch. The panel shows launch/readiness state and the retained log path. Press L to inspect the owned launch log.
- Read the error line. The captured planner error names an invalid plugin. Preserve the full error and nearby lines before changing the configuration.
Next: investigate the planner error.
Saved results: read the scope with the verdict
Open a report with flightops results. This report, from an earlier build, shows a successful environment-sourcing check. Read Execution result, What this establishes, and Evidence scope together. Expand checks and the original result to review their inputs. Download the source JSON to retain the exact report input. Reopening this report does not remeasure a live system.
Saved report from an earlier build, reopened from its source JSON. It shows a local environment-sourcing check, not a current live observation. Open original at full resolution.
- Keep the source result. Download source JSON retains the report input. Keep it with the HTML and any recording that produced the report.
- Read what the report establishes. Execution result, What this establishes, and Evidence scope qualify the result. PASS applies to the displayed sourcing check, with its stated scope and unknowns.
- Inspect the checks and source. Expand a check to review inputs and measurements. Source JSON below the report lets you compare the reopened report with the saved input.
Next: capture a talker and open your own report.
Screenshot provenance
The original image bytes are unchanged. Numbered markers are HTML overlays. The callout manifest records their source paths, SHA-256 digests, scope, and explanations. The terminal captures from the troubleshooting examples also have a provenance record. These examples explain how to read the views; they are not test results for your system.