groff treats '-' (the character you get when you hit the "minus" key on
the keyboard) as "hyphen", not as "minus". Thus it renders incorrectly
in some locales, and line-wraps strangely.
groff treats the two-character sequence "\-" as "minus", and the
four-character sequence "\(hy" as "hyphen".
Details here: https://lists.debian.org/debian-devel/2003/03/msg01481.html
This commit replaces every instance of "-" in our manpages where the
meaning is "minus" with "\-", so it works right.
This fixes many lintian warnings.
One problem frequently identified with pid is that the D term is
excessively noisy due to quantization (particularly of feedback position).
Introduce command-deriv and feedback-deriv pins. These can be connected
to some (hopefully superior) source of the derivative. For example, a
system with an analog tach signal in hal could use that value for
feedback-deriv. It also becomes easier to test different derivative
computation functions, such as explicit smoothing of the D term or
the five-point method mentioned on wikipedia
http://en.wikipedia.org/wiki/Numerical_differentiation#Higher_order_methods
Zero, one, or both of the -deriv pins may be connected. When a -deriv
pin is not connected, the related value input is computed by the
traditional two-point difference method. This means that when neither
pin is connected the behavior is the same as before (except for rounding
differences).
pid saturation is another way to detect a fault in the servo amplifier or feedback. the exact policy for fault detection via saturation is left to the integrator.
