Hi Max, you're the first to try the new platform 🙂 It's far from settled!
Just a couple of days ago I've changed the structure of the project so it includes the libraries I'm using. Some of them are going to stay, some might change. I'm using PlatformIO (with VSCode) to actually write these days, so that folder structure is a platformio project folder structure. Usefully, it allows you to have local copies of libraries installed per project, rather than everything having to share global copies. Dangerously, that's allowed me to make some local modifications, so that's why I've rolled the libraries into the repo.
1) ESP32_Servo ... I'm confused about the provenance of the version I'm using, the library.properties file describes it as John K BEnnett's v1.0, but very recent changes (last 4 days) have updated a few things about it, namely to 0.1.0 and there's a new co-author and it's got no underscores anymore! I think I just have an old version.
2) ESP Ticker... This is Bert Melis' Ticker-esp32 (https://github.com/bertmelis/Ticker-esp32) but it's also recently been merged into the main Arduino core for ESP32. However! I've hacked a local version that has microsecond timing rather than millisecond. That is included in the current lib/Ticker folder of the polargraph firmware. Right at this minute, the code doesn't use the microsecond timing (attach_micros()) because I'm trying a different approach to get more even stepping. I've not settled on the best way to do that yet. Actually I've got an uneven-ness that I'm trying to figure out if its in the hardware (the new polarshield v3) or in the software. I've got some days free over the next week to try to get to the bottom of that.
3) Metro is this one: https://github.com/thomasfredericks/Metro-Arduino-Wiring
4) Encoders aren't even really used yet but the library is there. The standard lib needs a couple of extra lines in direct_pin_read.h (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/lib/Encoder/utility/direct_pin_read.h#L33-L39) and interrupt_pins.h (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/lib/Encoder/utility/interrupt_pins.h#L176-L207) to make it work with ESP32. This was tested to make sure that it compiled and that the numbers changed when I twiddled the encoders, but I haven't tested whether it works in a realistic situation.
Most of it works ok, but there's a big question over the basic stepping engine. The most recent changes push the calls to motor.run() into a separate task in the the ESP32 operating system, and then call that task periodically with a task notification, and the task notification is driven by a timer that creates an interrupt every 100us. It works (amazingly) and does trigger that runMotors() task 10,000 times a second which is what I'm looking for. BUT, I can hear serious quantisation ("banding") in the acceleration profile, and when I step really slowly it's obvious that there are steps being quantised. I don't think it's missing steps as such, in the sense that the full motor steps are happening, but microstepping isn't smooth. I can't imagine that the software has anything to do with that, so that's why I'm going to focus on some hardware tests this weekend (I've got some beta testers waiting for these new machines!).
The old method of running the stepper motors was completely synchronous, so it'd block while stepping until the target position was reached. It made it really simple and also guaranteed that there was absolutely nothing else happening at the time, no interrupts, no competing tasks (well UNO/MEGA doesn't have multitasking). So I'm not clear if the way this new stepping pattern sounds is bad or if it's just different.
The pinouts for the motors are probably obvious from the code but shout if you get stuck. You might have a problem with the display & touchscreen if you don't have one connected, because it will try to do a screen calibration (touch the corners etc) if it detects that the screen hasn't been calibrated yet. You can probably avoid it by commenting out the call to touch_calibrate() (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/src/configuration.ino#L169) but also be aware that the touch response might get triggered by something else if those touch lines aren't controlled.
Good luck! Would love to hear if you get results.