-
Notifications
You must be signed in to change notification settings - Fork 13
Implementation of new skill to apply joint torque #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
mohitsharma0690
left a comment
There was a problem hiding this 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.
franka-interface-common/include/franka-interface-common/definitions.h
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
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. |
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.