{"slug": "end-effector-action-policy-outputs-to-robot-actuation", "title": "End effector action policy outputs to robot actuation", "summary": "A developer building out-of-box fine-tuning and testing support for open-source vision-language-action models like π0 for the Lagrangian platform documented how a policy's 6D end-effector delta output must be converted into the 7 joint-space actuator commands a Franka Emika Panda arm needs. The writeup derives the full pipeline from first principles, using PD control to compute target end-effector acceleration from Cartesian position and Tait-Bryan orientation deltas, then mapping those to generalized joint forces and actuator inputs. The work addresses a common misconception that VLA outputs are simply joint-position deltas.", "body_md": "## Introduction\n\nWhile building out-of-box support for fine-tuning and testing of open-source VLAs like [π0](https://www.pi.website/blog/pi0) for [Lagrangian](https://lagrangian.cc/), one of the key challenges I came across was my lack of appreciation for the complexity involved in transforming the model output to actuator controls signals for the robot.\n\nMy naive understanding, some stemming from the lack of details in the [original π0 paper](https://arxiv.org/pdf/2410.24164v1) but mostly perhaps because of my own lack of understanding, was that the model output was simply a delta in generalized position coordinates of the 7/8-DOF arm + gripper.\n\nHowever, after facing interfacing challenges between the [pre-trained π0 checkpoint](https://huggingface.co/lerobot/pi0_libero_base) output and controlling the 7-DoF arm I wanted to, along with observing some weird behavior, I realized I couldn’t be further from the truth.\n\nThe supported Lagrangian pre-loaded π0 checkpoint uses HuggingFace’s [LeRobot π0 Libero base model](https://huggingface.co/lerobot/pi0_libero_base). A [help doc in the LeRobot Github repo](https://github.com/huggingface/lerobot/blob/main/docs/source/libero.mdx) clearly describes the output control as follows:\n\nActions: Continuous control in `Box(-1, 1, shape=(7,))` — 6D end-effector delta + 1D gripper\n\nThe proprioceptive input on the other hand is described as follows:\n\n`observation.state` — 8-dim proprioceptive features (eef position, axis-angle orientation, gripper qpos)\n\nThe control output can be interpreted as delta of the Cartesian position and orientation (in Tait-Bryan representation) of the end effector (aka eef) pose in world frame.\n\nA regular [Franka Emika Panda arm model](https://github.com/google-deepmind/mujoco_menagerie/blob/main/franka_emika_panda/mjx_panda.xml) has total 8 actuators (7 for the arm + 1 for the gripper), 7 arm joints & 2 gripper joints (with 1 of the gripper joints being redundant given the equality constraint imposed between the 2 gripper joints).\n\nEach of these above 8 actuators are SISO (single control input and single control output) joint-based actuators, which naturally drive the above joints.\n\nNow given π0 policy’s end effector control output, a natural question arises regarding how the 6-dim target end effector delta state is to be transformed to the 7-dim control input required to actually control the robot arm.\n\nThe remainder of this post will sketch out this procedure in as much exacting detail as possible, deriving everything from first principles.\n\n## Deriving end effector acceleration via PD control\n\nSay from some control policy (like π0) we have the deltas in end effector state (ignoring the gripper dynamics for now given they’re simply generalized position deltas), in terms of Cartesian position and Euler (Tait-Bryan) orientation angles. The policy is essentially saying, move whole arm such that the commanded end effector motion is complied with, that I don’t care about the specifics of the whole arm but mainly the end effector which is mainly what effects my task.\n\nTo be able to derive the actuator control input (which is our goal) we must first derive the joint space generalized forces τ which cause the same motion as that commanded by the policy.\n\nTo obtain τ we first determine the end effector’s target acceleration (in the world frame) to comply with the commanded motion.\n\nWe use PD control here for this, using the commanded/target position as input. The general equation for PD control derivation of target acceleration is as follows:\n\nHere the command acceleration vector (**a_c**) is a 6-dimensional spatial motion vector, the top 3 components representing the eef frame acceleration and the bottom 3 components representing the eef frame angular acceleration.\n\nFocusing on position only first, assume a target Cartesian position **x_d** and Cartesian target velocity **v_d**, both expressed in the world frame, then **e_p**, **e_v** are:\n\nFor calculating the error components for the orientation the equations are a bit more involved. This is because the rotation orientation of the eef frame cannot be directly derived as a delta between the rotational states whatever numbers & representation be used to capture it.\n\nAssume that the world frame is represented by **W**, the current eef frame is represented by **E** and the desired eef frame orientation is represented by **D**.\n\nHere **R^{-1}=R^T** given the orthogonality of rotation matrices. Now, from the above the rotational adjustment needed is:\n\nHere the term **R_e** can be taken to be the error correction rotation transform which transforms between the current end effector frame orientation and the desired orientation.\n\nTo be able to represent this in the 3 component vector representation we derive the axis-angle representation of this rotational error term **R_e** via the [logarithm method](https://maegantucker.com/ECE4560/lectures/lecture7.pdf).\n\nGiven the above we have:\n\nNow, onto the angular velocity error term **e_v[3:6]**. To obtain this we can simply use the difference between the angular velocity vectors. Hence:\n\nPutting it all together to obtain the **e_p** & **e_v** terms for the above PD control equation:\n\nFor π0-like control policies, desired acceleration and desired velocity terms will be set to zero in most cases.\n\nNote, this does not mean that the K_d term will be irrelevant as the end effector’s current velocity still effects the commanded acceleration inversely due to the negative sign.\n\n## Operational space control dynamics\n\nNow from the above section we have **a_c**, the command acceleration for the end effector required to comply with the command.\n\nGiven that the policy output commands and the term **a_c** describes the end effector motion only (in the world frame), to derive joint space generalized forces **τ**, we need some way to transform between the end effector motion and force terms represented in the world frame. [Operational space control](https://www.emergentmind.com/topics/operational-space-control-osc) (OSC) provides a way to do this.\n\nThe idea behind OSC is to provide a framework where the robot can be controlled directly in the task aka operational space (in our case, the end effector motion in world frame) which can then be converted to robot joint level motion and forces to be used for actually commanding the actuators. Exactly what we need.\n\nWe derive OSC equations here from first principles. Let’s assume a vector function ϕ which transforms between generalized joint position vector **q** to the end effector Cartesian position and orientation **x** i.e.:\n\nWe can differentiate on both sides to obtain:\n\nIn our case, we assume that **n_x < n_q** given that the end effector Cartesian pose vectors requires 6 numbers in total to represent while the robot arm is assumed to have anywhere from 7-8 degrees-of-freedom.\n\nFurther, differentiating again we have:\n\nThis forms the basis of our transform between the 2 sets of objects we have, joint space motion and force vectors and end effector’s / task [world] frame motion and force vectors.\n\nThe generalized equations of motion are:\n\nUsing equation (14), we have:\n\nWe now have a way to obtain the generalized joint space forces using the end effector acceleration **a = a_c**.\n\nWe can stop here for our purposes, assuming that the generalized inertia matrix **H** and the generalized bias force **C** is known. However standard formulations of OSC dynamics equations like to frame the equations using the task space inertia matrix and the task space force. To obtain this we keep going.\n\nFrom the principle of virtual work, the virtual work performed by the task space end effector force to perform the command motion should be equal to that performed by the generalized forces on the joint motion. In equations this is:\n\nFurther using (12), we have:\n\nReplacing (16) in (19):\n\nHere given the prior assumption of **J** having full-row rank the **J^T** is assumed to have full-column rank & have the pseudo-inverse as well.\n\nFurther, let’s assume:\n\nThen (21) becomes:\n\nThis is the final formulation used to describe operational space control dynamics. We can inject PD control command acceleration we derived in the prior section to obtain:\n\n## Obtaining target joint space forces & actuator control inputs\n\nNow, we’re all set. The PD control command acceleration from (1) can also be injected into (20) to obtain the generalized joint space forces:\n\nAll that remains is deriving the actuator control inputs. To obtain these, we work with [Mujoco’s actuator model](https://mujoco.readthedocs.io/en/stable/computation/index.html#actuation-model) with some restrictions for the robot arm problem domain:\n\n1. All actuators for the robot are assumed to be SISO (single-control-input-single-control-force-output) (this used to be generally true in Mujoco until very recently actually).\n2. All actuators are assumed to have joint transmissions.\n3. All joints associated with the actuators are assumed to be hinge joints.\n\nNow given the above assumptions, the transmission length for each actuator is given simple by:\n\nUsing the principle of virtual work again, the virtual work done by the actuator force output on the transmission should be equal to that by the generalized forces on the joint space configuration. Hence:\n\nThe transmission length Jacobian can be further simplified using (26), after which we have:\n\nReferencing the Mujoco documentation for actuator modeling again, we have:\n\nHere we want to derive **u** which is our actuator input control vector. Using (26) to further simplify (29), we have:\n\nUsing (28) we have:\n\nFinally, we have the actuator control input for the robot arm after starting off from the end effector position delta commands for Cartesian position and orientation in the world frame.\n\n## Using null space projection for non-task related joint control\n\nThere’s an additional matter. The Jacobian transforming between the end effector motion and joint space motion is a rectangular matrix of shape **[n_x,n_q]** . While we assumed **n_x < n_q** and full-row rank for this matrix, given its shape we have a nullspace of dimension **n_q - n_x**.\n\nThis means that we can perform hide some additional joint space motion in this null-space which would still result in remaining compliant with the commanded motion for the end-effector / task space.\n\nThis statement can be formally captured in math by modifying equation (19) from above:\n\nWe can use the equation (23) to better understand and even formally define **τ_null**. We want this null-space force to produce no motion (or acceleration) for the end effector. This can be derived by replacing (33) in (23):\n\nHere for the null-space force to generate no motion in the end-effector we need:\n\nUsing (22) we have:\n\nEquation (39) must always hold for **τ_null**.\n\nGiven this, the null-space generalized force can be seen as not interfering with the task objective motion commanded by the policy.\n\nNow, I think this is quite neat and is used for many applications, listing a few here:\n\n- Obstacle avoidance\n- Joint configuration compliance including joint limit avoidance\n- Posture control\n- Singularity avoidance\n- Energy optimization\n\nOf course, having this null-space available doesn’t guarantee any of the above additional requirements as depending on the configuration this null-space may not be as large, but it’s a nice little extra playground to be able to use.\n\nFurther, we derive a projector matrix **N_null** which can project between any generalized joint space force vector **τ_null** and project it the null space for compliance, hence:\n\nReplacing in (39):\n\nOne possible null-space projector can be:\n\n## Using open-source VLAs with Lagrangian\n\nYou can start RL fine-tuning and testing open-source VLAs like π0, π0.5, π-fast, Gr00t with Lagrangian now, with the ability to setup multi-GPU workloads, configure custom reward functions, maintain-mix-match checkpoints and datasets, track workload logs and progress metrics over the Lagrangian dashboard & more.\n\nThe fine-tuning and testing workload setup configuration & capabilities can be further checked via [the API docs](https://lagrangian.cc/docs/api/).\n\nIf interested in obtaining an API key for trial, contact us via [Lagrangian homepage contact form](https://lagrangian.cc/) or even feel free to email me directly at: [avideepgabhawala@gmail.com](mailto:avideepgabhawala@gmail.com).", "url": "https://wpnews.pro/news/end-effector-action-policy-outputs-to-robot-actuation", "canonical_source": "https://lagrangianblog.substack.com/p/end-effector-action-policy-outputs", "published_at": "2026-10-27 02:18:25+00:00", "updated_at": "2026-10-27 02:41:26.863076+00:00", "lang": "en", "topics": ["robotics", "ai-agents", "machine-learning", "ai-tools"], "entities": ["π0", "Lagrangian", "Hugging Face", "LeRobot", "Franka Emika Panda"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/end-effector-action-policy-outputs-to-robot-actuation", "markdown": "https://wpnews.pro/news/end-effector-action-policy-outputs-to-robot-actuation.md", "text": "https://wpnews.pro/news/end-effector-action-policy-outputs-to-robot-actuation.txt", "jsonld": "https://wpnews.pro/news/end-effector-action-policy-outputs-to-robot-actuation.jsonld"}}