Robot Research Control Access: Position, Velocity, Torque, and Firmware Boundaries

"Open API" is one of the most overused phrases in robotics, and one of the least precise. For a research buyer, the question is never whether a platform is open in the abstract. It is whether the platform exposes the specific control layer the experiment needs, at a rate and with a feedback path that the experiment can actually use. A platform can be genuinely open for position commands and completely closed for torque control, and both statements can be true of the same robot.

This article is written for the people who buy and integrate robots for research, and it works through the decision in the order the experiment demands: translate the experiment into a required control layer, check actual commands and feedback, separate low-level access from safety authority, review timing and external-controller dependencies, clarify support and modification boundaries, and then choose the least access that meets the need. The distinction that runs through all of it is between what the software framework offers and what the hardware and firmware actually permit.

Translate the Experiment into Required Control Access

Start from the experiment, not the platform. Different experiments need different layers of control, and naming the layer is the first step.

Position-level control is where most research begins. The experiment specifies a trajectory, and the controller executes it. This is the most widely available layer and the least demanding.

Velocity-level control is needed when the experiment cares about speed profiles, smoothness, or continuous motion rather than a sequence of waypoints.

Torque commands and force interaction need their own interface checks. A joint-torque experiment requires documented torque commands and corresponding feedback. An end-effector force task may instead use a vendor force-control function or an external force sensor with position or velocity commands. Those routes expose different control authority; confirm which one the experiment actually requires.

Firmware modification is the deepest layer, and it is a distinct question from low-level control. An experiment that needs to change the controller's behavior itself is asking for access that most commercial platforms do not grant, and that may void support or licenses.

Write down which layer the experiment genuinely requires. Torque control is often requested when position control with a force sensor would suffice, and the difference decides whether a whole class of platforms is even in scope.

Check Actual Commands and Feedback

A platform's openness has to be verified against its interface documentation, not its marketing.

For each candidate, find the actual list of commands the controller accepts and the feedback streams it publishes. A platform that documents position and velocity commands but provides no torque-command specification has not established usable torque-control access for the experiment, regardless of the brochure wording. The same goes for feedback: an experiment that needs joint-torque feedback needs to confirm that the controller publishes it, at what rate, and with what latency.

Three official interfaces show why the command list matters. Universal Robots RTDE synchronizes an external application with configured controller inputs and outputs over TCP/IP, including joint, tool and safety status, I/O and registers. Reading those fields does not establish arbitrary torque-command access.

Franka's FCI documentation specifies a different interface: its C++ libfranka library sends joint-torque, joint-position or velocity, and Cartesian-pose or velocity commands at 1 kHz while receiving robot-state measurements. That rate belongs to the documented FCI configuration and requires a suitable workstation and network; it is not a rate for every Python wrapper or research robot.

For a Chinese mainland example, JAKA's SDK Developer Manual V3 lists joint-space servo_j and Cartesian-space servo_p position commands. Those named functions establish documented command types, not a universal torque interface or compatibility with every installed controller. Match the SDK revision to the quoted robot, controller and firmware, and obtain the command-and-feedback matrix for that exact configuration.

An SDK description should therefore be read as a scope of documented external functions, never as evidence that the underlying servo loop is open.

Separate Low-Level Access from Safety Authority

This is the boundary that research buyers most often misread, and it matters for both safety and procurement.

A research control interface does not authorize changes to safety configuration. Verify which limits, protective stops and operating-mode restrictions the exact controller enforces during external control, and which safeguards the experiment must supply. Torque-command access and permission to alter safety functions are separate procurement questions.

Keep the research plan within the manufacturer-supported operating conditions and the institution's safety assessment. An experiment that needs a different operating envelope requires a defined review with the manufacturer, the integrator and a qualified safety engineer before hardware trials. A supported interface still needs an application-specific risk assessment; interface access alone does not make an experiment safe.

The procurement implication is that "does it support low-level control" and "what safety constraints come with that" are two questions, and both need written answers.

Review Timing and External Controller Dependencies

Once the control layer is identified, the timing and the external dependencies decide whether the experiment can run as designed.

Protocol and rate: which protocol carries the commands and feedback, and at what rate? A loop that runs at one kilohertz is a very different tool from one that runs at a hundred hertz, and the choice depends on the dynamics the experiment is trying to control.

Latency and jitter: what is the round-trip delay, and how consistent is it? Control research that assumes a tight loop can be confounded by a network with variable latency, and the buyer should establish the real numbers by testing on the actual hardware rather than trusting a nominal figure.

Feedback: which signals come back, in what form, and how fresh are they? A position stream is not a torque stream, and a delayed stream can be worse than none for a fast controller.

Loss of connection: what does the robot do when the external controller stops responding? The safe behavior, whatever the platform defines it to be, must be understood before the experiment is connected to hardware, because an unexpected behavior during a fast motion is a safety event, not just a data error.

The general caution here is that a software framework is not a hardware capability. The ros2_control framework, for example, defines hardware interfaces with state and command handles across position, velocity, and effort, and requires an implementation that reads state and writes commands. That describes the software contract. It says nothing about whether a given robot's hardware and firmware will accept effort commands, or at what rate. A buyer who concludes "ros2_control supports effort, therefore this robot supports torque control" has confused the framework with the machine. The hardware question has to be answered by the robot's own interface documentation, per model.

Clarify Support and Modification Boundaries

Research often pushes toward modification, and modification raises questions that procurement should settle in advance.

If the lab changes the controller's configuration, adds a custom control layer, or modifies firmware, does the manufacturer still support the robot? Does the change affect the warranty, the safety certification, or the software license? Can the change be reverted, and how? Which functions or features depend on the original configuration and may stop working after a change?

These questions have real answers, and the answers differ by vendor. Some platforms publish a supported path for external control and encourage research use within it. Others treat any modification outside the vendor toolchain as unsupported. The buyer's job is to get the answer in writing for the specific model, before the experiment depends on it.

This separates cleanly from a related question the buyer may also be asking: software licensing and data rights. That is a different topic, about what the buyer may do with the software and the data, and it should be clarified too, but it is not the same as the control-access question. Keep them separate, and the answers will be clearer.

Select the Least Access That Meets the Experiment

The final step is to resist the pull toward the most open platform and instead match the access to the need.

Build a table. One column per experiment requirement: position tracking, velocity profile, torque or force interaction, high-rate feedback, external control loop, firmware change. Then one row per candidate platform, with the documented access level for each requirement, the rate, the feedback available, the support status, and the safety constraints. The cells should be filled from interface documentation and, where it matters, from a test on the hardware.

What usually emerges is that the experiment needs less than the buyer first assumed. Many control studies that begin as "we need torque control" turn out to need position or velocity control plus an external force sensor, which opens up far more platforms. Others genuinely need torque access, which narrows the field sharply and makes the interface documentation the deciding document.

Choosing the least access that meets the experiment is not a compromise. It reduces unnecessary integration work and avoids paying for capability the lab will never exercise. Confirm the supported configuration and modification terms in writing before committing to the platform.

Check the Exact API Before Choosing a Research Robot

Share the experimental command modes, required feedback fields and rates, controller firmware and preferred ROS 2 or external-control stack. AIsirRobot can coordinate available interface specifications with manufacturers and flag missing command permissions, update policies and integration responsibilities. This is interface planning, not a promise to unlock hidden controller functions. Coordinate the research-control interface review.