Motor Control

A project log for Holst Show Controller

A Teensy based controller board to control a number of motors, plus DMX, RS232 and GPIO.

Chris RobertsChris Roberts 10/28/2016 at 10:370 Comments

Since the core purpose of this system is to control a number of motors, deciding how that should be done is key.

There are a variety of ways to control motors out there, but they essentially boil down to the following levels:

To avoid needing to reinvent the wheel, so to speak, (which we did not have time for), we went for the last option. That gives us the ability to concentrate our coding effort on the desired outputs (i.e. motor commands) without needing to be concerned with the practicalities of driving a motor.

Choosing a motor controller module that has the ability to be controlled using a protocol which can be extended over a long distance means we can put the driver really close to the motor itself - meaning the high frequency, high current PWM of the drive signals only needs to go the few cm between the controller and the motor, rather than between the central controller and the motor, which alleviates many electrical noise concerns. Of course, the power is still coming from the central location, and the PWM control of the voltage to the motor will cause current draw to also follow - for this reason a large capacitor is placed near to the motor controller such that sudden changes in current draw will be fed by the capacitor discharging first, and the long wire back to the power source will only see the current required to recharge the capacitor, keeping the voltage of the power supply reasonably consistent.

There are many motor controller modules, but the most hacker friendly appeared to be the Pololu Simple Motor Controllers - which have a USB interface for configuration, a TTL serial interface and GPIO. The serial interface is well documented, can be either ASCII based, or straight binary commands. They support a decent speed resolution, will brake and coast, and can have an acceleration profile programmed into them to prevent peaks in torque when the speed is changed suddenly - which with a heavy load could cause the axel or other part of the drive chain to break in operation.

The other neat thing about these controllers is that their serial ports can be daisy chained. The Rx can be bussed, and each command you send identifies which motor you wish to address and the ones it's not addressed to ignores the message. For feedback from the motor, each controller has a Tx out and a Tx in - the Tx in can be connected to the Tx out of the previous controller - allowing each controller to pass back messages from any of the controllers before it in the chain, eventually making it's way back to the source.

The one problem is that the serial interface is TTL - which whilst simple to interface with being baseband 0-5V logic, it doesn't have a particularly great range and is susceptible to interference. If we want the controllers to be several meters away, then we need something a bit more robust, like RS232.

The interesting thing about RS232 is that the limitation for how far you can drive it is not defined by distance, but by cable capacitance - with a maximum capacitance connected to a single port not being more than 2500pF. Everyone's favourite communications cable, CAT5e - cheap and delicious - specifies a maximum capacitance of 52pF/m in each conductor, which means in theory you can get serial data to travel over 43m of a CAT5e conductor. Which for my application is more than sufficient. And the reality is by reducing the baud rate you can increase that range further - since the effect of the capacitance is to round off the corners of the pulses - if you make the pulses longer, the curved edges matter less. Additionally, if you're able to isolate both ends from the equipment (with transformers/optoisolators) then you can pretty much eliminate any issues due to ground loops between devices. This is also has the added benefit of decoupling any local ground issues and interference due to the spikey motor current draw. If I needed much longer distance than that, then we're looking at a differential signal like RS422. But that's significantly more difficult, and not really necessary for my application.

With that in mind, I needed to make some daughter boards with an isolated version of a MAX3232 that both fed the Pololu SMC's, as well as passing on the signal from the previous SMC in the chain. Seeing as my transciever has two ports, I may as well regenerate the signal coming from the controller as well. Seeing as I've got a bunch of unused conductors, I may as well supply the boards with 5V too - and a virtual ground connected to the controller's isolated port ground. I need to pass the ERR and RST signals back too, so that's another pair. One wire left so... lets stick a 1wire port on it as well so we can do temperature sensing too. Why not!

The connectors are RJ45, since I'd rather not be doing too much soldering when wiring this stuff up. Though this turned out to be a bit irritating as the connectors were board mounted, and meant I was forced to make a hole in the enclosure rather than bolting it to the enclosure. I would have used Ethercon passthroughs, but the space I had for the boxes wasn't big enough to fit such things. Maybe if I did this again I'd have used a D connector instead, or maybe even screw terminals. Or a single connector with two tails? It depends on how small the enclosure needed to be.

The enclosure had two glands on it, to allow a flying lead for 12V power in to the SMC and from the SMC to the motor to be hooked up, with XT60 connectors of the appropriate gender to prevent inadvertantly plugging the supply into the motor output. The wire for this was thick, 2.5mm^2 Tri rated cable from RS as the peak current was going to be fairly high. In black and ... pink. So that you don't get it confused with... err, something... no, mainly because I ordered the wrong colour from RS.

This setup worked well, with controllers working at a distance of 10's of meters from the master control.