Inside a robot’s control system: from a target to a movement

Ask a robot to move a sealed carton from a bench into a tray. Identifying the carton supplies only part of the answer. The machine also needs a grasp, a reachable arrangement of its joints, a route that clears the surroundings and commands its motors can follow. Even a perfectly identified target leaves geometry and control work to do. MIT’s manipulation course deliberately introduces pick-and-place with a known object pose to teach that remaining problem.[1]

A useful way to understand the system is to follow what the instruction becomes. The details below describe a modular robot arm using familiar robotics tools. Learned systems can combine some of these decisions, but the physical requirements still provide a way to understand their outputs.

Put the observation in the robot’s coordinates

A camera and a robot shoulder describe space from different viewpoints. A carton’s position relative to the camera must be related to the arm’s base and gripper. ROS 2’s tf2 library stores relationships between coordinate frames over time and converts observations between them. It uses transforms supplied by the system; it does not discover the carton or calibrate the camera by itself.[2]

For our carton, position alone is insufficient. Its orientation affects where the gripper can approach and how it will fit in the tray. The geometric description of position and orientation is called a pose. A useful target can be the gripper’s pose relative to the carton, rather than a point in a photograph.[1]

Choose a posture as well as a destination

Forward kinematics calculates where an arm’s end will be from its joint angles. Inverse kinematics starts with a desired endpoint and works backwards to possible angles. More than one posture can reach the same point; other points have no solution. A two-link arm makes this visible.[3]

In our original calculation, the links are 30 cm and 25 cm long. They are ideal, zero-thickness links moving in one plane, with unrestricted joints and no obstacles. The endpoint can lie between 5 cm and 55 cm from the shoulder. This geometric exercise is not a tested robot design.[3]

For the first target, the solutions are approximately −5.46° at the shoulder and +71.54° at the elbow, or +58.59° at the shoulder and −71.54° at the elbow. Shoulder angles are measured from the positive x-axis; elbow angles are relative to the first link, with anticlockwise positive. Substituting the unrounded angles into the forward-kinematics equations gives (40 cm, 20 cm) in both cases. A real application then chooses a posture that also clears its surroundings; moving the tray may be more useful than changing the instruction.

Plan the space swept by the whole arm

Reaching the destination does not establish that the route is clear. MoveIt’s planning scene can check collisions between the robot’s own parts and between the robot and its environment. It also checks constraints, such as a required position or orientation. These are separate tests: an endpoint can be reachable while a particular elbow position intersects the bench.[4]

The carton also changes the moving shape after it is grasped. Our engineering implication is that the plan must represent what is travelling with the gripper, not just the empty hand. A missing object in the scene cannot influence a geometric collision check. That makes the quality of the physical description part of the motion problem.

Give the route a speed and a feedback loop

A path describes where to go. A trajectory also describes when to get there. MoveIt adds timing under joint velocity and acceleration limits. Its time-optimal trajectory generation can move waypoints slightly within a tolerance, so the documentation says additional collision checks may be needed. A later smoothing stage can limit jerk—the rate at which acceleration changes. Smoothing is therefore part of producing a movement the mechanism can execute.[5]

During execution, ros2_control’s controller manager repeatedly reads hardware state, updates active controllers and writes commands. Depending on the interface, a command may specify a position, speed or effort; another controller can operate closer to the motor. Feedback connects the desired movement with what the joints are actually doing. The division depends on the robot’s hardware and configured controllers.[6]

Franka’s research interface provides a concrete scale: it exchanges commands and measured state at 1 kHz, or 1,000 times a second, through an external computer. Its measurements include joint positions, velocities and torque signals, plus estimated external forces. That is a particular low-level interface rate. It is not a claim that a language model replans the whole task every millisecond.[7]

There is also a difference between requesting a movement and learning that it completed. The Kilted joint-trajectory controller offers an action interface with execution feedback and path and goal tolerances. A tolerance violation can abort the goal and notify the caller. Its simpler topic route does not provide the same goal-result conversation. The surrounding task software needs the result before deciding that the carton is ready to release.[8]

Where learned AI joins the machinery

Some learned action policies produce short chunks of joint positions. The Rolling development documentation for ros2_control now describes an optional processing mode that can supply timing and smooth such positions before execution. It is off by default and applies to a particular topic route. This is development documentation, not a capability to assume in every installed robot. It exposes an important connection: a model’s proposed actions still need a usable relationship with the controller.[9]

For the carton task, the complete achievement is a chain of compatible results: a target tied to the arm, a posture and route that fit the scene, motion followed with feedback, and an observed final placement. Understanding that chain makes robotics progress easier to read. A better vision model, a stronger action policy and a more reliable controller improve different parts of the same physical job.

Report an error or suggest a correction