Forward / Inverse Kinematics nomenclature

[eeberhard]

Forward / Inverse Kinematics nomenclature

Context

The robot model library has functions "forward / inverse geometry" and "forward / inverse kinematic". Currently, the "_geometry" functions refer to position, and "_kinematic" functions refer to velocity.

For me, talking about FK and IK almost always refers to position by default. I believe the current nomenclature could cause confusion and that the API should be renamed.

Justification

the lazy way

Googling forward / inverse kinematics yields many robotics related results, including the following:

For FK, https://en.wikipedia.org/wiki/Forward_kinematics states:

Forward kinematics refers to the use of the kinematic equations of a robot to compute the position of the end-effector from specified values for the joint parameters.

For IK, https://en.wikipedia.org/wiki/Inverse_kinematics states:

inverse kinematics is the mathematical process of calculating the variable joint parameters needed to place the end of a kinematic chain [...] in a given position and orientation relative to the start of the chain

Meanwhile, googling Forward Geometry primarily yields a bicycle design by Mondraker:
https://bikeboard.at/_uploads/_fotos_thumbs/thumb_99403_w670h341c0_0_670_341.jpg

a bit more academic

I also checked some of the more reputable sources I had to hand, and can attest that the FK / IK applies by default to the problem of position in:

• Theory of Applied Robotics, 2e, Jazar 2010
• Robotics, Vision and Control, 2e, Peter Corke 2017
• the ETHZ Robotics lecture notes, 2017

Counterpoint

To briefly take an opposing stance, it is not necessarily valid for FK / IK to exclusively refer to position. From Introduction to Robotics, Craig 2005

Within the science of kinematics, one studies the position, the velocity, the acceleration, and all higher order derivatives of the position variables (with respect to time or any other variable(s)). Hence, the study of the kinematics of manipulators refers to all the geometrical and time-based properties of the motion.

However, Craig still separates the chapters for position and velocity, refers to manipulator kinematics and inverse manipulator kinematics when talking about position, and has an appendix of "inverse-kinematic formulas" that deal with position exclusively.

Proposal

For the functions currently called forward_geometry, inverse_geometry, forward_kinematic, inverse_kinematic, I propose any of the following options (in the same respective order)

1. forward_kinematics, inverse_kinematics, forward_velocity, inverse_velocity
2. fk_pos, ik_pos, fk_vel, ik_vel
3. forward_kinematics_position, inverse_kinematics_position, forward_kinematics_velocity, inverse_kinematics_velocity

Preference

My ranked vote for preference would be for option 1, 2, or 3, in that order. I am happy to hear any other suggestions, counterpoints, or preferences.

[buschbapti]

Old habit never dies

[buschbapti]

I learned everything from this guy and for me it makes just a lot of sense to separate them. I wonder why this nomenclature didn't take. Actually even pinocchio in the tutorials refer to geometry vs kinematics https://gepettoweb.laas.fr/doc/stack-of-tasks/pinocchio/master/doxygen-html/md_doc_d-practical-exercises_intro.html

[buschbapti]

But then they use:

se3.forwardKinematics(robot.model, robot.data, q)  # Compute joint placements

and they don't provide the functions for the velocity part so we will never know how they would call it. I would go for

forward_kinematics - inverse_kinematics
forward_velocity - inverse_velocity (or forward_velocity_kinematics - inverse_velocity_kinematics)

[domire8]

It's an interesting discussion, personally I learned FK and IK refer to position kinematics and heard _geometry the first time here from Baptiste. I was okay with it because its a clear distinction between position and velocity kinematics but if we go ahead and want to make the library more user-friendly I agree that we should change the naming.

I kinda like Enricos proposition number two because they make clear that for both position and velocity, it's a kinematic calculation, but the abbreviations don't agree well with our naming habit throughout control_libraries. So I'm happy with proposition number one too.

[eeberhard]

Thank you for the comments. There are definitely many different views on this, but it seems that @buschbapti and @domire8 both agree that option 1 is acceptable.

In that case I move that we rename the functions, at the next convenient release, to:
forward_kinematics, inverse_kinematics, forward_velocity, inverse_velocity