Each time maximum number of valid configs changes depending on the pick up point

4 Ansichten (letzte 30 Tage)
Hello,
I am trying to generate some valid pick up configurations for a given orientation ( I have 17 different orientations to test) around some points in space with UR5e. I count them as well so that I know the exact number of valid pick up configurations around each point. The thing is, sometimes when I run the simulation for some points, it counts less or more then it did before. So let's say the result of the first execution for the point A was 16 valid pick up configs around that point, the second time it can be 13 for example instead of 16. Why is this happening ? Should I modify the solver parameters of gik to overcome this ? Because if sometimes it looks like the UR5 can't reach certain poses but other times it can so it's not really viable.
Hello,
I am trying to generate valid pick-up configurations for a given orientation with a UR5e robot. I have 17 different orientations to test around specific points in space. For each point, I count the number of valid pick-up configurations to determine the exact number of feasible configurations.
However, I have encountered an inconsistency: the number of valid configurations varies between simulation runs. For instance, for a given point A, the first execution might yield 16 valid configurations, while the second might yield only 13.
Why is this inconsistency happening? Should I modify the solver parameters of the Generalized Inverse Kinematics (GIK) solver to achieve consistent results ? How can I be sure of getting the maximum reachable configurations? Because of this problem, it appears that sometimes the UR5e can reach certain poses, but other times it cannot, which undermines the reliability of the simulations.
Thank you for your assistance.

Akzeptierte Antwort

Remo Pillat
Remo Pillat am 29 Mai 2024
Hi Denizhan,
GIK is a numeric inverse kinematics algorithm and uses a non-linear optimization under the hood. The quality of the result is based on:
(1) The solver settings specified in the "SolverParameters" property of GIK.
(2) The initial guess configuration that is provided when calling GIK. This is the initialization used for the optimization.
(3) Some randomness if random restarts are used by the solver. If the optimizer determines that the optimization starting at the initial guess does not converge, it will trigger a "random restart", i.e. restart the optimization at a random configuration. This is controlled through the "AllowRandomRestart" property in SolverParameters. By default, this is on.
The way you describe your problem, you are probably seeing an effect of (3) where different random stream configurations cause different results for the same GIK problem at different times. If you want GIK to be repeatable, you can either (a) disable random restarts by setting SolverParameters.AllowRandomRestart=0 or (b) fix the random number generator before calling GIK, e.g. by setting rng(64) to some fixed number.
Thanks,
Remo
  3 Kommentare
Remo Pillat
Remo Pillat am 30 Mai 2024
Hi Denizhan,
The initial guess is just a set of joint angles that are used as a starting point for the optimization algorithm. Since the underlying optimization is non-linear, it's not guaranteed that it converges to the global optimum, but it's possible that it will converge to local minimum that can be different for each initial guess. That's also the reason that the "random restart" mechanism significantly helps with convergence, since the optimization will try different initial guesses to find the "best" local minimum.
This is a limitation of the numeric inverse kinematics algorithm and doesn't correspond to any physical limitation of the robot's ability to reach certain poses.
For some robots, you can find analytical (closed-form) solutions to the inverse kinematics problem. An added advantage is that it can compute all possible joint configurations. See the analyticalInverseKinematics documentation page for more details.
Hope this helps.
Denizhan AKINCI
Denizhan AKINCI am 30 Mai 2024
Bearbeitet: Denizhan AKINCI am 3 Jun. 2024
Thank you for the informative and helpful answer. Just to clarify, whether or not I allow random restarts, the robot is technically capable of reaching those poses in real life, correct? If that's the case, I can keep random restarts enabled and ignore the different initial guesses (even if they are mathematically not correct because the robot has only one initial guess in real-life in this case it's homeConfiguration). This way, I can identify more "reachable" poses that the robot can achieve in real life.
I can't implement analytical IK to my code anyways because it doesn't work with UR5e (RRRRRR) apparently.

Melden Sie sich an, um zu kommentieren.

Weitere Antworten (0)

Produkte


Version

R2023b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by