0.2 time for "small" motions

[pbeeson]

So occasionally, with let's say a gripper, I've noticed that in my system, toppra might get called with [[-0.2,0.2],[-0.2-1e-6,0.2+1e-6],[-0.2,0.2]]. When this happens, no matter what the magnitude of the joint angles or the velocities or the accelerations, toppra always returns time = 0.2. This is true for any DOF and for any sized trajectory (though len(way_pts)==2 yields 5 (from algorithm.py), which I set to 1e-10, so my local version works for 2 waypoints).

[pbeeson]

In fact, there seems to be a "lower bound" on duration where for any trajectory with >=3 waypoints, the duration is never < 0.2. I can't seems to find where this might be happening in the algorithm to try to get around it.

[pbeeson]

I see solve_stagewise_optim()[0] is always 100 on these cases. Unsure as to why or what that really means at this point. Is this fixable?

[hungpham2511]

What you describe certainly sound unreasonable and should not happen. Can you provide more details? Like the gridpoints supplied to toppra and so on?

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Patrick Beeson notifications@github.com Sent: Friday, October 19, 2018 12:28 AM To: hungpham2511/toppra Cc: Subscribed Subject: Re: [hungpham2511/toppra] 0.2 time for "small" motions (#15)

I see solve_stagewise_optim()[0] is always 100 on these cases. Unsure as to why or what that really means at this point. Is this fixable?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/hungpham2511/toppra/issues/15#issuecomment-431075465, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJQ_TMM9FU6kYsoPmtjQ4gEDzwx4KgE1ks5umKxIgaJpZM4Xtxgo.

[pbeeson]

Just run your scalar_example.py with

    waypts = [[2], [2], [2]]
    path = ta.SplineInterpolator([0, 0.5, 1.0], waypts)

[hungpham2511]

Alright, so the issue comes from the internal working of toppra. Basically, the algorithm computes a velocity profile, which is a function from path position to path velocity. From this velocity, the trajectory duration is computed. Now, because of numerical instability, the maximum allowable value for path velocity must be capped, otherwise, for a path such as [0.2, 0.2, 0.2] it would be infinity. Because of this cap, there is a "lower bound" on trajectory duration.

A simple workaround for this problem is to reduces the path length in the initial interpolation like this.

waypts = [[0.2], [0.2+1e-6], [0.2]]
path = ta.SplineInterpolator([0, 0.05, 0.1], waypts)

I have also change the maximum cap velocity to 100. Now the "lower bound" is 0.02 sec for this path

waypts = [[0.2], [0.2+1e-6], [0.2]]
path = ta.SplineInterpolator([0, 0.5, 1], waypts)

and 0.006 sec for this path

waypts = [[0.2], [0.2+1e-6], [0.2]]
path = ta.SplineInterpolator([0, 0.05, 0.1], waypts)

Hope this help.

[pbeeson]

Yeah. I can catch simple trajectories where we know the robot should at move at all, but was worried how this 0.2 minimum might affect complex generated trajectories from planning that might have nearby waypoints. I think reducing this to 0.02 is good. On Thu, Oct 18, 2018 at 8:18 PM Hung Pham (Phạm Tiến Hùng) < notifications@github.com> wrote:

Alright, so the issue comes from the internal working of toppra. Basically, the algorithm computes a velocity profile, which is a function from path position to path velocity. From this velocity, the trajectory duration is computed. Now, because of numerical instability, the maximum allowable value for path velocity must be capped, otherwise, for a path such as [0.2, 0.2, 0.2] it would be infinity. Because of this cap, there is a "lower bound" on trajectory duration.

A simple workaround for this problem is to reduces the path length in the initial interpolation like this.

waypts = [[0.2], [0.2+1e-6], [0.2]] path = ta.SplineInterpolator([0, 0.05, 0.1], waypts)

I have also change the maximum cap velocity to 100. Now the "lower bound" is 0.02 sec for this path

waypts = [[0.2], [0.2+1e-6], [0.2]] path = ta.SplineInterpolator([0, 0.5, 1], waypts)

and 0.006 sec for this path

waypts = [[0.2], [0.2+1e-6], [0.2]] path = ta.SplineInterpolator([0, 0.05, 0.1], waypts)

Hope this help.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hungpham2511/toppra/issues/15#issuecomment-431214013, or mute the thread https://github.com/notifications/unsubscribe-auth/ADrfxtIAg5yJqIR4qYgK5Ry5VYiUGGLDks5umShVgaJpZM4Xtxgo .

[pbeeson]

Is there any specific reason that you might have of why I couldn't set MAXSD to 1000, then maxu, maxx to 1000^2?

It seems to work fine and gives me a nice 1ms time for any repeated points in a trajectory, which seems acceptable for my application.

[hungpham2511]

For some of my tests, these values cause numerical problems. But if they work for your application, why not.

but was worried how this 0.2 minimum might affect complex generated trajectories from planning that might have nearby waypoints.

0.02 is the worst case "minimum time" when the given path has zero derivative dq/ds over an interval of path position of 1.0.

For a complex trajectory, even if you have points that are nearly identical, chances are these points won't be spread over a significant length, and that the derivative dq/ds is unlikely to be all zero since at least one joint should be moving. In another word, at least for this particular issue, the scalar trajectory [0.2, 0.2, 0.2] is precisely the worst case. A slightly different trajectory such as

waypts = [[0.2, 0.2], [0.2+1e-6, 0.201], [0.2, 0.2]]
path = ta.SplineInterpolator([0, 0.5, 1], waypts)

would not have this problem.

[pbeeson]

I see. Well right now I only use seidel, not qpoases and I have no need for the conic solver, so it looks like all the tests in retime and seidel work with the MAXSD=1000 values, so I'll stick with them for now.

Thanks a lot.