Is your feature request related to a problem? Please describe.
We have issue where jerk is not limited on the trajectories executed on the hardware. This leads to the difficulties in some cases. Especially where JTC is used for trajectory interpolation it is not sufficient to have limiters towards the hardware, but also the limiter has to be integrated within the JTC itself to properly calculate the next interpolated position.
Few years ago we were working on this but never finish up. There are two main tasks to do:
Describe the solution you'd like
The code has to be exceptionally well tested. This is a perfect task for the Test driven development. Therefore, it is recommended to first write the tests with the evaluation and then start writing code that should satisfy those tests.
First part is straightforward with extending the limiter with accepting jerk limits from the .yaml file as done for other limits and add maths for it to it. Here is extremely indispensable to have clan, understandable code and concepts with literally every single line tested. This means that clear test cases with comprehensive documentation about their values should be added. The target code should come in SturationLimiter class. Also, when the current code is analysed the checkboxes in this issue should be marked as finished.
The JTC integration of the limiters should be plugin based as done on the jtc-add-joint-limiter on b»robotized fork. This is the simple part, the complex part is to integrate this with the interpolation defined in JTC. The referenced branch also links to the different versions of interpolation adding new object for this, but now with time-distance, I am not convinced that should be done any more (see interpolation_mkethods.hpp file).
Describe alternatives you've considered
We could use external libraries for this like Ruckig of Reflexxes, but they generally make things more complex that is required. Therefore, we should avoid doing that.
Is your feature request related to a problem? Please describe.
We have issue where jerk is not limited on the trajectories executed on the hardware. This leads to the difficulties in some cases. Especially where JTC is used for trajectory interpolation it is not sufficient to have limiters towards the hardware, but also the limiter has to be integrated within the JTC itself to properly calculate the next interpolated position.
Few years ago we were working on this but never finish up. There are two main tasks to do:
SaturationLimiterin joint_limits package to support the jerk limiting. For this is quite important to consider all 7 dynamic cases as the limited jerk propgates back to the commanded positions.Describe the solution you'd like
The code has to be exceptionally well tested. This is a perfect task for the Test driven development. Therefore, it is recommended to first write the tests with the evaluation and then start writing code that should satisfy those tests.
First part is straightforward with extending the limiter with accepting jerk limits from the
.yamlfile as done for other limits and add maths for it to it. Here is extremely indispensable to have clan, understandable code and concepts with literally every single line tested. This means that clear test cases with comprehensive documentation about their values should be added. The target code should come inSturationLimiterclass. Also, when the current code is analysed the checkboxes in this issue should be marked as finished.The JTC integration of the limiters should be plugin based as done on the
jtc-add-joint-limiteron b»robotized fork. This is the simple part, the complex part is to integrate this with the interpolation defined in JTC. The referenced branch also links to the different versions of interpolation adding new object for this, but now with time-distance, I am not convinced that should be done any more (seeinterpolation_mkethods.hppfile).Describe alternatives you've considered
We could use external libraries for this like Ruckig of Reflexxes, but they generally make things more complex that is required. Therefore, we should avoid doing that.