Hello compas_fab !
I am looking for some guidance on how to produce a moveit configuration for the GoFa 12kg on the base of the already existing [abb_crb15000_5_95_moveit_config].
I saw @gonzalocasas signature on the repo: can you give me a hint?
Thanks for your feedback,
Marco
Hi Marco!
Nice to hear about your work on this! The GoFa model we use is the one from ROS-Industrial’s abb_experimental package: abb_experimental/abb_crb15000_support at kinetic-devel · ros-industrial/abb_experimental · GitHub.
To create moveit configs for the 10 and 12kg models we need to first get a hold of the URDF files for them (or get the parameters and create those urdfs ourselfs), and also get the meshes. I just created an issue on the ROS-I repo to ask about availability.
Once that is done, creating the moveit config is a 5’ task, it basically comes down to launching MoveIt’s setup assistant with our docker image. In this repo there’s an example of how to launch it, there’s two docker-compose files, one for the normal moveit launch and the other for launching it with setup assistant to generate the configs. It will mount the local folder so once you run it, you get the config package ready to go.
Regarding the creation of an analytical solver, that should be very easy, there are two basic types of analytical solvers in compas_fab, one is offset_wrist kinematics and the other is the spherical_wrist one. The GoFas are offset wrist, right? So we can create the correct one with DH params (which again we need to find, or figure out ourselves if we cannot find a proper source of info). This file shows how we create a bunch of these solvers for specific robot models just by defining their DH parameters.
So to summarize, the full thing to add support for these robots would be:
abb_experimentalmoveit config, which I would create as a repo in our organization because ROS-I doesn’t like to include default moveit config packages anymore on the support repos.compas_fab.The only “difficult” part is getting the URDF model in the first place, the rest is mostly a list of short tasks that can all be done in a day. I’m up for helping with any of them!
Cheers!
Gonzalo
Many thanks for making time Gonzalo, this is very helpful!
While waiting for abb-experimental, I’ll start digging in 
Cheers back!
Marco
Hi Gonzalo!
A quick update:
While waiting for the pull request to ROS, I started to look into the analytical solver.
I made a .urdf file and mesh description for the GoFa12 after finding the DH parameters, and I can import and visualize the robot in Rhino/Gh via Compas_Fab v. 0.27, only in RH7 (I made a forum entry about that).
The default Forward Kinematics solver compas_fab.robots.Robot.forward_kinematics() works fine, I therefore assume the .urdf is fine:
After some implementation starting from here I tested the compas_fab.backends.OffsetWristKinematics class with the GoFa DH parameters but both forward and inverse solvers do not work as expected (see flying frame in the image above for the FK solution).
I compared the UR10e solution with the GoFa12 one and run several unsuccessful tests. Is it possible that currently available offset wrist solvers are taylored to Universal Robots kinematic models?
I looked for alternative analytical solutions, and came across the IKFast library and OpenRAVE, which can produce robot-specific analytical solutions from urdfs. I am now giving this a try to familiarize with Docker, and, as a last resort I’ll see if I can run this.
Before going fully down that road, I’d be happy to know if there are alternative solutions.
Thanks,
Marco
Hi Marco! This might actually be close to a correct solution, the URDF and the analytical solvers need to be aligned in terms of rotations, because the analytical solvers cannot have an arbitrary rotation of the base, like the URDF allows to define. We see this situation with some URs as well that some URDF models container a 180deg rotation of the base compared to the one that ships with the robots and the analytical solver needs to also deal with that. The rotation of the URDF is source for very heated discussions, the tl;dr is that ROS does this rotation that deviates from vendor’s “reality” because they try to make all models comply to a specific orientation defined in one of the ROS Enhancement Proposals (I think it was REP-199 REP 199 -- Coordinate Frames for Serial Industrial Manipulators (ROS.org)).
Anyway, I think this is something we can fix without going the (awful) openrave route. Would you like to share your fork/branch of compas_fab with these changes for me to check them out and see if I can align them?
Cheers
Gonzalo
Hi Gonzalo! Here my new branch!
Best,
Marco
Hi Gonzalo,
I have some time to try and implement the MoveIt configuration, since I have the URDF and the meshes available. I tried to follow the link you provided in this comment, but it is not accessible:
Any chance I can find the docker image with your moveit setup assistant anywhere else?
Thanks!
Marco
