0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly - is equal of FF1 of PID which already exist and its widely used to compensaty cycle delay ... this stuff is from my point of view useless for now
but I am still taking just about pin which allready read position from allredy presented 50ms buffer .. you are providing us from sTP posCmd(t), velCmd(t) (command speed is compensated cycle with PID FF1 and we do no use 60B1 for now), accCmd(t) and jerkCmd(t) and we need for ethercat posExtraCmd(t+2) for ethercat devices which is running in Constant Synchronized Position mode because of absention PID and therefore FF1 absention too (2 cycle lag present of ethercat) - this is just array position value which allready exist in buffer because of time(you notice 50ms) precalculation ...
and I know this is topic connected with ethercat but it is directly connected to trajectory planner ... Beckhoff, Codesys, Deltaww it has implemented as I said because their native bus is ethercat ...
The lookahead buffer stores velocities and segment data, not pre-calculated positions. Positions are computed at RT execution time through interpolation based on progress values that depend on velocity integration each cycle. The future position you want doesn't exist in a buffer waiting to be exposed.Your HAL component using
Code:
vel_cmd * dt + 0.5 * acc_cmd * dt²
is actually the correct approach given the architecture. It's not a workaround, it's the right way to predict future position from the data that exists.The TP gives you accurate vel-cmd and acc-cmd every cycle. With S-curve planning these will be even smoother and more predictable than with trapezoidal, so your compensation should work better not worse.
