Auric: An update
I've been rather busy of late, and have not had as much time to spend on Auric as it has needed.
The motor control has been a problem on this model right from the beginning, and I put some of it down to the L289 controller that is on the NodeMCU carrier. I realise that this sounds like a poor workman blaming his tools, but early on, back-to-back testing showed the more common L298N-based drivers could drive the motors harder. Packaging issues got in the way last time, and so I went with the NodeMCU and its carrier. I paid the price in terms of performance.
Unfortunately, there is still the packaging issue. There are very few options for shields or carriers for a NodeMCU (to be honest, I can't find any other options), and there is simply not the space on Auric's deck for a separate driver module. This may well mean changing out the controller altogether. If I go to an Arduino UNO, such as I used the Self-Driving car, then I have a few more choices:
- ADAFruit Motor Shields v1 or v2. There are also a heap of clones of the v1, both of which are based on the L293D chip. These boards are rated to 2.5A
- SparkFun Monster Moto Shield. This uses a pair of ST Microelectronics VNH2SP30 chips, which are commonly found in automotive applications and can operate at 6A without a heatsink.
Both of these look promising because they solve the packaging issues and should be more than up to the current requirements of Auric's motors, but clearly a test was required.
My test rig consists of a pair of heavy duty 12V geared motors (ZYTD520) which should roughly simulate the load of the four motors used on Auric. Power supply was a 7.4V LiPo pack.
ObservationsThe first stage was to simply run the motors at full speed to measure speed and current draw, as well as the temperature of the driver chips.
The ADAFruit board ran much hotter. So much so in fact, that I added a pair of heatsinks to the board because I was worried it would shut down or be damaged.
The VNH2SP30 has a few interesting features, which while not essential make it potentially a better choice in the long term. The first is inbuilt current monitoring, I can read back the motor current on an analogue pin. Quite useful for battery life monitoring. The other interesting feature is brake functionality. We don't need it now, but being able to issue a force stop or hold would be useful in the future.
Unfortunately, both shields bring their connections out in dissimilar ways to the SZ-Doit board I was using, so this means new cables for battery and motor. Not a big problem in the grand scheme of things, but just annoying since I had everything so neatly cabled up.
Changing these shields will also mean large scale changes to the code which runs on the UNO, since these controllers are operated in a different manner. I will look into making the choice of shield a compile-time option, and make it possible for others to follow my work, but make their own choice of controllers.