PolyScope X: loading a program requires a rendered frontend session — roadmap and design rationale for pendant-less use?

[mairtirol]

This is a question about PolyScope X behaviour rather than a library bug, but it directly shapes how DashboardClient can be used on PolyScope X, so I hope this is the right place to ask. Happy to move it to Discussions or a support ticket if you prefer.

Context

Our installations run without a teach pendant and without any operator-facing PolyScope UI. The arm is driven entirely through the Robot API and RTDE: at startup our software uploads/updates its .urpx control program, loads it, plays it, and then controls the arm via RTDE registers.

Two things make the browser dependency below a blocker rather than an inconvenience:

• No pendant. Nothing renders the PolyScope X frontend at the robot unless we run something that does.
• Unattended updates. Installations are updated remotely. When an update changes the control program, the new .urpx has to reach the controller with nobody on site — so every update would depend on an embedded browser session being alive and healthy at that moment, with no one there to intervene.

Running a full Chromium purely to satisfy one REST call is also a serious cost in verification, footprint and security-update cadence.

The behaviour

Loading a program through the Robot API is not headless: robot-api forwards the load to the polyscopex-services remote-program service, which drives the rendered Angular application to actually open the program. With no browser rendering the frontend against the controller, the load never completes.

The same applies to querying which program is currently loaded, and to updating an already-installed program. Uploading a program, listing programs, robot mode, program state and play/pause/resume/stop are not affected.

Questions

1. Roadmap — is there a plan to make program loading work without a rendered frontend, i.e. handled by the backend services alone? If so, roughly which PolyScope X release?
2. Design rationale — what is the reason for routing the load through the rendered frontend rather than the backend? Knowing the constraint would help us pick a workaround that won't break later.
3. Library-side — commandLoadProgramWithResponse() reports success for a load that has only been accepted and may not have been carried out. Is there a status or diagnostic endpoint that would let a client distinguish "queued" from "executed" or "failed", rather than polling commandGetLoadedProgramWithResponse() until a timeout?

Environment

• Robot: UR8 Long, PolyScope X 10.13
• Also observed on universalrobots/ursim_polyscopex:10.13.0
• Client: ur_client_library (C++), DashboardClient with ClientPolicy::POLYSCOPE_X, plus RTDE
• Remote control enabled

Happy to provide details, logs or a reproducer if that helps.

[rasmus-lolk]

Short answer: this is working as intended, not a bug.

When Hardware is set to None in Safety Settings and the Teach Pendant is removed, the PolyScope X UI is still running in a Chromium instance — it's just not visible, since no screen is attached. So there is still a loaded frontend.

There are currently no plans for the Robot API to load programs when no PolyScope X instance is running, as this only occurs in a URSim setup. The reasoning is that a "program" belongs to the PolyScope domain, and which program is loaded is frontend state. We plan to support multiple PolyScope X instances in the future, each with a different loaded program — only one can control the robot, but the others can edit programs concurrently.

Regarding commandGetLoadedProgramWithResponse: I think this one does need a change. It wraps the Robot API, which only sends a response when program loading succeeds or fails — so a plain query has nothing to wait on. @urrsk , should we align the library with that?