Janmesh PatelRobotics software
No. 01

Low-latency robot teleoperation & constrained IK

I built a 100 Hz teleoperation system that drives a simulated Franka arm from a tracked marker, running on a Jetson Orin Nano and Isaac Sim. The goal was low latency, and safe behavior when the network or robot state goes bad.

100HzControl loop
65msCamera → arm, p50
117msCamera → arm, p95
0Logged overruns
TELEOP LOOP · 100 HzILLUSTRATIVECameraRealSense D435Posemarker trackIKDLS + null-spaceSafetysupervisorArmFranka / Isaac65 ms p50 · 117 ms p95joint state · pose · safety state → synchronized episode loge-stop · stale state · limits
Fig. 01: concept diagram, not real test data.

1Problem

The operator needs the arm to respond right away, but the camera, Wi-Fi, compute and drives each add delay and jitter. I also needed the system to stop safely when data goes stale or the link drops.

2What I built

  1. 01

    Control loop

    Camera, marker pose, constrained IK and Franka commands run at 100 Hz. The p99 loop period was 10.1 ms, with no overruns in any logged session.

  2. 02

    Network fix

    The Wi-Fi link averaged 43.4 ms ping with 85 ms of jitter. I moved control traffic to USB-C networking, which brought it to 0.35 ms average and 0.21 ms jitter.

  3. 03

    Inverse kinematics

    I wrote my own Franka forward kinematics and Jacobian, plus damped least-squares IK with adaptive singularity damping, null-space joint-limit avoidance and velocity limits. It's covered by gtest.

  4. 04

    Safety checks

    The supervisor handles e-stop, stale robot state, following error, joint limits and marker loss, and ramps motion down in a controlled way. I tested it by injecting delay, jitter, 5 to 20% packet loss and full link cuts. Recovery is latched, so it needs an explicit reset.

  5. 05

    Video and logging

    Operator video uses JPEG, which costs about 1.4 ms to encode and decode. Each session logs camera, joint, command, pose and safety-state data with synchronized timestamps.

3Result

Camera-to-arm latency came in at 65 ms p50 and 117 ms p95. The p99 loop period was 10.1 ms with no logged overruns. After the network change and drive retuning, command-to-motion p50 went from 158 ms to 30 ms.

Before and after (each row uses its own scale)BeforeAfter
MetricBeforeAfterUnit
Command → motion, p5015830ms
Average ping43.40.35ms
Network jitter850.21ms
Video bandwidth30.80.98Mbit/s
Next projectTerrain-aware navigation & vehicle safety stackQuestions about this project?janmesh.4300@gmail.com