Closed ahendrix closed 11 years ago
[wim] Are we sure we want to start supporting all different types of joints? It can get very complex very fast. Thinks about joint limits, joint safety code, etc, there are many many ways to specify those for multi-DOF joints. Also, the number of joints you'd need to support will get quite large. I like the approach where you can construct any multi-DOF joint by combining single-DOF joints. A ball joint can be created using two rotational joints. Any thoughts?
[sglaser] I agree with Wim. More complex joints will increase the complexity of the urdf spec and of the handling code.
What does the state of a ball joint look like? What does the command look like? Is there a transmission, and what does it look like? When a realtime controller wants to command the ball joint, how does it get access to it and what does the control code look like? How are the safety limits specified?
There's too many uncertainties around adding this joint, and I think they need to be worked out before we add a joint type to the urdf spec. Is there a clear need for a ball joint?
[hsu] Thanks for the inputs. Motivation is mainly driven by limitations from chaining multiple single-DOF joints. Doing so requires pseudo-links between pairs of joints; and further, each pseudo-link needs finite mass if the corresponding dynamics were to be simulated in ode. But as you mentioned, complete support of multi-DOF constraints in ROS does appear to be quite a daunting task. I am closing the ticket for now in favor of reducing ball joints to two or three collocated hinge joints until a more urgent need arises.
Phantom hand has a ball joint. This should not be too hard to do.
trac data: