[Animats]

I've done a fair amount of timing-critical design, including control of stepping motors and encoders for specialized uses. My experience has been that "real time" programming on a mainstream computer with an operating system is a headache, if it's possible at all. It's just a lot easier to do that kind of stuff on a mid range microcontroller, where the processor has exactly one task and predictable sequencing of operations.

Yes. This is just a "keep motor A in sync with encoder B" problem. That should be on something at the Arduino level, although you might need a faster CPU version. Something with no caches, no superscalar, just dumb static memory and fixed-time instruction execution. Linux would just get in the way. The loop that keeps both sides in sync should probably be running around 1000Hz or so. In one of the OP's rather long and numerous videos, he mentions 10Hz not being enough. Right.

If it needs a user interface, that might be on a separate computer, with an interconnect to set the ratio in the motor controller over I2C or something equally dumb.

Also, you can get stepper motors with encoders, so you can tell if you missed a step and correct. You don't have to use a servomotor, which seems to have complicated this project. Shopbots and Tormach mills use stepper motors with encoders.

Many people have converted existing milling machines to CNC, and there are kits for that. This is a much simpler project.

[rkagerer]

Starting about 7:09 he talked about why the Arduino wasn't a good fit and explained his choice of the TI board (including speed, single-cycle floating point hardware, responsive interrupts and dedicated peripherals to latch consistent, jitter-free reads of the quadrature encoder counts).

Note it's a 4096 step encoder, mounted on a different shaft than the one he's driving, that can run upwards of 2500rpm. His motor control loop (not the complete end-to-end, but the bit that maintains output position to that desired) takes under a microsecond. His code works with either a Nema 24 stepper or Nema 23 servo, and he demonstrated both.

In the second video he maths out some projections for error/drift (factoring in floating point representation error) and its ultimate impact on thread accuracy (which provides some motivation for what you might initially consider "overkill" hardware).

10hz is just the refresh rate for the tachometer calculation.

[analog31]

Indeed, a bit of confusion about "Arduino" is that it has come to mean two things. One is the original Arduino board and its "branded" successors. The other is the development stack. In the latter case, it's GCC with some libraries and a beginner friendly editor. It's bare-iron programming.

Thinking about dealing with an encoder, let's say it has 8k counts per revolution, and the motor can do 10 revolutions per second, which is pretty fast for a stepping motor. Then the encoder steps are coming in at an 80 kHz rate, but an 180 MHz MCU can execute a couple thousand instructions in that time period, so it's not even breathing hard.

[analog31]

I've been quite happy with the Teensy boards. The Teensy 3.6 has a 32 bit MCU with FPU, running at 180 MHz and executes code sequentially AFAIK. You program it in the Arduino IDE, but Arduino is now just a thin layer on top of GCC, and you have full access to the MCU registers and functionality. There are a number of other attractive 32 bit processors such as the STM32 family.

[Animats]

That's the sort of thing I had in mind. Low-level Arduino-type microcontroller programming on a bigger engine.

The Arduino development environment is just an IDE and a library for board-level systems. It's C++ underneath, and all of the C++ language, although not the libraries, is available to you. You can do the same thing without the Arduino system, but setting up the build environment tends to be complicated.

If you need precision timing, you either need to program bare-metal, or use some hard real time OS like VXworks or QNX. Here, where it's all stepping and reading encoders, bare metal is the way to go. If you were coordinating a multi-axis machine, a real-time OS might be better.

[vvanders]

I've always wanted to mess around with the beagle black since the two PRUs are supposedly built to handle cases exactly like this.