Analytical Kinematics

[romanarust]

I am making this a draft PR to motivate discussion on the integration. I started this branch some time ago and found finally some time to continue....

This adds analytical kinematics to compas_fab for spherical-wrist and offset-wrist robots. At the moment (UR3, UR5, UR10, ABB_IRB_4600_40_255, Staubli_TX2_60L) It could help to quickly test if there are IK solutions for a frame if no backend client is available and supports the subsequent implementation of cartesian path planning or the calculation of reachability spaces.

Please see here an example of how it can be used. In this example, PyBullet is used to test if certain configurations are in collision.

I am a bit stuck because although it would be good if Analytical_InverseKinematics would inherit from InverseKinematics, InverseKinematics returns joint_positions, joint_names, defining one Configuration and not 8 ones. There are many ways how to tackle this, for example:

• change InverseKinematics and higher-level methods to be able to return 8 configurations
• add new backend interface AnalyticalInverseKinematics and subsequent higher-level methods (robot.analytical_inverse_kinematics(frame))
• ...
• I would be happy for more suggestions ;)

PS: The implementation of the IK functions is at the moment rather slow and could in the future be replaced by some fancy IK fast plugins.

What type of change is this?

• [ ] Bug fix in a backwards-compatible manner.
• [x] New feature in a backwards-compatible manner.
• [ ] Breaking change: bug fix or new feature that involve incompatible API changes.
• [ ] Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• [ ] I added a line to the CHANGELOG.rst file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• [ ] I ran all tests on my computer and it's all green (i.e. invoke test).
• [ ] I ran lint on my computer and there are no errors (i.e. invoke lint).
• [ ] I added new functions/classes and made them available on a second-level import, e.g. compas_fab.robots.CollisionMesh.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• [ ] I have added necessary documentation (if appropriate)

[romanarust]

@gonzalocasas, I've implemented Beverly's suggestions. from my side, this is done - do you want to have a look?

[gonzalocasas]

Ah! the ironpython unit testing is failing because of Pybullet, you'd need to wrap those tests around a check for if not compas.IPY

[romanarust]

I have only one suggestion that ideally we apply before merging: instead of exposing the IK_SOLVERS dictionary that contains instances of solver functions, wouldn't it be cleaner to say that the argument takes a string, e.g. ur5 and the lookup in the dictionary is internal to the analytical solver class? This would be identical to what we do with the planner_backend argument of RosClient: https://github.com/compas-dev/compas_fab/blob/main/src/compas_fab/backends/ros/client.py#L36

good point!

[gonzalocasas]

yay!! 💃 I think this is good to go as soon as Github Actions finishes building!

[gonzalocasas]

looks like the last workflow of Github Actions is stuck... I think you can go ahead and merge directly