Non-cubic results for non-cubic trajectories

[pbeeson]

So, I was looking to use your repo in our system, and in doing some testing, I noticed some strange things in very simple test cases. I think this boils down to the fact that you enforce a cubic spline, which might not actually be an ideal fit for many trajectories.

For instead a very 1-DOF trajectory of 0,10 with max_vel and max_accel of 3 and 4, it takes 4.07 seconds. Reasonable. If a make this a 3 points trajectory of 0,5,10, I get the same answer. Now, If I make it 0,1,10, I get not only a different time (5.05s), but now the system moves negative in velocity and position at the start and goes very negative (-0.5 in position is 5% the wrong direction) and stays at a negative position for 1.2 seconds of the entire motion. This just seems wrong. After careful planning, it may be that the system simply cannot go negative here (which brings up another point of why there aren't max/min joint position conditions?). I realize that this is due to the original cubic spline which makes a dip down. I've looked and unfortunately for cases like this, where we might want a different model, I haven't found anything suitable in scipy (though PYthon really isn't my strong suit, so I don't know the libraries well). Also I tried the PPoly and Univariate models, with the simple case above but these both result in Python runtime errors. Any help would be appreciated.

[pbeeson]

Lots of testing with just scipy shows that PchipInterpolator works much better than Cubic. It handles the situation above well, and handles even "osciallting" trajectories like a sine wave. However, there's something with your /solver than doesn't like PchipInterpolator curves. Perhaps because the second derivaties aren't guaranteed to be continuous.

[pbeeson]

Also, I have noticed that the acceleration values (with your current head) don't seem to be limited by the a_max I provide. fore example, run vel 3, acc 4, and a 1-DOF trajectory of 0,10,50,100 and you'll notice that there are accels of >4.5

[hungpham2511]

Thanks for reporting the issue. Can you attach a script that contains the test cases/issues that you face? I will gladly look at them.

By the way, are you able to run the examples? Just to make sure that the installation works fine.

[hungpham2511]

Hi @pbeeson, I have tried the scenarios you described. The main issue is that the construction of the geometric path by a CubicSpline is not always the best option, or the only one. In any case, different people will have a different preference when it comes to interpolating paths, so toppra leaves it to the user to implement the Interpolator.

Please take a look at this note if you want to do that. https://hungpham2511.github.io/toppra/tutorials/1_geometric_path.html

However, this:

Also, I have noticed that the acceleration values (with your current head) don't seem to be limited by the a_max I provide. fore example, run vel 3, acc 4, and a 1-DOF trajectory of 0,10,50,100 and you'll notice that there are accels of >4.5

is very strange. It should not happen at all. Can you provide more details on that experiment?

I implemented the scenarios in a new example scalar_example.py in the lastest commit and did not find any problem with the velocity or acceleration.

[pbeeson]

Thanks for looking into this. I’ll try to follow up within a few days.

To be honest, I am using the topp_ros package in between my examples and your code, so there could be a translation issue with accelerations on the way back from your trajectories to a ROS trajectory. I’ll look more later. I had good luck with the Pchip spline, which obeys the joint ranges of the provided trajectory, and I would recommend that you consider that as the default. However in using that spline, it is definitely the case where I saw crazy large acceleration values, and occasionally I found corner cases where get_duration() would fail for some reason when using that spline. On Sun, Oct 14, 2018 at 3:47 AM Hung Pham (Phạm Tiến Hùng) < notifications@github.com> wrote:

Hi @pbeeson https://github.com/pbeeson, I have tried the scenarios you described. The main issue is that the construction of the geometric path by a CubicSpline is not always the best option, or the only one. In any case, different people will have a different preference when it comes to interpolating paths, so toppra leaves it to the user to implement the Interpolator.

Please take a look at this note if you want to do that. https://hungpham2511.github.io/toppra/tutorials/1_geometric_path.html

However, this:

Also, I have noticed that the acceleration values (with your current head) don't seem to be limited by the a_max I provide. fore example, run vel 3, acc 4, and a 1-DOF trajectory of 0,10,50,100 and you'll notice that there are accels of >4.5

is very strange. It should not happen at all. Can you provide more details on that experiment?

I implemented the scenarios in a new example scalar_example.py in the lastest commit and did not find any problem with the velocity or acceleration.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hungpham2511/toppra/issues/9#issuecomment-429607548, or mute the thread https://github.com/notifications/unsubscribe-auth/ADrfxqQW9xktojRALnm3077AQfHjsUrNks5ukvoXgaJpZM4XaveN .

[quangounet]

Hi PBeeson. TOPP ROS is based on TOPP (https://github.com/quangounet/TOPP), not on TOPP-RA. TOPP has a number of bugs and is no longer supported.

[pbeeson]

No it supports toppra too. On Sun, Oct 14, 2018 at 7:54 AM Cuong notifications@github.com wrote:

Hi PBeeson. TOPP ROS is based on TOPP (https://github.com/quangounet/TOPP), not on TOPP-RA. TOPP has a number of bugs and is no longer supported.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hungpham2511/toppra/issues/9#issuecomment-429624171, or mute the thread https://github.com/notifications/unsubscribe-auth/ADrfxnnO75PPZeeFmGMquVUVP2SgOz68ks5ukzQbgaJpZM4XaveN .

[pbeeson]

It’s just a simple python ROS node that converts a ROS trajectory to your your spline and calls your compute function and then converts back to a ROS trajectory. On Sun, Oct 14, 2018 at 8:00 AM Patrick Beeson beeson.p@gmail.com wrote:

No it supports toppra too. On Sun, Oct 14, 2018 at 7:54 AM Cuong notifications@github.com wrote:

Hi PBeeson. TOPP ROS is based on TOPP (https://github.com/quangounet/TOPP), not on TOPP-RA. TOPP has a number of bugs and is no longer supported.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hungpham2511/toppra/issues/9#issuecomment-429624171, or mute the thread https://github.com/notifications/unsubscribe-auth/ADrfxnnO75PPZeeFmGMquVUVP2SgOz68ks5ukzQbgaJpZM4XaveN .

[pbeeson]

In the future to help highlight issues, I’ll build directly off your examples.py On Sun, Oct 14, 2018 at 8:01 AM Patrick Beeson beeson.p@gmail.com wrote:

It’s just a simple python ROS node that converts a ROS trajectory to your your spline and calls your compute function and then converts back to a ROS trajectory. On Sun, Oct 14, 2018 at 8:00 AM Patrick Beeson beeson.p@gmail.com wrote:

No it supports toppra too. On Sun, Oct 14, 2018 at 7:54 AM Cuong notifications@github.com wrote:

Hi PBeeson. TOPP ROS is based on TOPP ( https://github.com/quangounet/TOPP), not on TOPP-RA. TOPP has a number of bugs and is no longer supported.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hungpham2511/toppra/issues/9#issuecomment-429624171, or mute the thread https://github.com/notifications/unsubscribe-auth/ADrfxnnO75PPZeeFmGMquVUVP2SgOz68ks5ukzQbgaJpZM4XaveN .

[pbeeson]

Ok @hungpham2511 I see the problem now. TOPP_ROS was simply taking any trajectory I was sending and was dividing up the spline into even sectioned N intervals between 0 and 1. So when I was sending 0,1,10, it was making a spline with x, 0,0.5,1. This was forcing the spline to move outside the starting/stopping y values of the spline, which was my original issue. So your note at the top of scalar_example about aligning waypoints is not done properly by topp_ros.

Additionally, the accels/velocities all look right when I make examples from your scalar_examples, so that must be a bug in topp_ros too. I'll just roll my own vesion of topp_ros since it's trivial anyways.

But, if you change CublicSpline in intrepolator.py with PchipInterpolator, and run scalar_example.py, you'll see the accel issues I was talking about. I'm convinced this is because Pchip Splines aren't guaranteed to be smooth in the second derivative (and I don't need to use thise if I set my spline intervals properly).

I guess the only issue now is how to best set up the spline intervals at waypoints. This should be easy to do.

Thanks for the help.

[pbeeson]

Oh, BTW, your new example uses ipython at the end, but that isn't included in your requirements.txt