What is the proper way to change the location of the base of a non-free flyer robot?

[jmorrell-gs]

I know this is pretty basic, but I can't figure out how to specify the location of the base of a robot arm. I can see how to do this using a free flyer joint: robot_model = pinocchio.buildModelFromUrdf(urdf_path, pinocchio.JointModelFreeFlyer()), but I am trying to specify the location of a fixed base relative to other objects and robot arms in a scene, NOT work with a moving base. I can imagine using a free flyer joint and some awkward workarounds, but it seems like there must be a correct and better way to do this.

Another thing I tried was to set the jointPlacement property:

robot_base_pose = pin.SE3.Identity()
robot_base_pose.translation = np.array([0, 0, 0.25])

robot_model.jointPlacements[1] = robot_base_pose

This does successfully move the first joint relative to the world, but the first joint in my robot is located between the base link and the first mobile link. Moving this JOINT does not move the base LINK, leading to something like this:

when I am looking instead for something like this:

I feel like there must be a proper way to do this, this can't be an uncommon thing to do right?

[jorisv]

Hello @jmorrell-gs,

Pinocchio Model usually have the following joint structure:

Index:     0           1                  
       universe -> root_joint -> ...

universe is a virtual joint that will never be evaluated. It can have Inertia that will never be used in dynamics algorithm but will be propagated if the model is appended to another one (With the appendModel method). It also have a jointPlacement that will never be used.
We can also attach operational frame and geometry object to this joint.

root_joint is the first model joint, usually a free-flyer or a fixed joint. This joint is a regular joint (inertia attached to it will be used in all our algorithms and jointPlacement will give is original configuration).

When you modify robot_model.jointPlacements[1] you modify the root_joint initial placement. That the right thing to do to fix your issue.
What you call your base LINK is probably attached to the universe joint, that will be always attached to world origin.

To help you further, you can provide me the script or urdf you use to create you model.

[jmorrell-gs]

I don't know if I understand what you mean. I can add other types of joints, other than free flyer joints, like so:

robot_model = pinocchio.buildModelFromUrdf(urdf_path, pinocchio.JointModel())

but this still gives me an actuated joint that I now need to manage. My nq has increased, Jacobians are different, etc. What I WANT is a fixed joint, really just a relative transform between the universe and the base_link frame. But if I use a fixed joint:

robot_model = pinocchio.buildModelFromUrdf(urdf_path, pinocchio.FIXED_JOINT)

it automatically merges the base_link with the universe, I have no root_link, and I have the same problem as before:

Nb joints = 7 (nq=6,nv=6)
  Joint 0 universe: parent=0
  Joint 1 base_to_link1: parent=0
  Joint 2 link1_to_link2: parent=1
  Joint 3 link2_to_link3: parent=2
  Joint 4 link3_to_link4: parent=3
  Joint 5 link4_to_link5: parent=4
  Joint 6 link5_to_link6: parent=5

So this doesn't seem like a solution to me.

[jmorrell-gs]

Is the take-away here that you cannot have a base link? Is that just impossible to do? I suppose if needed I could just not include that link at all. It doesn't change the dynamics or kinematics, it's more important for visualization than anything else. I suppose I could manually add collision and visual geometry for the base to my visualization and collision detection and just manually position it in my scene instead of having it be part of the robot arm. Still, this feels like a weird capability to not have.

[jorisv]

Thanks for providing us a script and an urdf.

Pinocchio didn't have a fixed joint so you can't add root_joint that only hold a static transformation.

One solution can be to create an empty _base link in the URDF and connect it with a fixed joint to the real base link. The fixed joint will hold the static transform. But you will not be able to update the static transformation in your script.

Another solution is to play with the jointPlacements[1] as you did and to also modify the visual_model and collision_model to update all GeometryObject::placement attached to universe.

Something like this:

for o in collision_model.geometryObjects:
    if o.parentJoint == 0:
        o.placement = offest * o.placement

It's also possible to play with appendModel but we found a bug inside this function lately (#2805)

[jmorrell-gs]

Thank you for all the answers! I think this is something I can work with, even if it is not perfect.

I want to describe what I am working on, to give some context, because I think this behavior would be useful to add. I have a robot arm with a gripper on both ends, which can move around by attaching its base to an object, reaching around with the other gripper to grab another object, letting go with the base, and regrabbing another object (if that makes sense). This robot can move around, but it is NOT a free-flyer type floating base. The base is always rigidly attached to something, but by switching the gripper and base it can reposition itself in the world. See the video below.

I think adding a way to specify a transform for that first universe joint would be very helpful, for this and also for any case where a robot arm is mounted somewhere other than the origin. For example, if an arm was mounted overhead above a work table, or sideways, etc. Do you know any reason why this would not work well with the existing system? And if not, do you know where in the code base I should look if I want to try to implement this?

Screencast.from.11-25-2025.10.10.07.AM.webm

[jorisv]

Hello,

Sound like a funny project.

You can still use a free-flyer base to do this behavior by using contact constraints. Pinocchio support this kind of constraints to solve dynamics.
You can also use some IK solver like pink or TSID that manage this kind of constraints.
Control framework like croccodyl or aligator also manage contact constraints (and also can take care of contact friction).

If you really don't want a free-flyer you can also use the Pinocchio ModelGraph API. This is a new way to model a robot that allow to:

• Use any frame of the model as root link
• Convert $q$ and $v$ vector from models built from different base

In this script we create a kinematics chain and build a Model with the first body as root body and another one from the last body as root body.
We then convert $q$ and $v$ vector from the first model to the second.

There is few draw back:

• ModelGraph is a young API and you can find some bug inside (feedback are welcome).
• We can't build ModelGraph from URDF right now. We are waiting the next Pinocchio major release to implement this feature.