search

machinekit / machinekit-hal

Universal framework for machine control based on Hardware Abstraction Layer principle
https://www.machinekit.io
Other
109 stars 62 forks source link

Synchronized trajectories across HAL instances are not possible #74

Open ArcEye opened 6 years ago

ArcEye commented 6 years ago

Issue by luminize Mon Aug 31 09:37:01 2015 Originally opened as https://github.com/machinekit/machinekit/issues/742

When multiple machines need to execute a synchronized path (like 2 robots which must work together) it is not possible to start and synchronize movement at the same time.

Since at this time joint constraints for non-trivial kinematics are not obeyed https://github.com/machinekit/machinekit/issues/438 plus it would be difficult to have a robot constraining its peers the logical thing would be to off-line plan the motion and feed the segments to the interpolator.

However, there then needs to be a common starting point of the motion

ArcEye commented 6 years ago

Comment by mhaberler Mon Aug 31 13:32:22 2015

To distribute such a job over several HAL instances on different hosts, each driving a machine, for coordinated motion to happen I think the following prerequisites are needed:

The latter requirement mandates a synchronized clock on all HAL instances, and possibly a motion command to start a playout at a given point in time. As the trajectories and their time/vel/acc properties are precomputed the motion of the machines should reflect the planning result.

A suitable vehicle for time-syncing HAL instances is the IEEE1588 protocol (aka Precision Time Protocol) which was specifically designed for this purpose - syncing hosts over Ethernet-type media down to the sub-microsecond range.

Fortunately a PTP implementation is available in the debian package stream (apt-get install ptpd). Here is a debian configuration example .

Reference material: NIST website on IEEE1588 talk on PTP this refers to another implementation but the principles apply National Instruments white paper on IEEE1588

Source repo of ptpd: https://sourceforge.net/p/ptpd/code/HEAD/tree/trunk/ Wireshark PTP hints Hardware packet timestamping can improve accuracy: overview of embedded processors which support hw timestamps it seems the Beaglebone with the Xenomai 3.8 kernel in fact does support this (see ethtool -i eth0)

ArcEye commented 6 years ago

Comment by mhaberler Mon Aug 31 13:55:24 2015

To make an IEEE1588 synchronized clock usable in HAL we need to

the clock is simply accessed by the clock_gettime() family of calls; this is in fact the call supporting rtapi_get_time() with RT-PREEMPT, so on this RT kernel no extra facility is needed

For Xenomai2 it seems the Posix skin and clock_gettime(CLOCK_HOST_REALTIME) would be the method to access the machine time as managed by the linux kernel.

The estimated error of the synchronisation can be retrieved by the adjtimex() system call (esterror field of the timex structure ) and also displayed in the shell with adjtimex -p (apt-get install adjtimex).

One way to go about this would be a userland component which retrieves the esterror value periodically (eg a few times per second) and mirrors this value in a HAL pin. Everything else like thresholding and estop can go from there. Also, the return value of adjtimex(2) could be used as a criterion (see man 2 adjtimex, section Return Value ).

Coordination between all HAL instances will be needed to establish a global HAL nodes sychronized - coordinated trajectory playout can begin - property.

ArcEye commented 6 years ago

Comment by slickqt Fri Nov 6 00:42:17 2015

we see use M code for sync the action in commercial product,that is one sync position is a M code, for example with 10 sync position, we set M160-M170 as sync point, when the first machine reach that point it wait until the other machine get to that point, when them get to same point, they will run continue. example: machine 1: G0 X100 M160;(machine 1 is ready,sync with machine 2) G0 X200; ..... M161;(another sync point with machine 2)

machine 2: G0 Y300; M160;(sync with machine1) ... M161;(sync with machine 1)

ArcEye commented 6 years ago

Comment by luminize Fri Nov 6 13:12:50 2015

I think that is not a full synchronisation between machines. If you use it like this, then you can do waiting between machines. But what i don’t see in your solution is how you will make sure that both machines are synchronised on the entire path

On 06 Nov 2015, at 01:42, slickqt notifications@github.com wrote:

we use M code for sync the action,that is one sync position is a M code, for example with 10 sync position, we set M160-M170 as sync point, when the first machine reach that point it wait until the other machine get to that point, when them get to same point, it will run continue. example: machine 1: G0 X100 M160;(machine 1 is ready,sync with machine 2) G0 X200; ..... M161;(another sync point with machine 2)

machine 2: G0 Y300; M160;(sync with machine1) ... M161;(sync with machine 1)

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

ArcEye commented 6 years ago

Comment by dbskccc Sat Nov 7 01:24:53 2015

yes ,it is not full synchronisation, total synchronisation is complicated even in the same machine, it related to more factors such as motor/servo driver and the mechanics.