In general the robot platform works quite well. But as it’s a work under progress there are still some improvement potentials resp. things to solve:

GPIO 38 does nothing

As the AD2 of the ESP32 doesn’t work when the WiFi is switched on all GIOP’s made available for extensions by the AUX connector were chosen from AD1. The GPIO 38 can be used for input only according the manual. In my case this input does nothing at all (I read that someone has the same problem so I assume it’s not a wiring error). However I linked now that position of the connector with the reset input. This allows peripherals to pull the reset which is helpful for development.

Battery status

With LiPo’s the charging state should be always kept in mind. The robot platform doesn’t report this state due to a lack of free analog inputs. If required it can be easily managed by the AUX connector from the periphery. Just connect a 10k resistor between Ubatt and GPIO33 as a 2,2k resistor from GPIO33 to ground. The voltage can then easily reported via OSC to the remote control (If you suse the same remote control as described earlier)

Speed

The robot is pretty fast. For example an application in which the bottom proximity sensors should prevent the robot falling down a stair will not work at full speed due the braking distance the robot requires (About 5cm at full speed – even with slow decay as described in the last log). Of course allows the H-Bridge to control the speed of the motors but they lose also torque at low speed. In order to avoid this either a software PID is realized. This is still work of progress but should be good possible to realize as the timing reported from the hall elements is very stable (30ms –200ms).

An alternative promises esp-idf (the ESP32) with the lately mcpwc command. As this is unfortunately not yet documented for the Arduino IDE it remains work under progress for me as well at the moment.