Teleop Is a Human-Machine Interface

Teleoperated control is not just “map buttons to motors.”

The driver is part of the control system. The controller layout, feedback, robot response, latency, default behavior, and failure handling all affect performance.

Map intent, not hardware

Compare:

Button A → motor 7 at 70%

with:

Right trigger → acquire game piece

The second mapping describes driver intent. Software can change how the intake mechanism works later without forcing the driver to relearn which internal motor is being controlled.

That separation is one benefit of commands and subsystems.

Continuous versus discrete control

Some controls represent a range.

• joystick forward/back;
• steering axis;
• variable trigger.

Others represent an event or state.

• toggle intake;
• move to scoring preset;
• reset heading;
• cancel automation.

Choose a control type that matches the action.

Deadbands and scaling

Joysticks rarely sit at mathematically perfect zero. A small deadband ignores tiny values around center.

Teams may also shape joystick input so low-speed control is easier while full range remains available.

The purpose is not fancy math. It is predictable driver control.

Defaults matter

What should the robot do when nobody is pressing anything?

For a drivetrain, a default drive command may be appropriate.

For a dangerous mechanism, the safe default may be stop or hold position.

Write the default behavior explicitly.

Driver-interface review

For one mechanism, create a control map:

Then run a paper simulation.

Imagine the driver is stressed and looking at the field, not the controller.

Can they recover from a wrong button press? Is the cancel action obvious? Are two critical actions easy to confuse?

Failure mode: control that only the programmer understands

A clever control scheme can be technically elegant and operationally terrible.

Driver controls should be tested by drivers.

The interface belongs to the human using it, even when the code belongs to the programming team.