Kin-Gen is a code generator for kinematics solvers for articulated robots, such as industrial manipulators or legged machines.
It is a command line tool(chain), taking as input a robot model and a user query; the first is a description of the connectivity and geometry of the robot, the second is a list of desired solvers (algorithms) to be implemented.
Implementing a solver involves numerous choices pertaining to technologies and mathematical formalism: the programming language and the layout of the digital data structures, but also the representation of orientation or the coordinate frames, among the others. We shall call them grounding choices, as they allow to ground an abstract specification (a declarative symbolic model, in the figure) into concrete code.
Traditional APIs provide an implementation for only one set of choices, or a few, as it would be unmaintainable to cover all possibilities. In addition, some of the choices are often implicit or undocumented, especially those related to the semantics of mathematical/geometrical objects (vectors, jacobians, coordinates, etc). All these issues make the integration of diverse APIs into an application more difficult.
A code generator tool relying on mechanisms for model composition (e.g. a model for the robot connectivity, a model for the geometric primitives, a model for the pyhiscal quantity kinds and units of measure), could be very configurable and allow to generate code matching exactly the desired semantics. The generated code itself would still be very poorly composable like traditional APIs, but it would fit the constraints imposed by the target environment (OS, robotics middleware, system developer's taste).
The figure in this section illustrates the current structure of the toolchain:
Besides the inputs (robot model and query), the figure shows the two components of the toolchain, the Generator and the Compiler, along with an intermediate artefact called ILK-Solver. ILK stands for Intermediate Language for Kinematics.
The ILK-solver is a key element of the toolchain. It is an imperative model of a solver, meaning it encodes the ordered sequence of operations required to compute something, but with no reference to grounding choices whatsoever. Each operation or entity referenced by the ILK-solver model is a semantic primitive (in the context of kinematics solvers), like “relative pose” or “relative velocity”; for example, an homogeneous transformation matrix is not a pose, but a possible representation of it, and as such it should not be referenced by the model whenever the concept of pose is needed; doing otherwise would introduce further, unnecessary constraints limiting the spectrum of possibilities for the code generator.
As depicted in the figure, the Generator creates the ILK-model given the robot description and the query, which tells which solvers are of interest (e.g. forward position kinematics); the query contains a declarative model of a solver, i.e. some symbolic references which can be interpreted as a kinematics solver for the given robot (e.g. “forward kinematics: position of the origin of the end-effector frame with respect to the origin of the base frame”). The Generator exploits robotics-specific knowledge to turn the declarative model into the imperative model.
The explicit and concrete representation of the imperative solver, which we called ILK-solver or ILK-model, allows to decouple the robotics-specific knowledge about kinematics solvers (in the Generator) from the logic to ground the ILK-solver into actual computer code (in the Compiler). The compiler interprets the solver model and its configuration options, and generates corresponding code in a target programming language. The Compiler does not know anyhting about the robot model, and can interpret ILK-models in isolation.
This approach is borrowed from the domain of traditional compilers, which turn code into machine instructions. What we are aiming to do with the ILK-Compiler is the same thing but at a higher level of abstraction, where the “programming language” (the ILK) is really a DSL for kinematics (and eventually dynamics) solvers.
The toolchain is undergoing active development, thus this list is going to change.
At the moment, the tool supports robots with tree topology, with prismatic and revolute joints. The query allows to request for inverse kinematics and forward kinematics solvers; forward solvers can compute relative positions, velocities, and geometric Jacobians.
At the moment, configurability of the compiler is limited to the target programming languages; C++ (with Eigen), Python (Numpy) and Julia are currently supported. The generated API, in terms of number of functions and outputs for each function, is completely customizable via the query.
Configurability in terms of digital data types and mathematical representations will be added by integrating another, complementary tool [TODO link to DConv page].
Current research related to the Kin-Gen tool is focused on the identification of the semantic primitives required to express kinematics/dynamics solvers as generically as possible, i.e. as “ungrounded” as possible. Every common operation related to the motion of multi-body systems, like the differentiation of a velocity vector, has to be exhaustively and explicitly modeled, by: separating the coordinate-free semantics from the coordinate-vector-specific operations, identifying every involved entity (e.g. a body velocity is always relative to another body), identifying the policies and choices which might erroneously be considered as constraints, but are in fact customary (e.g. the body velocity computed via a Jacobian need not use base frame coordinates).