If we are talking about responding to oscillation, I think the better first focus is on milling techniques that minimize it?
The negative of a lightweight head for milling is high oscillation potential. The positive is high speed. Perhaps using that high speed, you can mill in a pattern that reduces oscillation as a filter for the incoming/upcoming path. Then your counterweight algorithm starts by responding to a smoothed version of the inverse(?) state of the oscillation minimization algorithm, but X steps ahead within the filtered path due to its heavier weight/slower movement. Attach an accelerometer to the head, the counterweight and perhaps the bed and use the differentials to weight the positioning queues of the counterweight algorithm or to add real-time feedback as 'jitter' to the smoothed counterweight algorithm. After adjustments are applied, the jitter algorithm measures telemetry again to 'score' the results of its last move, use that to apply weights, and recalculate the base algorithm applied to the upcoming buffer.
I see every direct movement from point A to B as a frame, where a new frame is triggered by the head changing directions. Buffer N frames ahead, move the counterweight first, move head, apply jitter within the frame for active correction, and constantly recalculate the 'base' of the next few upcoming frames according to the jitter and feedback from the jitter.
head: buffered gcode (X steps behind real-time)
apply inverse of jitter smoothing filter to the upcoming buffer, re-apply to weight the full upcoming buffer
move
repeat
counterbalance: inverse gcode for N steps ahead of the head (more 'realtime' than the head but still buffered)
apply smoothing filter to upcoming N steps
measure/update jitter weights
apply jitter weighting
move
measure/update jitter weights
repeat
Look for trigger events in the upcoming gcode stream and apply markers that also weight or reset scoring in the algorithms:
- sudden direction changes
- lifting and moving X distance
I think you are 'successful' when you can align the frames of the gcode of the head/counterbalance, and graph the difference/offset to the original gcode over time for the same frames. On a waveform, the offsets should resemble the oscillations your machine/movement produces. If we can get this far, we have a platform that someone can work with and be inspired to experiment with different scoring and pathing algorithms on.
Could this be done with just two RAMPS-style boards and an Android/Pi feedback controller that managed the gcode buffer algorithm and fed the RAMPS?
The negative of a lightweight head for milling is high oscillation potential. The positive is high speed. Perhaps using that high speed, you can mill in a pattern that reduces oscillation as a filter for the incoming/upcoming path. Then your counterweight algorithm starts by responding to a smoothed version of the inverse(?) state of the oscillation minimization algorithm, but X steps ahead within the filtered path due to its heavier weight/slower movement. Attach an accelerometer to the head, the counterweight and perhaps the bed and use the differentials to weight the positioning queues of the counterweight algorithm or to add real-time feedback as 'jitter' to the smoothed counterweight algorithm. After adjustments are applied, the jitter algorithm measures telemetry again to 'score' the results of its last move, use that to apply weights, and recalculate the base algorithm applied to the upcoming buffer.
I see every direct movement from point A to B as a frame, where a new frame is triggered by the head changing directions. Buffer N frames ahead, move the counterweight first, move head, apply jitter within the frame for active correction, and constantly recalculate the 'base' of the next few upcoming frames according to the jitter and feedback from the jitter.
head: buffered gcode (X steps behind real-time)
apply inverse of jitter smoothing filter to the upcoming buffer, re-apply to weight the full upcoming buffer
move
repeat
counterbalance: inverse gcode for N steps ahead of the head (more 'realtime' than the head but still buffered)
apply smoothing filter to upcoming N steps
measure/update jitter weights
apply jitter weighting
move
measure/update jitter weights
repeat
Look for trigger events in the upcoming gcode stream and apply markers that also weight or reset scoring in the algorithms:
- sudden direction changes
- lifting and moving X distance
I think you are 'successful' when you can align the frames of the gcode of the head/counterbalance, and graph the difference/offset to the original gcode over time for the same frames. On a waveform, the offsets should resemble the oscillations your machine/movement produces. If we can get this far, we have a platform that someone can work with and be inspired to experiment with different scoring and pathing algorithms on.
Could this be done with just two RAMPS-style boards and an Android/Pi feedback controller that managed the gcode buffer algorithm and fed the RAMPS?
