Any support for free floating robot?

[shikui08]

Function _get_body_parameters_fromurdf treats base_link as fixed joint and the dofs are excluded. How to work with free floating robots?

[fmeier]

Hi!

thanks for reaching out! We're currently not officially supporting floating base systems, however I know of one researcher that has adapted the code-base to work with free floating robots. Let me see how hard it would be to incorporate these changes into our official library! I'll get back to you ASAP.

Best, Franziska

[shikui08]

Currently I can get around the free floating robot issue, but encountered other problems. I experiment using DifferentiableRobotModel.

One is that when calliing compute_forward_kinematics on certain end effector, the resulting position&orientation may turn out zeros&identity quaternion, which is unexpected. Instead if I call the function recursively down the kinematic chain from root to the end effector, I get expected results.

Another is that calling compute_endeffector_jacobian gives jacobian matrices that are different from either rbdl or tiny-differentiable-simulator. I can verify that rbdl&tiny-differentiable-simulator point_jacobian matrices are consistent. But inspecting compute_endeffector_jacobian result I get no clue.

Am I getting something wrong?

[fmeier]

hi!

would you be able to provide a small script that highlights the issue? which Urdf are you using? and what links are you trying to compute the Jacobians for?

we're automatically testing our forward_kinematics and Jacobian computations against pybullet (and the tests are passing) - so our kinematic computations should be consistent with pybullet at least (see tests).

[fmeier]

Please note that we just merged a PR that fixed another issue (batched Jacobian computations) that might be related to your kinematic computation issues.

[shikui08]

For the position&orientation issue, here is a sample urdf

`<?xml version="1.0"?>

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ` Code snippet: `import torch import sys sys.path.append("/home/shikui/dev/differentiable-robot-model/") import differentiable_robot_model.urdf_utils as u import differentiable_robot_model.robot_model as m model = m.DifferentiableRobotModel("/home/shikui/dev/catkin_ws/src/walker_gazebo/4/4_sim_lipm_Trans_EulXYZ_ROOT.urdf") print(model._n_dofs) tt= torch.zeros((1,38)) a,b = model.compute_forward_kinematics(tt, "LINK_thigh_r") print(a,b) a,b = model.compute_forward_kinematics(tt, "LINK_thigh_r_y") print(a,b) a,b = model.compute_forward_kinematics(tt, "LINK_thigh_r") print(a,b) ` Sample output tensor([[0., 0., 0.]]) tensor([[0., 0., 0., 1.]]) tensor([[1.1053e-01, 1.4901e-08, 0.0000e+00]]) tensor([[-0.6813, -0.0047, -0.0050, 0.7320]]) tensor([[1.1053e-01, 1.4901e-08, 0.0000e+00]]) tensor([[-0.6813, -0.0047, -0.0050, 0.7320]]) Notice LINK_thigh_r position&orientation differs.

[Tengoles]

@shikui08 So is free floating currently supported?

[shikui08]

@shikui08 So is free floating currently supported?

Hi~ Hasn't been following the updates of this repository closely. It's very possible free floating robots are still not supported, but I can't tell for sure.

[Tengoles]

@shikui08 You said in another comment that you found a way to get around the free floating robot issue. Would really appreciate some guidance on how you did it.

[shikui08]

@shikui08 You said in another comment that you found a way to get around the free floating robot issue. Would really appreciate some guidance on how you did it.

Basically I replaced the free floating base with 3 slide joints and 3 hinge joints. This allows actuation on the free floating base, which changes the behavior of the robot and might not be expected.

[ortegatron]

Hi @fmeier , I wonder which are the changes need to support free base? If you help me laying them down, we could have that as a roadmap and work it on a PR