IK-Geo solver

[johnwason]

I have completed a very rough IK plugin using the IK-Geo solvers. The IK-Geo library from RPI needs a lot of software engineering work before it will be ready.

https://github.com/johnwason/tesseract_ikgeo

It looks like Tesseract has very limited support for 7-DOF and higher robots. For IK-Geo, the solver can either optimize the free parameter in the IK solution, or have the free parameter specified. The free parameter can either be a joint, or some arbitrary geometric parameter. We should add a more generalized way to pass this parameter. Currently only "seed" joint angles are passed, but this is not overly helpful for the more advanced solvers that can take different parameters.

[marip8]

Do you think the specification of the joint or free paramter would happen only once (e.g., on construction of the IK solver) or on a per-call basis to the calcInvKin method?

In the case that it only needs to be set once, then you could probably just add the value of that parameter to the YAML configuration of the planner.

In the case that it needs to be provided to every call of calcInvKin, then we could modify the IK base class. How often do you think this would be used? If it's not a very common use-case, I'm wondering if it makes sense to leave the definition of calcInvKin alone for now (to minimize API breakage) and just only support automatic selection of the free parameter.

[johnwason]

The parameterization and the values of the parameter can potentially change every call. For example this paper discusses some of the issues, but there are more: https://ntrs.nasa.gov/api/citations/20240008776/downloads/Stereographic_SEW_Updated_Final%202024%2010%2009.pdf

for instance, a 7 dof robot on a 3 dof positioner have more than one free parameter, and the way the parameters are selected can vary each call.

I think this is important enough to modify the API. We can add a second virtual function with the extra parameter that by default calls the current overload so that existing subclasses are called correctly but newer subclasses can override the new overload.