-
-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jerk Limits #133
Comments
Hi, jerk limits are hard to handle during optimal time-parametrization. At the moment I can only suggest that you smooth the velocity profile before re-parametrize the geometric path. |
@dbodily1 Please refer to the following paper for a discussion on third-order constraints (which include jerk bounds): H. Pham, Q.-C. Pham. On the structure of the time-optimal path parameterization problem with third-order constraints. ICRA 2017 |
It seems that jerk constraints in joints space are too hard to be managed (the problem is not convex anymore, at least with the actual formulation). For practical usage even a regularization factor could be enough.
An higher order model could be used too (or using speed as optimization variable). Do you think it's a possible way to extend the algorithm? |
I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: What do you think about? |
@hungpham2511 In regards to your much earlier comment, is your recommendation to smooth the path paramaterization (squared path velocity) prior to generating time stamps? |
It's definitely a possible approach. |
Certainly non-linear optimization is a possible extension. It might not yield the globally optimal solution, but in reality, the locally optimal one is usually good enough. |
Would you be able to recommend an approach(s)? In this case even jerk reduction while still maintaining sane kinematics would be sufficient. |
@hungpham2511 , also curious if we can constrain the torque rate in the planning process? |
Hi, in practice I think smoothing the acceleration profile should produce some reasonable results. It should perhaps be done in the space of the Alternatively, you can try "interpolate" or smooth the function |
Basically, they are constraining |
Yeah actually that could work too. I remember trying that sometimes ago. However we would need to be careful regarding the sequence of velocities that the FIR filter is applied on. Ideally it should be w.r.t to time and not position. However it is not straightforward how to apply FIR w.r.t time for this problem actually. |
Actually, one can apply the FIR to |
Sound great. Do you use low-pass FIR? If you don't mind contributing the code that would be awesome. |
The basic idea is to cascade a fir filter. The parameterization result goes into the buffer first. The commanded I do have a Matlab file demonstrating the idea, as appended. I haven't put together the fir filter with TOPPRA, but I think it's okay to do so. |
I’ve actually tried using LP filtering s vs t many different ways and unfortunately it does not work very well. The first issue is the phase shift introduced by the filter will actually cause both limit violations and arbitrarily change ending conditions. You can use zero-phase shift filtering but we still have the issue of limit violations in many cases, especially in the middle of the paths (this is because the filter also reduces deceleration, causing velocity violations in some circumstances). A zero phase filter could probably work for pure single waypoint joint moves but beyond that it won’t work as intended if using for complex/arbitrary paths…but then again for a simple joint move it’s trivial to just use a properly constructed quintic spline for the trajectory instead of an algorithm… |
Exactly the same experience that I had. Does anyone have any experience with a similar library called rugkig? Apparently they can do jerk limit motion. |
Hey yes I found that the community version of Ruckig for things like velocity control, single goal point motions, dynamically changing goal point motions, and “move process, constant speed” type motions works reasonably well. It breaks down when you have intermediate waypoints but still require the fastest possible trajectory through those waypoints. The non-free edition can support intermediate waypoints but only a few in practical terms, and you lose optimality (more waypoints result in drastically slower trajectory times). It is essentially a modernization of the old Reflexxes library that i suspect is no longer available because the original author now works at Intrinisc.
|
I had some experience with Reflexxes library. Kroger wrote a book (Onlie) explaining the idea. The problem solved, as quoted from the book
As I remember, the algorithm considers only constant constraints. I doubt if they can be extended to handle cartesian constraints such as linear speed or torque constraints. The algorithm targets scenarios when switching to and from sensor-guided / sensor-guarded motion are necessary, in which case no predefined path is available anymore, which is different from TOPPRA.
|
@xbaosong Could this constrain torque-rate? |
Hi, I've currently researched TOPP concerning third-order constraints. I've read the paper "On the structure of the time-optimal path parameterization problem with third-order constraints". I am interested in this work, and I intend to compare your work with mine. Is it possible to share the codes of TOPP3? That would help me comprehend your method and compare the methods rigorously. |
A forwarded email below for people interested into this topic (time-optimized, jerk-limited motion planning library):
|
Thanks. Look pretty intriguing. Does anyone have experience with this library and perharps has any familiarity with their technical approach? |
The about page links to the following pages:
Ruckig compares trajectories to TOPP-RA, see: |
Nice! Thanks for the reference @s-trinh Ruckig's velocity profiles look rather intriguing. I have not seen any path-constrained algorithms producing velocity/acceleration profiles looking that simple. Look like they modify the path as well. As a disclaimer I have not read their paper. |
I tried ruckig. It is primarily for joint-space interpolation. It does not handle well paths defined by dense points in space. |
Now I'm trying the approach in: It solves a sequence of LPs integrating forward and backward. Maybe it could be redesigned in the Reachability Analysis framework as TOPP-RA. What do you think about? |
Sorry I have not had the chance to work through this paper. Please share your experience, it might be useful for others who are interested in this as well. |
The method described in that paper requires a second-order trajectory as input. The computation time is reasonable (~1sec on 1.8GHz CPU). This method might be a nice extension for TOPP-RA. |
There are methods based on dynamic programming (DP), e.g.: "“Nearly optimal path following Does anybody here have experience with DP? I am wondering whether such approaches can be efficiently solved on GPUs. |
I've been trying to implement that approach. However, it seems like a very important part is missing in the paper: How does one connect the forward (eq. 18,19) and backward (eq. 20,21) jerk profiles inside a path segment? I don't see why they should even meet. |
Hi @maxpla3 , I read this paper too. In my opinion, after transforming jerk limits into linear acceleration constraints, we need to do forward calculation with linear acceleration constraints to get FV, and do backward calculation with linear acceleration constraints and velocity contraints FV to get BV. BV is feasible veloctiy with jerk limits. |
Hello, @Linjackffy I also read this paper. I have two questions on eq.16 : |
@lower19 , @Linjackffy , from the plot in the paper, it seems the acceleration is not ensured to be zero at the start and end of the path? |
I've asked to the authors about this problem some time ago. Here their answer (not too clear for me): In this paper, the initial and final accelerations are obtained from the backward and forward passes, which is basically the TOPP-RA algorithm. The proposed approach in the paper is adopted to handle the jerk constraints between the start and the end, while the start and the endpoints are actually neglected (because these two endpoints are not identified as constraint violating points by Eq. (18)). To solve this drawback, I think two extra zero-acceleration grid points can be added to the start and the end respectively, then Eq. (18) can be used to identify the jerk violations at the endpoints, and the proposed method can be used to eliminate these constraint violations. Without solving this point I think the algorithm is quite useless... |
Do anyone try to use the nonlinear filter to filter the TOPPRA s−t curve? the refer paper is "Third Order System for the Generation of Minimum-Time Trajectories with Asymmetric Bounds on Velocity , Acceleration , and Jerk". it looks Ok? @hungpham2511 @EmanueleSiego |
Curious if you've seen a way to extend this into Jerk limiting applications. Your current implementation assumes unbounded jerk no?
The text was updated successfully, but these errors were encountered: