Closed zongyaojin closed 2 years ago
Also, the URDF parser doesn't support PLANAR joints. Could you fix that?
Hi @zongyaojin
why the libraries chose to reverse the sign? Are there any benefits outweighing this confusion?
I don't know and I don't think it has any benefits. Maybe @jorisv can shed some light on this choice as he is the original author of this code.
Also, the URDF parser doesn't support PLANAR joints. Could you fix that?
Sure but I am rather busy at the moment. Do you have some samples of URDF files using the planar joint? In RBDyn the planar joint is assumed to be along the z-axis so we might have to bake-in the axis from the URDF description.
Hi @gergondet,
I don't know and I don't think it has any benefits. Maybe @jorisv can shed some light on this choice as he is the original author of this code.
Thank you very much for the clarification!
Sure but I am rather busy at the moment. Do you have some samples of URDF files using the planar joint? In RBDyn the planar joint is assumed to be along the z-axis so we might have to bake-in the axis from the URDF description.
Understood. I don't have one either. Back then I was just thinking of an application where a robot arm is attached upside-down to an XY linear trail on the ceiling of a warehouse environment doing sorting or object-picking type of things. In that case, if planar joints are supported in the URDF, people don't have to manually create them. Anyways, thank you very much for your reply!
In the FD and ID libraries, the fictitious acceleration due to gravity is set as follows:
sva::MotionVecd a_0(Eigen::Vector3d::Zero(), mbc.gravity);
However, in Roy Featherstone's book, p94, and p95 equations (5.15) (5.19), it uses
a_0 = - a_g
; just curious, why the libraries chose to reverse the sign?It's a little confusing to users because we have to set
mbc.gravity = {0, 0, 9.81}
instead ofmbc.gravity = {0, 0, -9.81}
, which is what people would normally assume. Are there any benefits outweighing this confusion?