Jerk Limits

[danbodily]

Curious if you've seen a way to extend this into Jerk limiting applications. Your current implementation assumes unbounded jerk no?

[hungpham2511]

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.

[quangounet]

@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

[EmanueleSiego]

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. In some sense the problem here is solved as sequential 2d-LP. If the acceleration u_i is the optimization variable in i-step, maybe the following linear constraints could be added in the formulation:

u_i+1 - u_i <= J * h
u_i - u_i+1 <= J * h

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?

[EmanueleSiego]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294

What do you think about?

[thummel42]

@hungpham2511 In regards to your much earlier comment, is your recommendation to smooth the path paramaterization (squared path velocity) prior to generating time stamps?

[hungpham2511]

It's definitely a possible approach.

[hungpham2511]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294

What do you think about?

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.

[thummel42]

It's definitely a possible approach.

Would you be able to recommend an approach(s)? In this case even jerk reduction while still maintaining sane kinematics would be sufficient.

[yakunsjtu]

@hungpham2511 , also curious if we can constrain the torque rate in the planning process?

[hungpham2511]

Hi, in practice I think smoothing the acceleration profile should produce some reasonable results. It should perhaps be done in the space of the sd(s) function instead of the sd^2(s) due to the scaling issue of the latter one.

Alternatively, you can try "interpolate" or smooth the function s(t). The idea is to approximate it with a cubic polynomial with the same initial condition, minimize distance to the original function and minimize jerk via a quadratic objective.

[xbaosong]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294

What do you think about?

Basically, they are constraining $\dddot s$, which is remotely related to joint torque rate limit. For this purpose, a fir filter might do just as well on the velocity profile.

[hungpham2511]

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.

[xbaosong]

Actually, one can apply the FIR to $s-t$ curve directly, which is a direct output of TOPPRA. This little trick can readily obtain jerk-bounded trajectories (not respecting specific jerk bounds though).

[hungpham2511]

Actually, one can apply the FIR to s−t curve directly, which is a direct output of TOPPRA. This little trick can readily obtain jerk-bounded trajectories (not respecting specific jerk bounds though).

Sound great. Do you use low-pass FIR?

If you don't mind contributing the code that would be awesome.

[xbaosong]

The basic idea is to cascade a fir filter. The parameterization result goes into the buffer first. The commanded $s$ is the average of the buffer. (and of course, you can use other FIR filter).

I do have a Matlab file demonstrating the idea, as appended. fir_filter.zip

I haven't put together the fir filter with TOPPRA, but I think it's okay to do so.

[thummel42]

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…

[xbaosong]

Yeah, I think I have to agree with you on this. See below constraint violation at s = 2, 4, 6.

[hungpham2511]

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.

[thummel42]

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.

[xbaosong]

I had some experience with Reflexxes library. Kroger wrote a book (Onlie) explaining the idea. The problem solved, as quoted from the book

Although there has been much research on this objective, there is still one important question that has not been answered yet: If we consider a robot in an arbitrary state of motion, how can we calculate a trajectory, if we want the robot to react instantaneously to unforeseen sensor events?

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.

Major problems appear when all these fields are merged together: We must be able to switch abruptly at unforeseen time instants from one kind of robot control to another. If we arbitrarily switch one or more DOFs from trajectory- following control to sensor-guided control, this problem is usually a solved. By using the transfer function of a desired controller, command variables for lower-level control can be generated at any time instant. But how can we switch one, some, or all DOFs of a robotic system from sensor-guided control to trajectory-following control? If we consider a robot in an arbitrary state of motion how can we calculate a trajectory if we want the robot to react instantaneously to unforeseen (sensor) events?

[oridong]

@xbaosong Could this constrain torque-rate?

[Spencer-Huang2019]

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.

[s-trinh]

A forwarded email below for people interested into this topic (time-optimized, jerk-limited motion planning library):

Hi,

I wanted to share some exciting details about a new robot arm motion planning library. Using the Jacobi library, you can compute a time-optimized, jerk-limited, and collision-free robot arm motion plan from a start to a goal pose or following a user-defined path. And the best part - the installation process is painless through an online cloud-based version (although there is also an on-premise version if needed).

You can find the library and the documentation here: https://www.jacobirobotics.com/ To get access, fill out the form here: https://www.jacobirobotics.com/get-started

Please feel free to pass this on to anyone who might benefit from it.

Thanks, Yahav

[hungpham2511]

Thanks. Look pretty intriguing. Does anyone have experience with this library and perharps has any familiarity with their technical approach?

[s-trinh]

The about page links to the following pages:

• Ruckig - Motion Generation for Robots and Machines, Github
• Jerk-limited Real-time Trajectory Generation with Arbitrary Target States, RSS 2021
• Deep learning can accelerate grasp-optimized motion planning
• GOMP-FIT: Grasp-Optimized Motion Planning for Fast Inertial Transport, ICRA 2022
• GOMP-ST: Grasp Optimized Motion Planning for Suction Transport, videos
• SpeedFolding Learning Efficient Bimanual Folding of Garments, IROS 2022

---

Ruckig compares trajectories to TOPP-RA, see:

[hungpham2511]

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.

[maxpla3]

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.

I tried ruckig. It is primarily for joint-space interpolation. It does not handle well paths defined by dense points in space.

[EmanueleSiego]

Now I'm trying the approach in: R. Wang, Y. Xie, X. Chen and Y. Li, "Path-Constrained Time-Optimal Motion Planning for Robot Manipulators With Third-Order Constraints," in IEEE/ASME Transactions on Mechatronics.

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?

[hungpham2511]

Path-Constrained Time-Optimal Motion Planning for Robot Manipulators With Third-Order Constraints

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.

[maxpla3]

Now I'm trying the approach in: R. Wang, Y. Xie, X. Chen and Y. Li, "Path-Constrained Time-Optimal Motion Planning for Robot Manipulators With Third-Order Constraints," in IEEE/ASME Transactions on Mechatronics.

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?

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.

[maxpla3]

There are methods based on dynamic programming (DP), e.g.: "“Nearly optimal path following with jerk and torque rate limits using dynamic programming" by D. Kaserer et al.

Does anybody here have experience with DP? I am wondering whether such approaches can be efficiently solved on GPUs. Or in general: Which methods scale well on SIMD hardware?

[maxpla3]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294

What do you think about?

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.

[Linjackffy]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294 What do you think about?

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.

[lower19]

I found a new paper that could be useful to extend TOPP-RA including jerk constraint along the path: https://www.sciencedirect.com/science/article/abs/pii/S0921889021000294 What do you think about?

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 : (1) ui should be ui,max/min ? (2) if p is start point, xi,max/min and ui,max/min seem be zero, and the denominator will be zero. Could you tell me how to implement this eq or where is wrong of my opinion.

[yakunsjtu]

@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?

[EmanueleSiego]

@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...

[zhaodong1986]

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

[wjydym]

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

Hello, have you tried it? How to choose h, k, η? An algorithm for the computation (h; k; η) = f(z1,n z2,n). @zhaodong1986

[zhaodong1986]

I didn't try it as some knowledge of the paper is beyond my understanding. @wjydym