Teleoperated Robot HMI: Separate View Controls from Motion Commands

A teleoperated robot should not copy every remote-view control onto its local HMI. The local panel should make one decision obvious before anything moves: who has control now? Use the display window for control-source, connection and permission states; reserve fixed keys for clearly bounded local actions; and never let the same key both change a camera view and issue motion. If local jog is required, give it a separate enable condition, visible state and system-level safety review. The panel supplier can build the window, key zones, overlay, tail and connector, but the robot manufacturer owns control logic and machine safety.

Why a new telemanipulation study changes the panel brief

A human-centred operator study published on August 10, 2026 compared three visual interfaces for precision telemanipulation with 18 participants and a UR5 arm. The researchers found that adding a third-person view was associated with an approximately 16-point higher System Usability Scale score. The study did not detect a corresponding improvement in binary task success, and the authors treated the performance comparisons as inconclusive rather than proof that the view had no effect.

This is not a Baoshengda study, and it does not prescribe a membrane switch or local robot panel. It does expose a useful procurement distinction: remote visual feedback and local physical control solve different operator problems. A richer remote view can improve the operator experience, while the local HMI still has to communicate authority, permission and recovery without creating another ambiguous command path.

The practical question is therefore not how many remote functions can fit on the local overlay. It is which states and actions must remain clear at the machine when remote viewing, local service and the safety system meet.

Map the remote console, local HMI and safety chain separately

Freeze three function maps before approving artwork. Combining them into one undifferentiated key list makes later software and safety discussions harder.

• Remote operator interface: camera views, overlays, task information and permitted teleoperation commands belong here. It may be a workstation, headset or other system outside the front-panel supplier's scope.
• Local machine HMI: control-source status, communication state, maintenance acknowledgement, service information and deliberately approved local actions belong here.
• Safety chain: emergency stop, protective-stop logic, enabling devices, speed limits and safe motion functions belong to the robot integrator's validated architecture, not to an ordinary membrane-key circuit.

The local panel can display information received from the controller, but it should not imply that an illuminated legend proves a safe state. The controller and safety architecture determine the actual state. The overlay and key layout only make that state and the allowed human action easier to understand.

Show control source before asking for permission

A local technician should be able to answer four questions without guessing:

• Is control local, remote or unavailable?
• Is the remote link healthy, degraded or lost?
• Is a local action permitted in the current machine state?
• Will the next press acknowledge information, select a view, reset a fault or request motion?

Put control-source and permission information in stable, reserved areas of the display window. Do not reuse one small indicator for unrelated states. If colors are used, pair them with a symbol, label or location rule so the interface does not depend on color alone. Define the off-state appearance as carefully as the illuminated state. A dead or unpowered indicator must not resemble an active permission.

For a compact panel, fixed tactile zones can support actions that must be found without navigating a changing touchscreen. Their functions still need to be bounded. A fixed acknowledge key, for example, should not become a jog key in another screen unless the manufacturer has a deliberate state model, unmistakable feedback and the required risk controls.

Keep view selection, acknowledgement and motion in different control classes

Use a control allocation table before the graphic overlay is drawn. It forces the buyer, controls team and panel supplier to discuss the consequence of each input rather than debating icons after the layout is fixed.

This table is a design boundary, not a universal robot-control specification. The exact allocation depends on the robot, applicable standards, risk assessment and control architecture.

Define loss-of-link and handover states before choosing legends

The most important panel state may be the one that appears when communication is incomplete. Ask the controls team to define what the local HMI shows during:

• normal remote control;
• a request to transfer authority from remote to local;
• a rejected or timed-out transfer;
• degraded video with a healthy command channel;
• a healthy video channel with an unavailable command path;
• complete communication loss;
• local service mode;
• controller restart and panel power recovery.

Do not let the overlay artwork collapse all these conditions into a generic fault symbol. The panel may not need to display every network diagnostic, but it must distinguish the states that change what a person is allowed to do.

For each state, define the visible message or indicator, which keys remain active, what pressing a key requests, and what response confirms acceptance. Include the transition time and the no-response condition. A sample can then be evaluated against a finite state list instead of a single powered photograph.

