Thank you for your suggestion automata, we are aware and taking into consideration all known approaches, bi-arc, spline, clothoids, quintic etc...
These are substantial changes which may need a separate branch, or a different planner again planner_type 2 or more.
As of now we are concentrating efforts on fixing the spikes that have been reported, and I've had some success, not ready to share the code yet, probably next week, but I will share a picture of my current results, I've used mainly Rüdiger's code for testing, but also Endian's and Peter's PCW. A special thank you goes to ruediger123 for making the simple rhombus code. I love it because it's very quick to test and shows the blending issues very well. This was the original code what is now in master linuxcnc running the rhombus with G64 p0.25 to accentuate the issue
And this is same code after some blending and cubic improvements, note that YangYang's code sp_scurve itself has not changes a single dot.
As I mentioned before the main issues were not in the scurve code itself but in the architecture around it that needed to be tweaked, or possibly be rebuilt ground up, but that's for another time.
As of now the three big improvements/tweaks are:
1- making a bigger blending arc (still within G64 Pxx tolerance)
2- reduce velocity when blending (inevitable to avoid spikes)
3- limiting how much the cubic interpolation coefficient 'a' can change between segments - the cubic interpolation done after the kinematics was screwing up YangYang's smooth curves
Anyhow next week we are planning on refining and cleaning up the code, YangYang will work on tpOptimizePlannerMotions, I will do testing or real hardware not just scope reads, test latency as well. We may have a PR ready end of next week, but no promises.
Topic Author
