Open jimy-byerley opened 7 months ago
target features
Currently I am hesitating between 2 designs for the end-user API of Kinematic
class
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 ?
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
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
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
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
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
This is a great job in perspective, but would definitely be awesome since nothing of that matter exists for robotics.