adaptive Li damping on ikine LM?

[francogassibe]

Hi to the community and the developers of this amazing toolbox.
The 16 Sep, 2021 I cloned this repository, at the time the ikine_LM function had this cool behavior where the Li parameter adjusted itself if the error had increased or not with respect to the last q actualization.

                    # Compute possible new value of
                    qnew = q + dq

                    # And figure out the new error
                    enew = base.tr2delta(self.fkine(qnew, end=end).A, Tk.A)

                    # Was it a good update?
                    if np.linalg.norm(W @ enew) < np.linalg.norm(W @ e):
                        # Step is accepted
                        q = qnew
                        e = enew
                        Li /= 2
                        rejcount = 0
                    else:
                        # Step is rejected, increase the damping and retry
                        Li *= 2
                        rejcount += 1
                        if rejcount > rlimit:
                            failure = f"rejected-step limit {rlimit} exceeded"
                            break

I did an actualization and passed on to the 1.1 version to find out this Li parameter is no longer implemented.
I had some Cartesian trajectories to test the functioning of the toolbox and there are many of them that fail to ikine_LM (maybe due to been close to a singularity) with the new actualization. I don't know the reason to this change but i am inclined to tell that it made the algorithm more robust.
Anyone who can maybe ease my ignorance and explain me why this choice was made. Or maybe they just forgot to include it in the new versions.
Thanks on advance to all developers, this toolbox rules.

[petercorke]

Hi @francogassibe, thank you for your interest in RTB, and apologies for the very long delay in replying. Various life events got in the way, and since May this year I've been doing a lot of work across RTB, Swift and SpatialGeometry.

The change was deliberate, not an omission. The accept/reject loop with Li halving and doubling was replaced by the damping schemes described in the Manipulator Differential Kinematics tutorial papers (Part 1 and Part 2, under "Papers and technical reports"), which are also what the fast C++ solver ets.ik_LM implements. The damping is now adjusted at every step, but from the current error rather than from whether the last step was accepted:

• method="chan" (default): Wn = k·E·I, so the damping falls automatically as the error falls. Typical k is 1.0 to 0.01.
• method="sugihara": Wn = E·I + k·I, with k roughly 0.1 to 0.0001.
• method="wampler": constant Wn = k·I, with k roughly 0.01 to 0.0001.

sol = ets.ik_LM(Tep, q0=q, method="chan", k=0.1, ilimit=100)

I tried these on a Panda over a Cartesian path that ends at the elbow-straight, wrist-flat singularity, warm-starting each step from the previous solution. All three methods followed it without failures. The one case that did hurt was Sugihara with k too large (0.1), which failed on about 40% of near-singular poses, so k is worth tuning if you use that one. Note also that slimit gives random restarts when a search stalls, so slimit=1 is the harshest setting.

I can't tell from here why your trajectories fail, since I don't have them. If you still have the problem, please post an Issue rather than a discussion thread, with the robot model, a failing pose or trajectory and the call you're making, and I'll look at whether an accept/reject damping option is worth adding. In future, for bug reports please post an Issue rather than a discussion item.

Thanks for the question, and for the kind words about the toolbox.

[francogassibe]

Hi there Peter, thanks for the detailed response, I will check the papers but I think I understand the concept roughly. I no longer have those trajectories in my power since I no longer work in the company where I was implementing the trajectory generation, path finding and path planning pipelines where I was using the toolbox. So sadly I can't help you with that if your goal was to try to improve the IK of the toolbox. Nonetheless as a former user of the toolbox as a robotics teacher, everything is working pretty good, so congratulations again. Best regards Franco Gassibe El vie, 9 oct 2026 a las 22:26, Peter Corke ***@***.***>) escribió:

…

Hi @francogassibe <https://github.com/francogassibe>, thank you for your interest in RTB, and apologies for the very long delay in replying. Various life events got in the way, and since May this year I've been doing a lot of work across RTB, Swift and SpatialGeometry. The change was deliberate, not an omission. The accept/reject loop with Li halving and doubling was replaced by the damping schemes described in the Manipulator Differential Kinematics <https://docs.petercorke.com/#papers> tutorial papers (Part 1 and Part 2, under "Papers and technical reports"), which are also what the fast C++ solver ets.ik_LM implements. The damping is now adjusted at every step, but from the current error rather than from whether the last step was accepted: - method="chan" (default): Wn = k·E·I, so the damping falls automatically as the error falls. Typical k is 1.0 to 0.01. - method="sugihara": Wn = E·I + k·I, with k roughly 0.1 to 0.0001. - method="wampler": constant Wn = k·I, with k roughly 0.01 to 0.0001. sol = ets.ik_LM(Tep, q0=q, method="chan", k=0.1, ilimit=100) I tried these on a Panda over a Cartesian path that ends at the elbow-straight, wrist-flat singularity, warm-starting each step from the previous solution. All three methods followed it without failures. The one case that did hurt was Sugihara with k too large (0.1), which failed on about 40% of near-singular poses, so k is worth tuning if you use that one. Note also that slimit gives random restarts when a search stalls, so slimit=1 is the harshest setting. I can't tell from here why your trajectories fail, since I don't have them. If you still have the problem, please post an Issue <https://github.com/petercorke/robotics-toolbox-python/issues/new/choose> rather than a discussion thread, with the robot model, a failing pose or trajectory and the call you're making, and I'll look at whether an accept/reject damping option is worth adding. In future, for bug reports please post an Issue rather than a discussion item. Thanks for the question, and for the kind words about the toolbox. — Reply to this email directly, view it on GitHub <#391?email_source=notifications&email_token=ART5SXTQECFP4WJI2YKUK6T5TGF4FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2TCNBXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18845147>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ART5SXUFSUIQYMQ4GPQ5BFD5TGF4FAVCNFSNUABGKJSXA33TNF2G64TZHMZTGNBWG42TMNJ3IRUXGY3VONZWS33OHM2TGOJVGQZDHILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ART5SXSSWXFV2TBVF5AD7MT5TGF4FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2TCNBXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/ART5SXRHFZY62PZQEQPLXR35TGF4FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2TCNBXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: <petercorke/robotics-toolbox-python/repo-discussions/391/comments/18845147 @github.com>

[petercorke]

Thank you for your interest in RTB, and for taking the time to reply. The change was deliberate, as explained above, and I understand you can't take it further. I'm closing this as resolved. If you come back to it, please comment and I'll reopen it.