At present, emc2 doesn't have any friction compensation. However, there
are several avenues you might go down to add it: in the motion
controller, or as a HAL component.
At first glance, it looks like the place to add this in the motion
controller would be in the function presently known as
'compute_screw_comp' in src/emc/motion/control.c. Right now, this
function computes either backlash alone or backlash plus screw
compensation, then applies a filter to it so that changes in the
compensated value are applied within a velocity and acceleration
constraint.
You would modify backlash_corr according to your friction compensation
algorithm after the screw/backlash compensation code but before the
s-curve code.
Joint velocity is not currently available in the emcmot_joint_t
structure, so it would also be necessary to find a good place to compute
this if you have to do a velocity-dependent correction.
You might also find that it is possible to place friction compensation
entirely outside the motion controller using a HAL component. You can
imagine a correction component as a box with 3 inputs and 2 outputs:
________________
joint-command >>>>>| Friction |
motor-command >>>>>| Compensation |>>>>> motor-command-compensated
motor-feedback <<<<<| Algorithm |<<<<< motor-feedback-compensated
~~~~~~~~~~~~~~~~
Motors and joints have offsets for various reasons mentioned in the
manpage motion(9). You would compute the compensation based on the
joint-command, but apply the compensation to the motor command.
The compensation algorithm basically determines a compensation amount
based on the command, and assigns
command_compensation = compensation_algorithm(joint_command)
motor_command_compensated = motor_command + command_compensation
feedback_compensation = command_compensation // (see below)
motor_feedback = motor_feedback_compensated - feedback_compensation
As long as it has no discontinuities, there's no need for an s-curve
application of the compensation like there is for backlash compensation
which is inherently discontinuous, which simplifies the component
considerably.
For the feedback_compensation value there are three main methods that
come to mind:
* use the same value as command-compensation, since the function is
continuous this doesn't introduce much error
* use the prior value of command-compensation, since the feedback
should now be the prior command position
* have a separate code path to compute an appropriate value
This component can do whatever it likes, and you hook it e.g., between
motion and pid.
Then the connections in hal end up something like this:
net a0j axis.0.joint-pos-cmd => friction.0.joint-command
net a0pc axis.0.motor-pos-cmd => friction.0.motor-command
net a0pf axis.0.motor-pos-fb <= friction.0.motor-feedback
net a0pcc friction.0.motor-command-compensated => pid.0.command
net appfc encoder.0.position-feedback => pid.0.feedback
net appfc => friction.0.motor-feedback-compensated
If you write friction compensation as a change to the emc motion
controller, we'd be happy to consider those patches for inclusion in a
future version. If you write it as a HAL component, we'd welcome the
addition of that component to the wiki ContributedComponents page,
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents
Jeff
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
