Restore virtual joint type to fixed in SRDF#86
Conversation
You are right, this can be seen as a regression due to my update of the config package. However, the error itself has nothing to do with it and this basically shows us that we need tests with a planar/floating joint config! Can you please provide a minimal example for the error and document it in a new issue in the moveit repository? |
Done.
I agree! It doesn't occur with Solid Primitives so it shouldn't happen with meshes.
I was afraid you were going to say that! Will do after our meeting. |
|
Thank you for the cleanup 👍 |
|
FYI the fixed joint removes these error messages when launching the demo: |
|
Yes, I was aware of that and it's the main reason why I merged this fix right away. :)
The pilz planner prints this error when it sees a multi-dof joint in the model, even if it's not asked to plan for the joint.
Now that I think about it more, that in itself can actually be considered a bug in the planner...
Anyway, thanks for pointing it out. :-)
|
The virtual joint type set to
floatingseems to break things when doing benchmarks with the moveit_ros_benchmarks package.The first issue I had was with STOMP with cartesian goal constraints which you can read here. Changing the joint type to fixed resolves the problem but it may not be the culprit.
The second issue is only occurring when I populate a scene with meshes (tried different meshes and reduced to only one). The left image is a joint constraint goal and the blue line is the path retrieved from STOMP. The left end of the path is the start state and the right end of the segment is the goal state. The left image is with the fixed virtual joint and is the correct planning scene. The right image was taken with the virtual joint as floating. This changes the TF from the world frame to the panda_link0 frame for an unknown reason. This also affects OMPL planners. Using this scene with SolidPrimitives and the virtual joint set to float dosen't produce the error, only meshes.
The comment in the SRDF says "considered fixed with respect to the robot" but the joint is floating... The first commits had the fixed type but was changed to floating here.
I did not investigate further but I can replicate the behavior everytime.