Support for floating base?

[blooop]

Does Curobo have support for a floating base?

If not, is it theoretically compatible to extending it to support planning with a floating base?

Thanks,

[balakumar-s]

Floating base is supported. cuRobo does this by adding translation (x,y) and rotation (z) joints at the base of a robot. You can add kinematic joints to the base to also support z translation.
Example:

curobo/src/curobo/content/assets/robot/franka_description/franka_panda_mobile_xy_tz.urdf

Line 9 in d85ae41

<joint name="base_x" type="prismatic">

Here is an example configuration file: https://github.com/NVlabs/curobo/blob/main/src/curobo/content/configs/robot/franka_mobile.yml

[blooop]

Thanks.

That is not quite what I meant by floating base. I meant in a similar way to how pinocchio implements it, i.e the 6-DoF state of the robot is recorded in the robot state, but not via joints in the URDF.

https://gepettoweb.laas.fr/doc/stack-of-tasks/pinocchio/devel/doxygen-html/md_doc_c-maths_b-joints.html

it has a "floating joint" at the bottom of the page.

For example, could curobo create plans for humanoids, quadrupeds or segway type robots with the method you suggest? It would need to plan without being able to explicitly control the "fake" joints.

Could that be partially achieved by removing the fake joints from the cspace parameter in the RobotConfig?

[balakumar-s]

I think this can be done in two ways in cuRobo.

Option 1: Use lock joints

cuRobo has lock joints which will lock specified actuated joints at a fixed value and optimize only the other joints. We do this in the Franka to lock the gripper here:

curobo/src/curobo/content/configs/robot/franka.yml

Line 102 in d85ae41

lock_joints: {"panda_finger_joint1": 0.04, "panda_finger_joint2": -0.04}

You can use this to lock any joint. So adding 6 joints at the base of the robot (1 for each axis) and then locking them by reading the pose from a robot_state is possible. You can also choose to optimize over them by not locking them.

One caveat is that currently we rebuild the kinematic tree every time the joint values of the locked joints change (this can take up to 0.1 seconds).

Option 2: Change relative transform between robot and world

Each obstacle in the world (including the nvblox map) have a pose w.r.t. robot. You can change the transform based on the robot state. This is not a clean solution compared to Option 1 but will be faster as transform updates are essentially tensor copies.

[justagist]

Is there a plan to add official support to floating base systems? I agree option 1 seems to be a more suitable solution, but adding 6 additional joints to the URDF of the robot does not sound ideal and can cause issues when loading in other simulators etc. Wouldn't it be cleaner to provide the option for adding a floating joint to the curobo robot state representation?