great tools for kinematic, dynamic, forces computations and simulations.

[jimy-byerley]

This is a great job in perspective, but would definitely be awesome since nothing of that matter exists for robotics.

[jimy-byerley]

target features

• new general-purpose kinematic solver
  faster, more precise, more converging, more flexible
• new joint API
  prividing force transmission, parametrization, direct and inverse resolution, and more depending on the particular joints
• kinematic graph decomposition
• kinematic DH decomposition
• kinematic import/export to URDF
• dynamic simulation functions based on kinematic

[jimy-byerley]

Currently I am hesitating between 2 designs for the end-user API of Kinematic class

intrinsics

The Kinematic class is intrisicly a solver whose main methods are

• parts(state) -> array[all_solids, 4, 4]
• solve(fixed, close) -> state
• freedom(state) -> matrix

These methods are only using the joints definitions and graph to produce an output without notion of input/output.

The input/outpu methods are helper methods relying on the previous methods

• direct(input, close) -> output
• inverse(output, close) -> input
• grad(state) -> array[input, output]

My hesitation is about the definition of the input and output spaces. Should they be both joint spaces, or should the output space be placement matrices of a set of interface solids ?

joints space as output

• direct(flatten_input_joints, close) -> flatten_output_joints
• inverse(flatten_output_joints, close) -> flatten_input_joints
• grad(state) -> array[flatten_input_joints, flatten_output_joints]

the downsides are

• higher cost of solving when input/output has solids poses, because it is adding 4*3=12 variables to the solver each solid, and thus increasing the dimension of the probleme to solve.
• less convenient for the end-user when using solids poses because the flattened variables need to be restructured by the user, despite this is likely to be the mainstream use of these end-user methods

solid matrix poses as output

• direct(flatten_input_joints, close) -> array[num_solids, 4, 4]
• inverse(array[num_solids, 4, 4], close) -> flatten_input_joints
• grad(state) -> array[flatten_input_joints, num_solids, 4, 4]

the downsides are

• makes it impossible to use something else than solid matrix poses as operational spaces

[jimy-byerley]

An other hesitation I have is: should the joint variables change to be a numpy.void type, with a structured dtype instead of nested tuples like now ?
a draft of joints variables as structured numpy data is on branch kinematic-dtype

[jimy-byerley]

Lets continue with nested tuples for now and solid matrix poses as output. for joint space as output, the user will still be able to use .solve() and .freedom()

For large kinematic display, this branch will need #105

[jimy-byerley]

news about this:
kinematic chains are very fast to solve and very stable

kinematic with many loops are working fine as well, but much more computational and not always perfectly stable