User Tools

Site Tools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Last revisionBoth sides next revision
printer_controller_trajectory_planning [2016/08/04 16:00] – created Traumflugprinter_controller_trajectory_planning [2016/08/04 22:08] – [Second Order Trajectory Planning] Traumflug
Line 25: Line 25:
 Moving stepper motors at a certain velocity means to send out pulses after certain delays. A computationally very cheap approach is to simply subtract some value from the previous delay to achieve higher speeds. However, this means non-constant acceleration. Still it's a lot better than no acceleration at all. Moving stepper motors at a certain velocity means to send out pulses after certain delays. A computationally very cheap approach is to simply subtract some value from the previous delay to achieve higher speeds. However, this means non-constant acceleration. Still it's a lot better than no acceleration at all.
  
-AFAIK, [[https://github.com/grbl/grbl/wiki|GRBL firmware]] uses such an approach and doing so allows GRBL to achieve rather high step rates.+AFAIK, [[https://github.com/grbl/grbl/wiki|GRBL firmware]] uses such an approach and doing so allows GRBL to achieve rather high step rates. Like some 30'000 steps per second on an 16\_MHz ATmega.
  
 === Constant Acceleration Calculation Step by Step === === Constant Acceleration Calculation Step by Step ===
Line 35: Line 35:
 === Step Based Acceleration Updates at Discrete Time Intervals === === Step Based Acceleration Updates at Discrete Time Intervals ===
  
-Instead of doing this computationally intensive acceleration calculation after every step, it's done every other microsecond (or at some other time interval), only. The calculation is still done based on motor steps, so it's positionally still perfectly accurate. Velocities obviously suffer in precision somewhat, but at 500 velocity updates per second that's not noticeable.+Instead of doing this computationally intensive acceleration calculation after every step, it's done every other millisecond (or at some other time interval), only. The calculation is still done based on motor steps, so it's positionally still perfectly accurate. Velocities obviously suffer in precision somewhat, but at 500 velocity updates per second that's not noticeable.
  
 This is what Teacup firmware uses when compiled with ACCELERATION_REPRAP. Achievable step rate on an 16\_MHz ATmega is some 40'000 steps per second. Faster hardware, like an ARM Cortex-M4 has been demonstrated to exceed 500'000 steps per second. This is what Teacup firmware uses when compiled with ACCELERATION_REPRAP. Achievable step rate on an 16\_MHz ATmega is some 40'000 steps per second. Faster hardware, like an ARM Cortex-M4 has been demonstrated to exceed 500'000 steps per second.
Line 51: Line 51:
 To the left is a "generator", which outputs 1, 0 or -1. This "signal" is stuffed into the first integrator at discrete time steps, e.g. every 2 milliseconds. The output of that integrator is the integral of the original signal, which happens to be jerk. To the left is a "generator", which outputs 1, 0 or -1. This "signal" is stuffed into the first integrator at discrete time steps, e.g. every 2 milliseconds. The output of that integrator is the integral of the original signal, which happens to be jerk.
  
-This jerk signal (now any value in the range {-1, 1}) is put into another integrator, which integrates up again.This gives acceleration. Yet another integrator in the chain gives velocity. The last integrator gives position, and that integrator happens to be not some mathematical formula, but our stepper motor.+This jerk signal (now any value) is put into another integrator, which integrates up again.This gives acceleration. Yet another integrator in the chain gives velocity. The last integrator gives position, and that integrator happens to be not some mathematical formula, but our stepper motor.
  
 The non-trivial part here is to calculate the original signal. There's a matlab script at the end of the paper to calculate the signal in multiples of an adjustable time step. This script even takes error correction into account. But that's not my point here. The non-trivial part here is to calculate the original signal. There's a matlab script at the end of the paper to calculate the signal in multiples of an adjustable time step. This script even takes error correction into account. But that's not my point here.
printer_controller_trajectory_planning.txt · Last modified: 2018/05/27 16:10 (external edit)