Franka Research 3 teleoperation: remote demonstrations that respect the 1 kHz loop

The Franka Research 3 is a 7-axis arm with a torque sensor in every joint, a 3 kg payload and an 855 mm reach, sold as a research platform rather than a production cobot. Its older sibling, the Panda, is the robot in DROID, one of the largest open teleoperation datasets, and the FR3 is the research arm Franka sells today. Teleoperating it well comes down to one design decision: where the 1 kHz control loop runs, and what a remote operator is allowed to send into it.

Why FCI changes how you teleoperate this arm

Low-level control of the FR3 goes through the Franka Control Interface. FCI exchanges commands and robot state at 1 kHz, and Franka's system requirements are blunt about what that means: the round trip between your workstation and FCI, plus the run time of your control loop, plus the robot's own processing, must add up to less than 1 ms. Franka asks you to plug the workstation straight into the controller's LAN port, run a PREEMPT_RT kernel, and avoid relays in between because they add delay, jitter or packet loss.

When a packet misses its slot, FCI drops it and fills the gap: it extrapolates from previous waypoints for motion generators, or reuses the last torques for controllers. After 20 consecutive dropped packets the robot stops with a communication_constraints_violation error. Franka's troubleshooting page adds that large jumps between consecutive commands stop the motion with discontinuity errors, whether the jump came from your code or from lost packets.

Through libfranka that local controller can command joint torques (with gravity and friction compensation), joint positions or velocities, or Cartesian poses or velocities. For teleoperation, impedance control is the usual choice, and the FR3 makes it adjustable: the datasheet lists translational stiffness from 10 to 3000 N/m and rotational stiffness from 1 to 300 Nm/rad. That range matters more for remote work than for local work. With a stiff setting, a target that arrives late and slightly wrong turns into a hard contact. With a softer setting, the same error becomes a gentle push the operator can see and correct.

Three ways to drive an FR3 remotely

A 3D mouse is also possible, but nothing official ships for it on this arm. DROID's own stack is built around the Quest, so a SpaceMouse means writing a bridge that turns its twist into Cartesian targets for your local controller. Keyboard control has the same one-axis-at-a-time problem it has on every arm, and on a 7-DoF arm it leaves the elbow wherever the inverse kinematics puts it.

Control rates and latency for a remote operator

Two rates coexist on a teleoperated FR3. The arm runs at 1 kHz. The data, and the policy trained on it, usually run far slower: the LeRobot port of DROID is recorded at 15 fps, and most ACT and Diffusion Policy setups sit between 10 and 30 Hz. At 15 Hz a control step is about 67 ms, and that is the yardstick for a remote operator's round trip:

Keep the network delay out of the 1 kHz side entirely: the local controller should hold the last target, smooth toward new ones and clamp velocity, so a late packet from the operator becomes a slightly late motion rather than a discontinuity fault. Our latency guide covers budgets by task in more detail.

Software: franka_ros2, libfranka and LeRobot

Franka maintains franka_ros2 on ROS 2 Jazzy, with a ros2_control hardware interface, example joint and Cartesian impedance controllers, MoveIt configuration for the FR3, gripper support and packages for the FR3 Duo and a mobile FR3 Duo. The README calls a real-time kernel essential and recommends Docker Engine over Docker Desktop to avoid UDP timeouts.

LeRobot itself does not ship a Franka driver. Its third-party robots page lists LeFranX, an extension for a Franka arm paired with a RobotEra XHand and Quest VR teleoperation, marked as an extension that may need custom setup rather than a drop-in plugin. The same page lists a drop-in GELLO teleoperator plugin for the 7-DoF GELLO. In practice most FR3 teams wrap their existing ROS 2 or libfranka stack in a small LeRobot Robot class, or record in their own format and convert.

One data point worth knowing before you plan a dataset: in a LeRobot GitHub thread about deploying VLAs on a Franka, a lab running LeRobot on an FR3 through ROS 2 reported that smolVLA did not perform smoothly on the arm after fine-tuning, while a Diffusion Policy trained from scratch worked much better. Their guess was that smolVLA's pretraining data came mostly from small SO-series arms. Whatever the cause, it argues for collecting in-domain 7-DoF demonstrations rather than counting on a pretrained model to transfer.

Data: building on DROID

Per the DROID project page, the dataset holds 76k demonstration trajectories, about 350 hours, across 564 scenes and 86 tasks, collected by 50 people at 13 institutions on the same hardware: a Franka Panda, two ZED 2 stereo cameras for third-person views, a ZED Mini on the wrist, and a Quest 2 for teleoperation, all on a portable desk. The LeRobot port lists 95,658 episodes at 15 fps with three camera streams, joint positions, Cartesian pose, gripper state, language instructions and a per-episode success flag.

Our data collection guide covers episode structure and quality checks across arms.

What a good FR3 operator does

FR3, Panda or FR3 Duo?

The Panda is the arm in DROID, so a lot of public data and code assume it. Franka's current documentation and ROS 2 packages target the FR3, and the FR3 product page no longer mentions the Panda. If you are planning a new rig, plan it around the FR3. The FR3 Duo is Franka's dual-arm version, listed as a prototype, and franka_ros2 notes that it runs one controller at a time through the effort (torque) interface only. If you need a lighter or cheaper 7-DoF arm for the same kind of work, compare the Kinova Gen3 and the xArm 7.

How RoboPilots runs FR3 teleoperation

The arm and its real-time PC stay in your lab, wired the way Franka specifies. Operators connect to a client on your side of a VPN that sends targets at your record rate, and the 1 kHz loop never depends on our network. We agree the input device with you (your GELLO or Quest setup, or one we build with you), and we train a dedicated group of operators on your unit and your task protocol before any recorded episode counts.