ESP32 Forum

I'm working on a self balancing robot (ie: like a minature segway) which has two brushed DC gearmotors with hall effect quadrature encoders on them. I'm using DRV8871 https://www.adafruit.com/product/3190 as the motor driver.

The first robot I built was using an Adafruit feather m0 board and I controlled the motor driver using the analog and digital write pin commands to switch the control pins and send PWM.

On ESP32 I see there is the MCPWM unit. Can MCPWM be setup to read the quadrature encoders AND control the motor PWM? I have seen an example that does motor PWM but NOT one that also has MCPWM reading the quadrature encoders. If the hardware can do this it would be a big help as these robots have tight timing requirements so having hardware reading/saving encoder info would help.

Also, does MCPWM have any way to also use the encoder output to manage motor speed? Or would that have to be done in software with a PID loop or something similar that reads the encoder count and adjusts the PWM output?

By the way I'm using ARDUINO right now because I'm building several robots with different CPUs and the cross platform support is helpful, can MCPWM be used from ARDUINO IDE?

Any help/examples would be appreciated.

I've done a PID motor controller using the MCPWM. I used only a single encoder output, not quadrature. The capture module in the MCPWM measures the time between pulses, thus providing the feedback to the PID controller.

There is a sample project in the ESP-IDF examples folder which illustrates usage of the capture module. I would start there.
It is FreeRTOS.

Regards,
Greg

did your PID controller run the PID in the MCPWM somehow? Or was it external code with the MCPWM just counting pulses and PWMing the motor?

The latter. The counter gets the pulse timing, and that is translated into RPM. A simple PID in C code sets the PWM duty cycle.
A counter is needed to fire the PID periodically. So the system periodically samples, and the PID adjusts duty cycle to keep the loop error low.

The PID is implemented as a FreeRTOS task. I also had an OLED display running to display the RPM.
The PID parameters are user adjustable for experimentation purposes.

The PID needs top priority as it is a hard real time process. I did the operations in fixed-point to make it as efficient as possible.
A good way to come up to speed on fixed-point number manipulation.

Regards,
Greg