I added a branch with the original trifinger urdf - where the joints are specified out of order (out of order meaning not as they appear in the kinematic tree)

the jacobian tests fails for this urdf

Inverse and forward dynamics functions should agree with each other. We were testing this assumption in the following:

tau_pred = compute_inverse_dynamics(q, qd, qdd)
qdd_pred = compute_forward_dynamics(q, qd, tau_pred)

We expected qdd and qdd_pred to be very close to each other.

When we do this experiment with device=cpu, the L2 error is in the 10^-5 order. But when we use device=cuda, we get L2 errors around 0.12 which is unexpected.

I have a simple script that minimally reproduces this problem here

@fmeier @gsutanto @exhaustin

Hi,

Thank you for sharing your code! I can only run your code on CPU. Does this code work with CUDA as well?

Any clue why dynamic trajopt doesn't work?

With Adam, does not reduce the cost for a goal reaching task, even if you start very close to the goal.

run_dynamic_trajectory_opt.zip

Hi,
I'm wondering if joint of type "prismatic", defined as "a sliding joint that slides along the axis, and has a limited range specified by the upper and lower limits" are supported. I don't find on the code any behavior attached to that join, although I see it's used on the Panda and Fetch robot models: https://github.com/facebookresearch/differentiable-robot-model/search?q=prismatic

Cheers,
Marcelo

Hi there,

I am trying to understand why I fail to produce identical qdd when I use the same robot to perform forward dynamics twice.

Here is the test script:

``

n_data=100
device="cpu"
gt_robot_model = DifferentiableKUKAiiwa(device=device)
train_data = generate_sine_motion_forward_dynamics_data(
    gt_robot_model, n_data=n_data, dt=1.0 / 250.0, freq=0.1
)
train_loader = DataLoader(dataset=train_data, batch_size=100, shuffle=False)

for g in [True, False]:
    for d in [True, False]:
        
        for batch_idx, batch_data in enumerate(train_loader):
                q, qd, qdd, tau = batch_data
                
        
                qdd_pred = gt_robot_model.compute_forward_dynamics(
                    q=q, qd=qd, f=tau, include_gravity=g, use_damping=d
                )
        
                print (g, d, torch.sum(torch.abs(qdd_pred - qdd)))

printout:
True True tensor(15084.983)
True False tensor(19104.133)
False True tensor(20023.293)
False False tensor(23508.631)

Please let me know which concepts I have failed to grasp, so that I can read up on them.
Many thanks,

As of d7bd1b3, I noticed that the config this notebook referred to was missing ../conf files, then saw that they were removed per refactor in #18.

Error after rename the repo dir to differentiable_robot_model:

File "..../differentiable_robot_model/differentiable_robot_model/robot_model.py", line 20, in <module>
    import diff_robot_data
ModuleNotFoundError: No module named 'diff_robot_data'

I added an __init__.py file in the repo dir and I tried

import sys
sys.path.append('../')

But it still wouldn't import. I need to define robot_description_folder by hand for now.

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

Hello,

I have been experimenting with the compute_endeffector_jacobian method within DifferentiableRobotModel class. It seems that it can not support batch joint angle inputs, and always returns linear and angular Jacobians with shape [3, n_dof].

This issue can be reproduced by the code below:

from differentiable_robot_model import DifferentiableRobotModel
import diff_robot_data
import torch
import numpy as np
import os

rel_urdf_path = "panda_description/urdf/panda_no_gripper.urdf"
ee_link_name = "panda_virtual_ee_link"
urdf_path = os.path.join(diff_robot_data.__path__[0], rel_urdf_path)

robot_model = DifferentiableRobotModel(urdf_path)

limits_per_joint = robot_model.get_joint_limits()
joint_lower_bounds = np.array(
    [joint["lower"] for joint in limits_per_joint])
joint_upper_bounds = np.array(
    [joint["upper"] for joint in limits_per_joint])

# generate random joint angles
batch_size = 10
joint_angles = np.random.uniform(
    joint_lower_bounds, 
    joint_upper_bounds, 
    (batch_size, 7))
joint_angles = torch.from_numpy(joint_angles.astype('float32'))

# compute forward kinematics, which supports batch
ee_position, ee_orientation = robot_model.compute_forward_kinematics(
    joint_angles, 
    link_name=ee_link_name)
# prints end effector position shape: torch.Size([10, 3])
print('end effector position shape:', ee_position.shape)
# prints end effector orientation shape: torch.Size([10, 4])
print('end effector orientation shape:', ee_orientation.shape)

# compute Jacobians, which does not support batch
position_jacobian, orientation_jacobian = robot_model.compute_endeffector_jacobian(
    joint_angles,
    link_name=ee_link_name
)
# prints position jacobian shape: torch.Size([3, 7])
print('position jacobian shape:', position_jacobian.shape)
# prints orientation jacobian shape: torch.Size([3, 7])
print('orientation jacobian shape:', orientation_jacobian.shape)

Thanks,
Anqi

Dear Contributors,

Great work! I have thoroughly looked into the code and understood the following:

Step 1: First the sine wave trajectory data having (q, dq, ddq, tau) is being generated using ground truth robot model as given below:

train_data = generate_sine_motion_inverse_dynamics_data(gt_robot_model, n_data=1000, dt=1.0/250.0, freq=0.05)

Step 2: Then torque values are predicted using the learnable robot model as:

tau_pred = learnable_robot_model.compute_inverse_dynamics(q=q, qd=qd, qdd_des=qdd_des, include_gravity=True)

My query is regarding the step 2. You are computing the inverse dynamics (i.e. tau) using the same model from which you have computed the ground truth values. I think the learnable robot model should be a neural network. Please guide me regarding this.

Thanks.

Best,
Deepak Raina