You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I happened to come across this issue today when test driving paul-unity around with the joystick:
I saw the back_rotation joint kept moving slowly although I was not commanding anymore (I think mainly because the driver also went into QuickStop state, but I don't have proof for this). Interesting thing is the following plot where you can see, that there is still a non-zero wheel-command for the respective back_rotation joint!!!
I could also see the spikes on the velocity joint_states for various base joints:
For the rest of the time velocity joint_states is following the wheel_commands/target_velocity quite well:
@ipa-mdl
can you think of a case where this could happen?
I mean generating a wheel_command/target_velocity where just the back_rotation joint is moving seems very unlikely (see also the steep drop of all the other target_velocities - deadman released)
could this also be an issue with ros_canopen (we are using latest kinetic release)?
I happened to come across this issue today when test driving paul-unity around with the joystick:
I saw the back_rotation joint kept moving slowly although I was not commanding anymore (I think mainly because the driver also went into QuickStop state, but I don't have proof for this). Interesting thing is the following plot where you can see, that there is still a non-zero wheel-command for the respective back_rotation joint!!!
I could also see the spikes on the velocity joint_states for various base joints:
For the rest of the time velocity joint_states is following the wheel_commands/target_velocity quite well:
related to https://github.com/mojin-robotics/cob4/issues/684
@fmessmer FYI
The text was updated successfully, but these errors were encountered: