Closed ecmjohnson closed 9 months ago
@ecmjohnson The changes explain themself, however, out of curiosity, did you get this message when the robot is moving? or when it is steady?. I'm asking because the velocities are non-zero
@ecmjohnson The changes explain themself, however, out of curiosity, did you get this message when the robot is moving? or when it is steady?. I'm asking because the velocities are non-zero
@saikishor These are the commanded velocities published in the trajectory_msgs::msg::JointTrajectory
message by the send_trajectory
node. I think they should be non-zero even if they will be overwritten by the positions
@ecmjohnson I'm just asking if the copy of message you have in the description after the fix is during the execution of the trajectory or not?. Because of course it doesn't make sense that your initial or final state of the trajectory is with non-zero velocities.
If this is the case, the resulting velocities could be due to the planner we are using.
Thank you
@saikishor Sorry, I must be misunderstanding something. The send_trajectory
publishes a trajectory_msgs::msg::JointTrajectory
which will be executed by the controller, so I guess in this case the message would be sent prior to execution of the trajectory.
The single point I included from the trajectory may be confusing. I included a single point (the last from before ros2 topic echo
truncated) just to show that the velocities
field is no longer identical to the positions
field. The full message published by the send_trajectory
node after these changes has neither 0 velocities at either start or end point, and also exceeds the double total_time = 3.0;
:
@ecmjohnson thanks for the information. Fine then the issue is coming from the solver itself. Let's wait for @christophfroehlich to review and then we can merge it
I had a quick look. The IK solver is called with a twist in tool frame and generates a velocity vector in joint space, which is then integrated to positions. That's why the velocity is not zero in the end: one should probably add another field to the message with the last position (is discarded now) and zero velocity. Maybe the hardware plugin should be improved in a future PR using both position+velocity fields.
Thank you @christophfroehlich
Resolves #427 by copying joint velocities into the trajectory point's velocity field. This makes no functional difference for the r6bot controller when both position and velocity are provided as shown by @christophfroehlich here.
Tested by echoing the
/r6bot_controller/joint_trajectory
topic. Prior to the change, bothvelocities
andpositions
were always the same:After the change, the
velocities
andpositions
differ:No difference in the example is observed.