Other screens
The screens in the main app that have no sidebar entry: what each one is, and which ones you can trust.
The sidebar shows four entries on https://zeonsystems.app. The app has more screens than that. Some are reached from a button rather than the menu, some are reachable only by typing the URL, and a few are developer scaffolding that was never wired up.
Every screen below lives under your project URL: /p/<project-id>/<screen>. This page tells you what each one is and whether its output means anything.
Annotation
Path: /p/<project-id>/annotation. Status: wired, needs real cameras
This is how you turn a physical bench into a world. It moves the arms clear, captures from the rig's two cameras, lets you outline the objects you can see, works out where each one sits in 3D, and saves the result as a world you can run workflows against.
You reach it from World Builder, where the Create World from Cameras panel has a Capture Cameras button that opens it. The left panel is headed Annotation Tools and walks four numbered steps: 1. Capture, 2. Label Objects, 3. Localize, and 4. Save World.
Labelling has two modes, Click and Box. Click mode segments the object under the point you click; box mode segments whatever falls inside a rectangle you drag. Either way you give the result a name. Localize Objects then computes a pose for each labelled object from the two camera views, and the step is only complete once every object reports as localized. The save step stays out of reach until then.
Capture works on a cloud project too. The execution service there is simulation-only, so it renders the two camera views from the simulated world rather than photographing a physical bench. To build a world without capturing at all, use World Builder directly. See Building a world.
Capture moves the arms before it takes the picture. Pressing it first commands both arms to their watching positions and waits for that motion to finish. On a rig with real hardware attached this is a physical movement you did not explicitly ask for. Stay clear of the arms' reach before pressing Capture.
Developer Tools
Path: /p/<project-id>/developer-tools-*. Status: mixed; one useful view, the rest scaffolding
There is no single Developer Tools screen. There are five separate routes, and the one you land on decides what you see. None of them has a menu entry, so you get there by typing the URL.
developer-tools-skills is the one worth knowing about. It is headed Skill Database and lists every skill in the project from live project data. Click a skill and you pick a world, then land in the Skills Editor with that skill open. Expanding a skill loads its parameters.
Its search box is better than the one in the Workflow Editor. Here, typing filters on the skill's name, description, and tags. The Workflow Editor's skill dropdown only ever matches the skill name, so a skill whose name you have forgotten but whose purpose or tag you remember is findable here and not there. If you are hunting for "the one that does the plate transfer", this is the screen to open.
developer-tools-scientific is headed Scientific Database and shows a list of contexts with files, objects, and images. Its contents are fixed sample entries built into the app, not your project's data, and the Add Context form does not save anything. Treat it as a mockup.
Hardware Setup
Reached from the Hardware Setup dialog in the header, via Design a new endpoint from a URDF or mesh…. This is a genuine working screen for designing a gripper endpoint. It drives a live session and restarts the execution service when you confirm, so expect a short reconnect after you use it.
For what the header hardware indicator does and does not tell you, and the limits worth knowing before a physical run, see The main app.
Protocol viewer
Path: /p/<project-id>/protocol-viewer. Status: wired
A read-only view of a saved workflow's graph. The header reads Workflow Preview with the workflow's name and a Read Only badge. Clicking any node opens a Node Details panel on the right showing that node's label, type, and node ID. A footer strip counts Nodes, Edges, and shows the workflow's Version.
Nothing here changes the workflow. When you want to edit, Edit Workflow hands the same workflow to the Workflow Editor.
It needs to be told which workflow to show, which happens when you open it from a workflow card's view action in the Workflows screen. Since Workflows is hidden in cloud mode, there is no route to this screen through the cloud UI. On zeonsystems.app you would be typing the URL, and typing it directly gives you an error because no workflow has been selected.
Workflows
Path: /p/<project-id>/workflows. Status: wired, but hidden in cloud mode
This is the workflow library and run history. It has two tabs: Saved Workflows lists every workflow in the project with search over name and tags, and per-workflow actions to open it for a run (pick a world, then land in the Workflow Editor), view, copy the name, or delete. Past Executions lists previous runs, searchable by workflow name or ID.
You will not see this screen on https://zeonsystems.app. The sidebar entry is hidden when the app runs in cloud mode, because the cloud is simulation-only and keeps no real-hardware execution history. It appears on a lab machine attached to a robot.
One rough edge: on the Past Executions tab, the view action on an execution card does not open anything yet.
Where to go next
Updated 2 days ago