Design the window and fixed keys for local distance and lighting

The remote operator may work close to a large display, while the local technician stands beside an enclosure under factory lighting. That difference changes the front-panel brief.

Specify the local viewing distance, viewing angle, glare sources, ambient light and whether gloves are used. Confirm that status groups remain distinct through the actual window material, surface finish and any dead-front treatment. If backlighting is included, review bleed between legends, brightness at the intended distance and the appearance when the light is off.

For physical keys, define key size, spacing, embossing, actuation force or tactile target, and support behind each active area. Place any motion-related input away from acknowledgement or display-navigation keys. A user should not reach across one control class to operate another during a service task.

Route the tail for service access, not only assembly

A clean front layout can still fail at the rear. The tail direction, bend, connector and service loop must fit the enclosure after the display, controller, cable glands and mounting hardware are installed.

Send the panel supplier a rear-clearance drawing and a photo or CAD view of the intended cable route. Define:

• tail exit location and orientation;
• total tail length and the controlled bend zone;
• contact side, pitch, exposed-contact length or connector model;
• connector retention and insertion direction;
• keep-out zones near screws, sharp edges and moving parts;
• service-loop space and the replacement procedure;
• strain relief or support near the panel exit.

Do not approve a loose front sample if the real assembly requires the tail to fold immediately at the panel edge. Mount the sample and inspect both front operation and rear routing after the enclosure is closed.

Supplier boundary and system limitations

A custom industrial automation HMI panel supplier can review the overlay stack, display window, key zones, printed circuit or FPC tail, connector interface, adhesive land, backlighting option and assembled front-panel evidence. Those are physical interface decisions.

The panel supplier does not determine robot-control authority, network architecture, safe speed, protective stops, emergency-stop performance or the validity of a remote operation. It also cannot infer the correct motion logic from artwork alone. The robot manufacturer or system integrator must provide the state model, input consequences, risk controls and acceptance criteria.

Keep this boundary visible in the drawing and test plan. It prevents a normal membrane-switch input from being mistaken for a safety-rated control and prevents a display legend from being treated as proof of a machine state.

Run a mounted handover test before releasing the sample

Test the front panel in the intended enclosure with the controller or a representative simulator. Record at least these cases:

1. Power up with no remote connection and confirm the default control-source indication.

2. Establish the remote connection and verify that local keys do not silently change class.

3. Request a local or remote handover and record pending, accepted, rejected and timed-out states.

4. Change remote views and verify that the local panel does not issue motion or show a false authority change.

5. Interrupt the command link and video link separately if the architecture can distinguish them.

6. Press acknowledgement and reset inputs in allowed and disallowed states and record the response.

7. If local motion exists, test the enable condition and direction mapping under the integrator's safety procedure.

8. Repeat the key checks after enclosure closure, tail bending and connector retention.

9. Inspect window readability and indicator distinction from the normal service position.

10. Reboot the controller and confirm that the panel never shows an active permission before the state is valid.

Attach photos, state logs and drawing revision to the sample record. A pass or fail note without the tested state is not enough for later production transfer.

RFQ checklist for a teleoperated robot local HMI

Send this package before asking the supplier to lock the construction:

• robot or machine type and the purpose of the local panel;
• remote-console, local-HMI and safety-chain function maps;
• control-source and authority-transfer state diagram;
• list of fixed keys, with the consequence and enable condition for each key;
• display-window dimensions, active area, viewing distance and lighting conditions;
• illuminated, non-illuminated, link-loss and power-recovery appearances;
• overlay material, surface finish, legend method, embossing and cleaning exposure;
• tactile target or actuation-force range and housing support under each key;
• front-panel drawing, bezel or recess, adhesive land and mounting-surface material;
• tail direction, length, pin map, contact side, connector, bend zone and rear clearance;
• prototype quantity, annual quantity and required sample evidence;
• mounted handover, communication-loss and enclosure-closed acceptance tests;
• explicit supplier boundary for controller logic, functional safety and system validation.

When the function map and mechanical package are ready, send the drawing and RFQ inputs for engineering review. A useful first review should connect the visible control-source states, fixed key classes, window construction and rear tail route before the artwork is treated as final.