New OpenMoCo Arduino Libraries

I haven't compared the two yet, but I kinda consider it apples and oranges - with the old blocking code, it may have allowed slightly faster stepping, but it prevented really long moves while still retaining control over the engine. Like, you couldn't abort a move in-progress if you were about to smash into something =)

But, there still is tuning to do on the new code, I've identified several areas where it can be made a little faster, but it will never be able to exceed about 10k steps/second while still being responsive. This is due to the fact that running the interrupt more often than once every 40uS results in other aspects of the sketch being so delayed that normal activity starts to stutter and timeout. (At a maximum speed, presuming nothing else happened but a bit flip - it takes two interrupt cycles to run a step, so even if we don't account for the operations to actually step the motor, the minimum step-cycle time is 80uS, for a maximum of 12,500 steps/second. This corresponds to the min_stp setting of 80 in the old firmware. Of course, it actually has other stuff to do now, so it won't ever get down to 80uS between actual steps.) The old firmware is a little misleading though, as the digitalWrite() in the old code took several uS its self, so 80uS delay would never have actually been achieved. Once the new code is a little more stream-lined (exchanging memory for CPU cycles), it should match exactly any performance of the old code.

!c

Ok, so after much optimizing, timing, coding, etc. I have found that it is not possible to have both very high speed stepping (significantly greater than 2,000 steps/second) and both accurate, smooth variable splines. Even rudimentary cubic forms take north of 180uS to process position information on the 8-bit processor with no floating-point co-processor. Better mathematicians than I can probably do better, but it presents a stark choice:

Either limited control over the curve (a la smoothstep or linear easing) and high-speed stepping, or fine control over the curve and lower-speed stepping.

I think both cases are meaningful and must be supported.

I think that for those wanting very fast movement, but limited definition of the acceleration curve profiles, we can provide both linear and less expensive quadratic forms combined with a high sampling frequency on when to step. For those wanting the smoothest of motion, with high accuracy in expected position, then they will have to satisfy themselves with a lower stepping frequency.

I have based, as already noted in the existing OMMotor library, the motion control around a sample period upon which Timer1 triggers an ISR to determine whether we should currently be stepping, or standing still, given we know the number of timing cycles that we must not step in which to achieve the desired speed. In the latest implementation, I have also added error correction based on fractional cycle delays to adjust the speed measured across multiple slices to on average meet the expected speed. It has also been somewhat optimized: determination of what activities to take at any given cycle average at or below 20uS. Fewer decisions or comparisons would increase the performance in cpu time, but reduce output reliability. To ensure the CPU remains available for other activities while the motor is running, it only adjust the motor speed once per millisecond, resulting in both a very smooth, natural movement and approximately 75% of the CPU time available for other activities. Decreasing the speed adjustment time consumes more CPU time for motor driving and offers no appreciable improvement in performance, and increasing the time between adjustments results in rougher movement with minimal improvement in CPU availability. As the average time to run the step determination and cubic interpolation combined in one cycle exceeds 240uS, the minimum achievable step check frequency is 250uS, resulting in a maximum step rate of 2,000 steps/second. (See Nyquist theorem.)

Currently, using the hermite spline, the code is able to achieve extremely high levels of accuracy: it always takes the exact number of steps with 0.00028% over-speed accuracy. That is, it will arrive either exactly at the time expected or 0.00028% faster in a worst-case scenario. To give an example of this: on a 60-second move it will arrive 17mS early. This is a constant error rate at a given speed, so all units will express the exact same error given the same duration, and therefore arrive at the same time. The speed is continuously variable, and this results in a smooth and natural move for both short and long moves.

Every millisecond, the speed of the motor is determined by running the cubic interpolation to determine the location of the motor at the end of the next speed adjustment cycle. From this value, the speed the motor should be moving at (i.e. the number of ISR triggers it should remain low for) is re-calculated, and an overflow counter is updated. When this counter exceeds the desired amount, another step is taken. For most serious accuracy, we have to deal with speeds that involve fractional delay periods - for example, a delay of 60uS given a 40uS sampling rate results in 1.5 samples run low. This, its self, is not possible to achieve - instead, we can increment the current delay error by the amount specified in the current time band, and delay an additional sample once the cumulative error exceeds 1.0. In a steady-state of .5% error, we re-correct speed every two steps, and it appears to be moving at the exact requested speed to the human eye, and the overall analysis of motion shows the motor arriving to the expected endpoint at the expected time. (However, any one individual step may arrive at its location up to 0.99 samples early.) This allows us to re-create speeds that are not wholly divisible into one sample, for example: 0.0000015 steps per speed calibration window!

