You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, this project is fantastic, it seriously helps with DIY arm development! I'm mostly asking if this is something within the purview of this library, but how do y'all feel about supporting interpolated values between two points, your current, and target position? I'm working on a pick and place (of a sort) robot, and a large part of the job is picking up items from one or several places, and placing it into a narrow, deep container. I know fora fact when I first got my homemade ik model off the ground, the arm would like, "swing" into position, and the only way around it was instead of one movement, many shorter segments of movements that shortened the amount the arm could "swing" (I'm sure theres a technical term I'm butchering, sorry).
I'm imagining an option in inverse_kinematics() that takes some sort of a parameter for tokenizing the movement into a list of movements. Maybe the value is a numSegments integer, or the default length unit, like millimeters per segment. Taking the concept to the nth degree so it doesnt feel like for loop syntactic sugar, I'm envisioning that target could be a list of values, so the model could be animated at a higher level, maybe even supporting velocity suggestions calculations given a max velocity value, maybe even per axis?
If thats outside of this libraries mission, I totally get it, just wanted to know if you guys were open to those sort of features as pull requests.
The text was updated successfully, but these errors were encountered:
Actually that's a very interesting feature, and certainly to be added in IKPy!
A few quick thoughts:
I'm pretty sure i've written a simple snippet in the past, that splits a trajectory into multiple target positions. However, i'm unable to find it after a quick lookup 🤷
IMO the main difficulty of this feature is a design constraint: To be more precise, we want to add the notion of trajectory into IKPy, which can immediately translates into a sequential list of target positions, but can also be a more abstract object (i.e. a continuous trajectory is a curve, that can also includes velocity information)
Once we have a curve, it's easy to sample from it to get the list of targets;
So the main issue is "How to define a curve in a simple ikpyesque ( ;) ) way?": There are many ways to define curves, but maybe choosing the right one is not so easy
For example, with your picking robot, you want your robot to follow a certain trajectory (i.e avoiding colliding your walls), instead of going in an undefined line between your starting position and your target
What are your thoughts on this?
Especially, how would you define your trajectory in your use case?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
First off, this project is fantastic, it seriously helps with DIY arm development! I'm mostly asking if this is something within the purview of this library, but how do y'all feel about supporting interpolated values between two points, your current, and target position? I'm working on a pick and place (of a sort) robot, and a large part of the job is picking up items from one or several places, and placing it into a narrow, deep container. I know fora fact when I first got my homemade ik model off the ground, the arm would like, "swing" into position, and the only way around it was instead of one movement, many shorter segments of movements that shortened the amount the arm could "swing" (I'm sure theres a technical term I'm butchering, sorry).
I'm imagining an option in
inverse_kinematics()
that takes some sort of a parameter for tokenizing the movement into a list of movements. Maybe the value is a numSegments integer, or the default length unit, like millimeters per segment. Taking the concept to the nth degree so it doesnt feel like for loop syntactic sugar, I'm envisioning that target could be a list of values, so the model could be animated at a higher level, maybe even supporting velocitysuggestionscalculations given a max velocity value, maybe even per axis?If thats outside of this libraries mission, I totally get it, just wanted to know if you guys were open to those sort of features as pull requests.
The text was updated successfully, but these errors were encountered: