Skip to content

Conversation

@Ruthrash
Copy link

@Ruthrash Ruthrash commented Sep 13, 2023

This PR implements a new skill that applys desired joint torque passed from the frankapy server. I pass a minjerkjointtrajectory generator as the trajectory generator to the skill but it is not used at all. The desired joint torque is sent from the frankapy server through TorqueControllerSensorMessage and is applied after clipping with torque limits.

Copy link
Contributor

@mohitsharma0690 mohitsharma0690 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the long delay. Thanks a lot for your contribution. The code on a glance looks ok but i am not super sure if the controls are smoothly being applied (see comment). Nevertheless, if you can clean up the code and address the comments I can quickly try it on our end before merging.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove this file from the review.

}
log_counter += 1;
if (log_counter % 1 == 0) {
pose_desired = robot_state.O_T_EE_d;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this logging required here? also pose desired may not really be correct at this stage.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this was necessary for logging robot states. I double checked O_T_EE_d and O_T_EE are the same in this stage

current_joint_rotatums_[i] = -max_joint_rotatums_[i] * safety_factor;
}
}
current_joint_torques_[i] = previous_joint_torques_[i] + current_joint_rotatums_[i] * period;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this logic really discontinuous, i.e. at t = 0, we have 0 torques and then just directly at the next state we have a large torque value?
Since this code seems to be doing q_t = q_{t-1} + dt * (q^{desired}_{t-1} - q_{t-1}) / dt (basically combining 25 and 34). or am I missing something here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine,

  • at t = 0 we are applying 0 torque (libfranka applies torque to cancel gravity in backend) and at t = 1, we are limiting the commanded torque by limiting joint_rotatum to a fraction of the maximum in case it is greater than maximum joint_rotatum. This should limit discontinuity.
  • Please let me know if you think otherwise or if you think this could be done in a better way.

@Ruthrash
Copy link
Author

Hey @mohitsharma0690! Apologies for getting so late to reply, I was travelling for the most part of the time after your change requests and I didn't have access to the franka robot. Thanks so much for your comments, I have incoporated the changes you have asked and have addressed some of your concerns. Please get back to me when you could.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants