RethinkRobotics / baxter_common

ROS Messages and robot description files for the Baxter Research Robot
www.rethinkrobotics.com/sdk
BSD 3-Clause "New" or "Revised" License
56 stars 105 forks source link

Joint head_nod should not be fixed #19

Open davetcoleman opened 11 years ago

davetcoleman commented 11 years ago

I ran into this problem with a related issue in the latest changes to MoveIt. Although that is a separate issue, it seems like the URDF should be updated on Baxter to support its screen nodding just like it can in real life. I understand the screen nod doesn't have real encoders / full rotation, but we should still be able to see these changes in rviz and gazebo.

Note: I have made the joint non-fixed in my fork of the urdf and I notice the center of rotation is currently not in the correct location.

7675t commented 6 years ago

Recently I also ran into this problem. Can I fix it by updating SDK or something?

IanTheEngineer commented 6 years ago

@7675t can you please describe your issue in a bit more detail? Baxter should work with moveit right out of the box. There are no encoders on the head nod joint, just limit switches. On top of that, no feedback is given to the rest of the system other than "nodding" or "not nodding" for this joint. It would seem to me a fixed joint is the best compromise here.

7675t commented 6 years ago

Hi, thanks,

Now I'm working on jog_control package, which aims to provide jog control for every manipulators.

It subscribes /joint_states and calls /compute_fk passing the all joint status in joint_states. compute_fk throw exceptions because Baxter publish head_nod in joint_states while the Baxter's URDF defines the joint as a fixed joint. Of course we can avoid it if we remove head_nod joint from the calling compute_fk, but it requires knowledge of which joint should be excluded. If possible, we want to make our program can run without additional knowledge. I found this Issue and I wonder if I can expect to get non-fixed version of the URDF to avoid this exceptions. Does it explains well?

Thank you,

IanTheEngineer commented 6 years ago

I found this Issue and I wonder if I can expect to get non-fixed version of the URDF to avoid this exceptions.

Unfortunately, as I mentioned above, a non-fixed head_nod joint does not make sense, as it cannot be controlled like any other joint, and we do not ever know where it is. This issue should likely be handled inside the jog_control panel itself.

7675t commented 6 years ago

OK, no problem then. Thanks!