○Draft — not verified

Theoretical Background: Teleoperation of Mobile Robots

Module 4 Theory: Teleoperation

4.1 Human-Robot Interaction in Teleoperation

Teleoperation allows a human operator to remotely control a robot across a communication link. The system architecture consists of three fundamental components: the operator station (input devices, displays, feedback systems), the communication link (wired or wireless network), and the robot system (actuators, sensors, local controller). The theoretical challenge is maintaining stable, responsive control despite imperfect communication and human perceptual limitations.

4.1.1 Levels of Teleoperation Autonomy

Direct Control: Raw commands mapped directly to actuators. The operator bears full responsibility for all motion. Requires latency below 50 ms for effective operation.

Shared Control: The operator provides high-level direction while local autonomy handles low-level tasks such as obstacle avoidance. Tolerates latency in the 50–500 ms range.

Supervisory Control: The operator sends goals and the robot plans and executes autonomously. The operator monitors and corrects as needed. Can tolerate latency exceeding 500 ms.

Key Assumption: As communication delay increases, the level of local autonomy must increase to maintain system stability and operator effectiveness.

4.1.2 Input Devices and Command Mapping

The choice of input device determines the mapping from human intent to robot command. The fundamental mapping takes the form:

u_{robot} = M (u_{human}) (1)

where $M$ is a mapping function that may be linear, nonlinear, or state-dependent.

Keyboard Teleoperation provides discrete velocity commands. Each keypress maps to a fixed velocity setpoint, making it simple but lacking proportional control.

Script Implementation (Keyboard Teleop):

# Keyboard teleoperation node for differential drive robot
        # Publishes Twist messages to cmd_vel topic
        import rclpy
        from rclpy.node import Node
        from geometry_msgs.msg import Twist
        
        class KeyboardTeleop(Node):
        def __init__(self):
        super().__init__('keyboard_teleop')
        self.publisher      = self.create_publisher(Twist, 'cmd_vel', 10)
        self.linear_speed   = 0.5   # m/s   max linear velocity
        self.angular_speed  = 1.0   # rad/s max angular velocity
        
        def process_key(self, key):
        twist = Twist()
        if key == 'w':
        twist.linear.x  = self.linear_speed   # forward
        twist.angular.z = 0.0
        elif key == 'a':
        twist.linear.x  = 0.0
        twist.angular.z = self.angular_speed   # turn left
        elif key == 'd':
        twist.linear.x  = 0.0
        twist.angular.z = -self.angular_speed  # turn right
        elif key == ' ':
        twist.linear.x  = 0.0  # emergency stop
        twist.angular.z = 0.0
        self.publisher.publish(twist)

Joystick Teleoperation provides proportional control through analog stick deflection. The mapping is:

v_{linear} = k_{lin} a_{y} (2)

ω = k_{ang} a_{x} (3)

where $k_{lin}$ and $k_{ang}$ are scaling gains and axis values $a_{y}$ , $a_{x}$ range from $- 1.0$ to $1.0$ .

Script Implementation (Joystick Teleop):

# Joystick teleoperation with deadman switch for safety
        # Subscribes to Joy messages, publishes Twist to cmd_vel
        
        class JoystickTeleop(Node):
        def joy_callback(self, msg):
        twist = Twist()
        # Only move if deadman button (L1) is held -- safety feature
        if msg.buttons[deadman_button]:
        twist.linear.x  = max_linear  * msg.axes[linear_axis]
        twist.angular.z = max_angular * msg.axes[angular_axis]
        else:
        twist.linear.x  = 0.0  # release stops robot
        twist.angular.z = 0.0
        self.publisher.publish(twist)

Haptic Devices (3-DOF or 6-DOF interfaces) enable force feedback teleoperation. The device position maps to robot velocity or position, while contact forces are fed back to the operator, creating a bilateral control loop.

4.1.3 Feedback Mechanisms

Effective teleoperation requires closing the perception loop so the operator can observe the consequences of commands.

Visual Feedback: Camera streams from robot-mounted cameras, overhead map views from external sensors, and augmented displays showing sensor data overlaid on video. In ROS 2, camera topics are viewed using rqt_image_view.

Sensor Data Feedback: LiDAR scan visualization, obstacle proximity warnings, battery level indicators, and odometry (position/velocity) display provide quantitative situational awareness.

Audio Feedback: Proximity alarms where beeping frequency increases near obstacles, motor sound indicating speed, and speech alerts for critical conditions supplement visual channels.

4.1.4 Latency and Stability in Teleoperation

Communication Latency

The total round-trip delay between operator input and perceived robot response is:

T_{total} = T_{command} + T_{processing} + T_{feedback} (4)

Local Ethernet: $< 1$ ms, suitable for direct control
WiFi (local): 1–20 ms, suitable for direct or shared control
4G/LTE: 30–100 ms, suitable for shared or supervisory control
5G: 1–10 ms, suitable for direct or shared control
Satellite: 500–2000 ms, suitable for supervisory control only

Stability Under Delay

Time delay destabilizes bilateral teleoperation systems. The passivity-based framework provides a theoretical guarantee of stability regardless of delay magnitude.

Passivity Condition: The system must not generate energy — it can only store or dissipate it:

\int_{0}^{T} v^{T} F d t \geq - E_{stored} (5)

Wave Variable Transform maintains passivity under arbitrary time delay by encoding force and velocity into forward and backward travelling waves:

u = \frac{F + b v}{2 b} (6)

w = \frac{F - b v}{2 b} (7)

where $b$ is the wave impedance parameter. The wave formulation ensures that the communication channel remains passive even with variable delay, because wave energy is conserved during transmission.

4.1.5 Practical Latency Mitigation Strategies

Predictive Displays: Show predicted robot state based on command history, giving the operator immediate visual feedback of expected outcomes.

Move-and-Wait: The operator sends discrete commands and waits for confirmation before issuing the next, avoiding instability from accumulated delay.

Local Autonomy: The robot handles obstacle avoidance locally, reducing the operator’s burden under delay.

Command Smoothing: Filtering operator inputs reduces jerk and improves stability margins.

4.1.6 ROS Packages for Teleoperation

Several standard ROS 2 packages provide ready-made teleoperation capabilities:

teleop_twist_keyboard: Publishes Twist messages from keyboard input. Installed via ros-humble-teleop-twist-keyboard, launched with ros2 run teleop_twist_keyboard teleop_twist_keyboard.

teleop_twist_joy: Publishes Twist messages from joystick input with configurable axis and button mappings. Installed via ros-humble-teleop-twist-joy.

rosbridge_suite: Enables web-based teleoperation by bridging ROS topics to WebSocket connections, allowing browser-based interfaces using the roslibjs JavaScript library.

ArbiterROS web teleop (this course). The platform at https://arbiter.txio.live replaces the two CLI tools above with two browser pages that publish the same geometry_msgs/Twist to /cmd_vel through rosbridge:

/manual — minimal 2D teleop surface. Keyboard (WASD / arrow keys), on-screen virtual joystick, and USB gamepad all feed a single useROSBridge publisher. Default $v_{m a x} = 0.7$ m/s, $ω_{m a x} = 1.5$ rad/s.
/control — same command channel, but rendered on the 3D GLTF scene with the obstacle environment loaded. Use this when you need to see the robot pose and /scan overlay.

Both pages are wrappers; the wire format is still the standard Twist described above. This matters for Lab 1 (inspecting the rosbridge WebSocket frames) and for the reflection question asking where latency enters the loop.

4.1.7 Safety Considerations

Safety in teleoperation requires multiple layers of protection:

Emergency Stop (E-stop): A hardware button that cuts power to motors, independent of software.

Deadman Switch: The robot stops immediately if the operator releases the designated button, preventing runaway motion during communication loss.

Velocity Limiting: Maximum speed is capped based on the operating environment. Tighter limits apply in confined or populated spaces.

Geofencing: The robot is restricted to a defined area, with autonomous stopping at boundaries.

Watchdog Timer: If no command is received within a timeout period, the robot autonomously stops.

Script Implementation (Watchdog Safety):

# Watchdog timer stops robot if no command received
        # Publishes zero-velocity Twist after timeout
        
        class SafeTeleop(Node):
        def __init__(self):
        super().__init__('safe_teleop')
        self.cmd_pub        = self.create_publisher(Twist, 'cmd_vel', 10)
        self.last_cmd_time  = self.get_clock().now()
        self.timeout        = 0.5  # seconds before auto-stop
        self.create_timer(0.1, self.watchdog_callback)
        
        def watchdog_callback(self):
        elapsed = (self.get_clock().now() - self.last_cmd_time).nanoseconds / 1e9
        if elapsed > self.timeout:
        stop = Twist()       # zero velocity
        self.cmd_pub.publish(stop)  # command robot to halt

Integration: Theory to Practice

The theoretical concepts in this module connect directly to ROS 2 implementation. The Twist message on cmd_vel encodes the velocity mapping from Equation (1), where the input device produces $u_{human}$ and the teleop node computes the corresponding robot command. The passivity framework from Equations (5)–(7) motivates the practical safety features: the deadman switch ensures the system remains passive when the operator is absent, and the watchdog timer prevents energy injection from stale commands. Latency analysis from Equation (4) guides the selection of control mode — direct control for low-latency links, supervisory for high-latency links. The ROS 2 parameter system allows runtime tuning of velocity gains (Equations (2)–(3)) without recompiling, enabling rapid adaptation to different environments and operator preferences.

Theoretical Design Choices

The wave variable transform is chosen over simple time-delay compensation because it guarantees passivity for arbitrary and time-varying delays, whereas prediction-based methods require accurate delay models. The deadman switch implements a fail-safe passivity condition: releasing the button sets energy input to zero, satisfying Equation (5) trivially. Velocity limiting is preferred over position limiting because the Twist interface is inherently velocity-based, and velocity bounds directly constrain the power delivered to the system. The watchdog timeout of 0.5 seconds balances responsiveness (the robot does not stop during normal inter-command gaps) against safety (runaway motion is limited to at most 0.5 seconds of travel at the last commanded velocity).