"jerk" term needs to be clearly defined

[J-Dunn]

There is much talk of "jerk" in TinyG but this jovial unscientific term does not seem to be defined anywhere and I had to spend considerable time ploughing through complex code to infere what was being done.

While a short, four letter, word may be handy as an abreviation, it needs to be clearly defined in comments and documentation right from first useage since scientifically this really is meaningless.

The references to "third order" give a clue but still do not clearly state what is being done since it does not say third order of what. This all leaves a situation where it seems clear to someone who already knows what it is about but is very poorly defined for anyone new to the code ( which is presumably the main point of the documentation and code comments ).

It seems that 'jerk' is used to refer to rate of change of acceleration, or third time derivaitve of position. What the code does is to implement constant rate of change of acceleration and thus constant rate of change of accelerating force, rather than step changes in those quanitites that would result in hard shocks being applied to the mechanics at start and end of movements and twice that shock at the turning point in a path that does not have a cruise section.

This is major selling point for the code, especially for heavier systems with more inertial mass in gantries etc., so it would be well worth making it clear what all this is about in clear and prominent comments.

[mikest]

it's a complex concept for sure, would you be willing to explain it for the project?

Sent from my iPhone

On Dec 22, 2014, at 12:21 AM, J-Dunn notifications@github.com wrote:

There is much talk of "jerk" in TinyG but this jovial unscientific term does not seem to be defined anywhere and I had to spend considerable time ploughing through complex code to infere what was being done.

While a short, four letter, word may be handy as an abreviation, it needs to be clearly defined in comments and documentation right from first useage since scientifically this really is meaningless.

The references to "third order" give a clue but still do not clearly state what is being done since it does not say third order of what. This all leaves a situation where it seems clear to someone who already knows what it is about but is very poorly defined for anyone new to the code ( which is presumably the main point of the documentation and code comments ).

It seems that 'jerk' is used to refer to rate of change of acceleration, or third time derivaitve of position. What the code does is to implement constant rate of change of acceleration and thus constant rate of change of accelerating force, rather than step changes in those quanitites that would result in hard shocks being applied to the mechanics at start and end of movements and twice that shock at the turning point in a path that does not have a cruise section.

This is major selling point for the code, especially for heavier systems with more inertial mass in gantries etc., so it would be well worth making it clear what all this is about in clear and prominent comments.

— Reply to this email directly or view it on GitHub.

[J-Dunn]

I thought I just had.

Third time derivative may be a bit technical for most but rate of change of force should be fairly accessible, wihtout the need for degree level qualifications.

The idea of an "S-curve" is equally friendly, in a condescending Microsoft kind of way, but equally uniformative as to what it actually does or why it is beneficial. Some notes to the effect that this method produces parabolic change in speed, in contrast to the linear increase produced by simpler constant acceleration models like the basic Besenham algo, could be added.

Rather than a simple trapezoidal ramp, it speed ramps up in a parabola until the max acceleration then increases at an ever slower rate until the max speed. It then cruises or goes straight into deceleratoin in a mirror image of the accel curve.

There will be some useful refinements which could be added to this basic scheme as currently done, such as allowing a finite "jerk" at the start rather than staring from zero. This would provide a faster start and finish wth a faster total movement and minimal mechanic shock.

Now this code is out of the strict limitations of the Arduino Uno context there is a lot less need to minimlistic about the calculations.

[aldenhart]

I think your section here describes it best:

"...'jerk' is used to refer to rate of change of acceleration, or third time derivative of position. What the code does is to implement constant rate of change of acceleration and thus constant rate of change of accelerating force, rather than step changes in those quantities that would result in hard shocks being applied to the mechanics at start and end of movements and twice that shock at the turning point in a path that does not have a cruise section."

I would add: Controlling acceleration using jerk makes smooth S curve velocity profiles, as opposed to trapezoidal profiles where acceleration stops starts instantaneously.

Some background is that the term "jerk", also known as "lounce" was coined sometime in the mid 1800's to describe the forces that play when railroad cars are jammed together for coupling. In CNC terms this is like impact to the machine - like hitting it with a hammer. This impact can excite machine resonances and cause many side effects, including poor surface finish, chatter, and skipping. As well as the machine walking off the table.

The 4th, 5th and 6th derivatives of position were named by a physicist in the 1920's as "snap", "crackle", and "pop". These can be visualized as stepper and steeper S curves. They have the effect of allowing for faster acceleration than just jerk alone, while still controlling the impact terms. TinyG now operates with a linear pop motion control to take advantage of this.

[J-Dunn]

Thanks Alden, the railroad analogy points out how imprecise the term "jerk" is. The trapezoidal speed profile is a step change in force ( acceleration ),. ie. a step change to a higher value which is sustained, while the railroad collision is more like an impulse, as is a hammer blow.

I thought snap, crackle and pop was something to do with a breakfast cereal not newtonian mechanics. This all gets rather silly and it would be better remain in clear. scientific terms if the idea is to be easily and clearly communicated.

A visual representation could be done in ascii-art if it is done in terms of acceleration or force. The latter is probably the most clear to those without a science degree.

TinyG does triangular linear ramps for both the accel and decel paths whereas Bresenham is rectangular pulses ( but not spikes as in a hammer blow or rail-car ).

You are, of course, correct about the rather nasty effects this can have on the mechanics.

One thing I had roughed out in my mind was a test suite that would run each axis back and fourth at gradually increasing frequency while advancing the perpendicular axis at a constant rate. The tool would be weighted pencil.

The amplitude of the movement traced on paper would show any resonances in the mechanics and a homing check would show whether any steps were lost.

.

[J-Dunn]

The resonance test is more a test of the mechanical rigidity but would be a nice tool to add to TinyG2. It would probably be build option since it is not likely to be used once the hardware is put into to service, so could be regarded as a h/w debugging/diagnostic aid.