Note that what we're talking about here are the real things happening on the CPU, and not what the motor interprets them at. You cannot exceed the 2,000 step/second limit of the cubic model using microsteps, as it is a limitation of time to calculate, and not a limitation of the motor!

What does 2,000 steps per second look like? On a rotational axis, using a 1.8' motor in full-step mode with 100:1 gear reduction ratio, the maximum speed is 3.6' per second, or a complete rotation in 100 seconds.

Finally, what we're left with is two models: one complex, and one simplified. Both should offer the same execution per sample, but the simplified one will be able to operate at higher speeds by limiting the execution time required to calculate the speed for the next cycle to a reasonable fraction of the sample rate. For example, linear interpolation (without acceleration of deceleration control) operates under 5uS. So, with a standard sample handling time of 20uS, this means that 40uS would be the minimum achievable sample size - or, to put it more bluntly: up to 12,500 steps/second. (Which would require an extremely exacting motor driven at extremely high voltages for full stepping, and hope like hell you don't hit a resonant frequency along the way.)

(EDIT: needed to clarify here, as I don't want it to be construed as limiting a factor as it appears.)

Of course, all of that above refers to a -single, continuous- move where all four factors are defined. Thus, what we're talking about above are "continuous motion" profiles. As the motions between shots in a shoot-move-shoot style execution are irrelevant in their placement outside of appropriately accelerating for the given load, there is no real value in spending all the time on the cubic interpolation for the movements between shots. Instead, in this case we actually apply -both- cubic interpolation and a faster interpolation like linear or quadratic. The higher-order spline is used to define the number of steps in the motions between shots, and the lower-order splines are used to execute those shots to allow for reasonable acceleration profiles under load. Thus, the output motion looks like the cubic spline, but the individual moves between shots are not limited to the speed limit of the cubic spline, and can therefore execute much faster: up to our theoretical limit of 12,500 steps/second.

There is still a drawback here: the output motion will appear more jagged in a shoot-move-shoot cycle as the number of possible samples in the slice is (interval * time), and the natural smoothing of a constant variable speed will be eliminated. That is, the spline will dictate that there are a required 3.25 steps in the each of the next four shot cycles, resulting in an accumulated error of 1 step by the time we reach the fourth, resulting in the fourth shot having a 4-step move. In most cases, this won't be noticeable, but the overall curve will, by nature, be more jagged due to the reduced sample set.

To compare:

30s continuous move @ 1 frame per second: 30,000 speed changes
30s S-M-S move @ 1 frame per second: 30 speed changes

!c

Well, not entirely at the end, I was going to update yesterday, but was mired in code. I found a way to approximate the same curves using a linear algorithm (it comes out close enough for our uses - if we were doing high-resolution 3d animation, it wouldn't be as effective =), and with a tweak to the way the high-step timing cycle was done, we're up to a max speed of 5,000 steps/second now! It's even faster than smoothstep =) (which runs at about 75% of the cubic time, or 150% of the new linear formula time).

As for separating the hardware-specific stuff? I'd have to leave that as an exercise to someone ready to support that specific hardware =) Given that it's all just C++, it's not a leap to replace Wiring with another GPIO library for linux. But there are only so many hours in the day which I have *grin* Until I have more than just me on the dev team here, I have to stick with one target at a time =)

!c

Will have the code uploaded soon (I'm hoping tonight, after we upgrade the site) - I have a largely working library (there are still some issues to work out about taking non-profiled moves [e.g. move 100 steps without specified accel and decel, or move continuously forever] that need to be worked out), and the documentation is still rough around the edges (but now with pictures and graphs =) - also, wanted to add smoothstep.

Additionally, as you know (but no one else, lol =) I had to get the bootloader development done to finish the next stag in a related project, so we also now have a proper bootloader that will let you upload sketches over the RS-485 network, and as soon as I test out the changes to the MoCoBus libraries, we can go up to 115,200bps on the MoCoBus, which is quite, quite nice!

I'll have the full bootloader source in there as well. Unfortunately, it's going to be quite a bit of re-work to get the timelapse engine re-factored around the new motion profiles, so the timelapse engine firmware won't be working when the libraries get checked in.

!c