Skip to content
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

Joint head_nod should not be fixed #19

Open
davetcoleman opened this issue Sep 9, 2013 · 5 comments
Open

Joint head_nod should not be fixed #19

davetcoleman opened this issue Sep 9, 2013 · 5 comments

Comments

@davetcoleman
Copy link

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
Copy link

7675t commented Jun 17, 2018

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

@IanTheEngineer
Copy link
Contributor

@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
Copy link

7675t commented Jun 18, 2018

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
Copy link
Contributor

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
Copy link

7675t commented Jun 18, 2018

OK, no problem then. Thanks!

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

No branches or pull requests

3 participants