Hi rmu,
In case of feed override, for the current executing segment, we can initially relax the condition to have jerk limited transition to the new feed rate. Assume that acceleration can be changed instantaneously only when the feed override is changed. We can relax this condition later (not so hard to do once the remaining formulation/algorithm is clear).
On Feedrate change, we take the current executing segment. We already know the current position, velocity and acceleration and how much distance is left to be executed in the current segment.
We make a smaller segment of that size and insert it (not actually insert but use it in the optimization as the current segment) into the Queue for optimization.
Now there are 2 scenarios:
1. Feedrate has increased from the previous value: In this case we need to consider a complete plan to get to the new feedrate by running tpRunOptimization function with the part of the current smaller segment as the first segment.
2. Feedrate has decreased from the previous value: In this case also we need to replan by calling the tpRunOptimization with the current smaller segment as the first segment.
This call to tpRunOptimization can be done in the motCommandHandler function where the tpRunOptimization is generally called when the incomming command is tpAddLine or tpAddCircle etc,. OR it can be called independently at the start of emcmotController function.
The purpose of the tpRunOptimization is as follows:
Iterate through all the segements on the list from front to back and back to front and set the following 3 velocities,
a. segment start vel
b. segment end vel
c. segment max vel.
For jerk limitation, we can add a step to this process itself to compute the polynomials for each segment for executing a trapezoidal profile. So we will get 3 second order polynomials (t-polys or only polys) for each segment which are accel_poly, const_vel_poly and decel_poly. The polys could be zero time i.e., the poly actually does not get executed.
For executing, based on the time tick, we get a new value of the planned position from the current poly and keep advancing the polys in the queue once the segments finish executing.
This part gets us done with Trapezoidal type planner with second order polynomials. The math for this is easy enough to workout and I will have a short white paper on this soon for the benefit of our community.
Now here is the actual jerk limitation (or I would rather say jerk percentage limitation).
Based on the jerk percentage allowed value set from config, we can modify all the accel_poly and decel_poly to be broken into 3 more 3rd order polynomials (s-polys). Given the starting vel, ending vel, and time of execution, we can make 3 new polys that will keep the area under the accel curve (average velocity) same as well as the time of execution the same. For doing this we will have to increase the max acceleration to a maximum value 2 times the maximum acceleration specified. This maximum value is directly related to the percentage of time the first and third polys spend in increasing and decreasing the accel vlaue to the max value. If we specify jerk percentage as 50% max violation is 2xa_max. else the violation is lower.
We iterate through the trapezoidal polys in the segment queue and find any that have an acceleration transition (from max_accel to 0 accel or vice versa) and those polys we break into 3 more 3rd order polys. There are 3 cases we need to handle on this:
1. prev t-poly is 0 accel and curr t-poly is amax accel.
2. curr t-poly is amax accel and next is 0
3. prev t-poly is 0 accel and curr-tpoly is amax and next toply is 0.
In all three cases we can find the 3 new s-polys and use them for execution.
NOTE: The two things we kept constant when converting from 1 t-poly to 3 s-poly has been the area under the accel box and the time it takes for execution of the accel t-poly. This means we cannot really limit the actual jerk but only limit the percentage impact of jerk. And we will be doing this by violating the max acceleration limit for a small percentage of the accel/ decel time. Though not ideal, this will be better than the current scenario of infinite jerk.
Also, if we dont want to do this, set the jerk percentage value to 0, and we have only t-polys which is the current scenario as a fallback.
This ends the basic jerk percentage limited planner.
***********************************
Now we can handle the simplification we made earlier on about accepting an infinite jerk at the point of replan i.e. feedrate change.
The assumption we made about conversion from 1 t-poly to 3 spoly was that the average accel was always at amax at the start and end of a t-poly. We may need to relax that consideration for the conversion of the first t-poly where the initial acceleration can be anywhere from 0 to 2*amax. The guiding formula during conversion from t-poly to s-poly would be
1. keep the average acceleration the same
2. keep the time of execution of the t-poly same.
I will try to write up this approach in a white paper and post as this post has become a little wieldy and long.
But it does cover the gist which is
1. replan on feed change
2. represent the segments as 3x t-polys (2nd order polynomials) which can be further broken into 3x s-polys (3rd order polynomials).
4. on switching from t-poly to s-poly, keep the average acceleration same in the segment.
5. on switching from t-poly to s-poly, keep the execution time same as the t-poly.
We could optimize on this approach a little with the accel/decel t-poly spilling over into nearby const velocity t-polys but that is for further research.
let me know your thoughts on this elaborate method for jerk PERCENTAGE limitation.
Regards,
-automata
