The software assumes that the robot begins on the Fixed Frame

[Raziel90]

I have had this problem:

As you can see the self collisions shape are spawn on 0,0,0 of the common_world frame. Unfortunately, I have not been able to find the part of the code that creates the shapes for the self-collisions.

In my robot configuration, all the collision surfaces are expressed in the world frame which is my fixed frame. I am not able to configure the software to accommodate my situation.

I think this can be fixed by adding another parameter to the config file start_here.py

[Raziel90]

I tried to include the world joint in the robot chain. It adapts the cylinders to the robot but the rest is retransformed weirdly.

[Raziel90]

I have solved the problem for myself
ptA = np.matmul(orient[0:3,0:3], ptA) + base_frame
ptB = np.matmul(orient[0:3,0:3], ptB) + base_frame

If I get some support from the authors I can help you to generalise the case and contribute:)

[djrakita]

Thanks for the comment! Yeah, this type of setup is not the easiest to set up, sorry about that. That being said, the "official" way to do this would be to make sure the base_frame offset is included as a fixed joint in the urdf, and make sure that joint is included in the joint list in the start_here / info_file. It sounds like you tried that, but my guess is that the offset joint was incorrect in the urdf. Once the fixed joint is correctly added and specified from the urdf, it should be doing the exact same computation that you manually included in the post above

[Raziel90]

Hi djrakita,
I guessed those could have been official solutions and I tried these and others. However, I was Either getting a wrong positioning of the robot (but matching collision shapes) or a wrong base position of the collision shapes.

This unofficial solution seemed to be the only working solution for me as the problem is only in the collision base_frame which is assumed [[0,0,0], [0,0,0,1]] of common_world (That is what I understood).

One could separate the world frame and the base of the chains in the start_here.py configuration.

[djrakita]

Gotcha, thanks for the additional info! Actually, I've been working on a new robot library that will include a newly implemented version of relaxedIK and other motion planners and whatnot that will handle tricky configurations like this much, much better. It should be available over the next couple of months. Glad you came up with a workable solution in the short term, and hopefully the new library will afford an even more solid and robust solution for this kind of thing in the long term

[Raziel90]

A little update:
I have been able to solve this part in some way I am having problems with the end-effector coordinates.
Indeed, If I extract the position of the end effector it is very far away (and rotated) from the actual end-effector of the robot.

Unfortunately, this makes the solution not particularly useful for my usage :(

[gabrielegiudici93]

Hi @djrakita,
I am working on the same robot as @Raziel90, but I want to use the new CollisionIK solver, can I use his trained model or do I need to train a new one? In this case, have you solved the problem reported in this issue or do I need to manually manage them?

Thanks for your support