Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jimy-byerley opened this issue Dec 6, 2023 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@jimy-byerley
Copy link
Owner

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

@jimy-byerley jimy-byerley self-assigned this Dec 6, 2023
@jimy-byerley jimy-byerley added the enhancement New feature or request label Dec 6, 2023
@jimy-byerley
Copy link
Owner Author

jimy-byerley commented Jan 3, 2024

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
Copy link
Owner Author

jimy-byerley commented Apr 7, 2024

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

news about this:
kinematic chains are very fast to solve and very stable
image
kinematic with many loops are working fine as well, but much more computational and not always perfectly stable
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: in progress
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant