Question regarding waypoints/intermediate points

[finnBsch]

Hi, First of all: thanks for your work. I am trying to use it to generate trajectories following a previously planned path with respect to velocity, acceleration and jerk constraints in C++. I was wondering if ruckig allows to travel over intermediate waypoints without needing to provide accelerations/velocities for each point. Looking at the "test/otg_multiple.py" it seems that it needs to know the the velocities and accelerations for each waypoint.. Is there any way around that? Thanks!

[pantor]

Hi @finnBsch,

unfortunately this is currently not possible. Ruckig only supports a single target waypoint, however then guarantees to calculate a time-optimal jerk-constrained trajectory in real-time (so that it can be used in an online manner). If you want to find a trajectory for multiple, intermediate waypoints (only given their position), you probably need to relax the requirements, in particular the real-time capability. This is a very fundamental issue, as one waypoint might influence the time parametrization of the whole trajectory.

There is one (naive) approach of estimating the velocities and accelerations of the intermediate points using a heuristic, but from my point of view this does not work sufficiently. In many cases, the trajectory is far from time-optimal and the path overshoots between waypoints. I think TopiCo implements this approach and it might work in your case too.

You probably want to have a look into offline trajectory generation, which is however mostly not jerk-constrained. Commonly, a robot calculates (1) a time-optimal trajectory without jerk-constraints and (2) smooths the trajectory afterwards. There are some open-source C++ libraries for the first step, e.g. by Kunz, which is also integrated into MoveIt.

[finnBsch]

Thank you for that quick reply. Okay I understand. I am new to this area as I am doing a project at uni which is why I am not familiar with the common approaches. I don't need the real-time capability. I managed to achieve the time optimal trajectory with velocity and acceleration constraints already, however I don't quite understand how to smooth it afterwards to reduce the jerk. Any advice on that? The robot we're using requires us to keep the jerk within a limit. In fact, it's the same you described in your paper regarding ruckig.

[pantor]

In the most simple way, the smoothing of a trajectory can be implemented as a low-pass filter. A more solid and complete approach is e.g. described in Trajectory Planning for Automatic Machines and Robots in chapter 3.4.4 On-line computation of the double S trajectory.

When using the Franka robot, you should be able to use MoveIt to plan your trajectories (or time parametrization) without major problems. In my experimence, the MoveIt trajectories are smooth enough to be executed on the Franka. When you're only interested in applying the trajectory, this would be the easiest way.

[finnBsch]

Ok thank you. That leaves me with one last thing: We used the implementation by Tobias Kunz you mentioned earlier which resulted in the panda sometimes stopping due to the jerk being too high (even though we limited the acceleration and velocity to 5% of what the manufacturer says). Those trajectories are supposed to be smooth already and maybe I am mistaken but I don't quite see yet how additional smoothing would help?

[pantor]

The algorithm by Tobias Kunz (as it is in the GitHub repo) is not jerk-constrained, so it's not directly useable on the Franka robot regardless of the velocity and acceleration limits. An additional low-pass filter on the position output will always smooth the motion (in the sense of constraining its third derivative), of course with the cost of more inexact and slower motions. Franka even does that in libfranka, that's what the cutoff_frequency in the control method of the robot is for. However libfranka is not sufficient to filter out acceleration discontinuities. I think (but I'm not 100% sure) that MoveIt does that somehow. Did you try Kunz's algorithm via MoveIt or by implementing your own controller using his repo?

[finnBsch]

Ok I understand.. We used Kunz's algorithm using his repo, no MoveIt involved..