Extract Motor control code from StrokeEngine and inject a MotorInterface

[zylos146]

WIP currently - Lots of bugs and polishing needed

[zylos146]

Need to check that all patterns work, but otherwise a lot of the PR comments are addressed now. Will continue to do cleanup if I notice anything

[zylos146]

Once this PR is merged in, I want to work on building a Pattern Registry, so they can be automatically detected when a library is included. I also want to discuss the concept of Directors as I laid out in the new README.

[zylos146]

Make Pattern independent of depth being used as translation. Have translation be handled in StrokeEngine, so we can smoothly translate patterns?

[zylos146]

What happens when goToPos is called while a motion command is executing?

[zylos146]

Mutex or lock over Motor Movement. Only one source can take a lock and send motion commands at a time. Prevents erratic behavior due to users using goToPos without disabling StrokeEngine first

[zylos146]

Add more protection to goToPos to reject commands in invalid motor state (Not homed, etc)

[zylos146]

Move homing start into Event Handler

[zylos146]

Reactive / Observer for Motion? Or continue to use goToPos?

[zylos146]

Directors will be very similar to patterns/drivers, where StrokeEngine provides registery, and help attaching/hooking up, but external libraries provide the actual Directors. Some basic Directors might be included

[zylos146]

Rail length detection via Sensor-less homing techniques

[zylos146]

How do we handle worst-case scenario failures, like a FreeRTOS task returning, causing an ESP abort, and the microcontroller rebooting? Can we intercept that process so we can gracefully emergency stop?

[theelims]

I don't thick a critical failure can be intercepted to execute code. The only chance would be to check on reset reason, and if it was a crash execute some safety function.

In practice more often then not when this happens the code would stick in a death loop. This would defeat this purpose.

[zylos146]

So it's not finished yet, but I'm pretty close to allowing JS-based Pattern building via DukTape. You'd be able to add a pattern like the following.

addPattern("Simple Stroke", {
  isOutStroke: false
}, function (timestamp, isAtTarget) {
  var position = 0

  if (isAtTarget) {
    this.isOutStroke = !this.isOutStroke

    if (this.isOutStroke) {
      position = this.stroke
    } else {
      position = 0
    }
  }

  return {
    position,
    speed: this.speed,
    acceleration: this.acceleration
  }
})

[theelims]

May I suggest to separate those two topics? But yes, I already hat eyed with DukTape for this purpose.

Is the motor part of this PR ready for testing? Once it is all in the experimental branch I would write the generic stepper motor driver and put it to tests on my machine.

[zylos146]

It's relatively close. The reason I had started with DukTape is because adding the lock/unlockTask was part of a re-write to have the Motion Generation more task-oriented, rather than polling-based.

I can see if I can revert to an earlier checkout in the branch and continue getting the motor part ready for testing.

[zylos146]

But yeah, I can understand wanting it separated. I think I got a bit carried away with investigating DukTape, and should focus on getting the basic PR ready first

[zylos146]

I've pushed the duktape integration into https://github.com/theelims/StrokeEngine/tree/duktape-integration

[zylos146]

I'll move the other un-related changes I had bundled with the Duktape changes back to this PR