@Julian,
Thanks for creating a test configuration. This is really helpfull.
I’ve been dealing with an issue related to acceleration spikes in the HAL scope output for joint.0-acc-cmd and joint.1-acc-cmd during runtime, specifically when interpolating splines. I wanted to share the problem, its root cause, and the solution I’ve implemented in case it helps others facing similar challenges.
The Problem:
When interpolating lines or arcs, the HAL scope output for joint.0-acc and joint.0-acc behaves as expected. However, when interpolating splines, I observe acceleration spikes in the HAL scope. These spikes are problematic and can lead to undesirable behavior in the motion system.
Root cause:
The issue arises from how splines are interpolated. Splines are typically interpolated based on their total length, which is calculated by evaluating a finite number of points (e.g., 20 points) along the spline trajectory. Unlike lines or arcs, the absolute length of a spline cannot be calculated mathematically in a straightforward manner. This also applies to more exotic curves.When the spline is treated as a series of connected line segments (a "linestrip"), each segment has an angle relative to the next. These angular changes cause abrupt direction changes during interpolation, resulting in acceleration spikes. The same issue occurs if the spline length is pre-calculated and interpolated from t=0 to t=1 acceleration spikes still appear in the output.
Possible solutions:
- Filtering Acceleration Spikes:
One approach is to filter out the acceleration spikes by using a stepgen backend for XYZ joints. However, this is more of a workaround than a true solution.
- Restricting Curve Types:
Another option is to use only curves whose lengths can be calculated absolutely (e.g., lines and arcs). While this avoids the problem, it limits the flexibility of the system.
My Solution: Arc-Strip Interpolation
After much thought, I designed a solution that allows the use of any smooth algorithm or exotic curve without introducing acceleration spikes. Here’s how it works:
- Waypoint Generation:
The curve is transformed into a fixed number of waypoints (e.g., 21 waypoints). The number of waypoints can be adjusted (e.g., 9 or 51) depending on the desired precision.
- Arc-Strip Interpolation:
At runtime, an arc-strip interpolator processes these waypoints. The interpolator treats the curve as a series of connected arcs rather than lines. For example, 21 waypoints can be divided into 7 arcs (since each arc requires 3 waypoints). The total length of these arcs is known absolutely, eliminating the need for approximate length calculations.
By treating the curve as a series of arcs (an "arc-strip"), the system avoids the abrupt direction changes that cause acceleration spikes. This approach maintains smooth motion and works well for a wide variety of curves.
Why This Works:
- Smooth Transitions: Arcs inherently provide smoother transitions between points compared to straight lines, reducing abrupt changes in direction.
- Absolute Length Calculation: The total length of the arc-strip is known precisely, avoiding the approximation errors associated with spline length calculations.
- Flexibility: This method can be applied to any curve type, including exotic curves, as long as it can be represented by a series of waypoints.
Conclusion:
This solution has resolved the acceleration spike issue in my system and allows for the use of complex curves without compromising motion quality. I hope this explanation and approach can help others facing similar challenges. If anyone has further insights or alternative solutions, I’d love to hear them!
