Driving multiple motor+encoder at high frequency I/O


I would say I am mildly competent at making simple robotics with one or two motors, but I have a case now where I would like to make a 6-DOF robotic arm with 6 brushed DC motors with 6 high-resolution quadrature encoders on it (up to 2500 cycles/rot). I am having trouble figuring out the hardware I need.

here is the example motors/encoders
encoder: usdigital.com/products/encod … ary/kit/e3
motor: maxon RE30 motors, I’d like to drive them at 12V, peak 2A

There are a few things I wanted to do:

  1. keep a control loop for all servos at a high frequency, minimum 1kHz, hopefully a few more kHz
  2. PC to micro communication (does not need to be bilateral)
  3. Implement my own motor control algorithm

From my understanding I need:

  1. microprocessor unit
  2. counters for each encoder input so micro doesn’t need to be counting — essentially to keep high frequency operations I want to have the option to just ping for the motor shaft location.
  3. motor drivers/controllers for each motor (if I use motor drivers, I need a PWM-generator for each motor, and if i use motor controllers, would i still be able to define my own closed-loop control method?)

I’d like some suggestions about what hardware I should get and or other considerations I am missing…



Hi, Mike.

Your understanding basically sounds correct to me.

Maxon has a couple of RE30 models; I don’t know which one you are planning to use. Do you know the stall current of the motor? We recommend that people get motor drivers/controllers that have continuous current ratings above the stall current of their motors.

- Ryan

Thanks Ryan,

I’m not 100% sure which one, but it seems a check of the “starting current” of a RE30 within a similar spec range is 25-50A (surprisingly high to me!). This seems way more than any normal power supply would be able to deliver. How should I interpret this?

Secondly, The only motor controller I found (on Pololu) that takes quadrature input is the Roboclaw; however, its unclear whether I am forced to use their position control strategy (PID), or if I can use it simply as an nice board interface for 1. driving motors, 2. getting the position of the motor without actually measuring the encoder ticks.

A final question is with current sensing — how come a controller such as Roboclaw doesnt come with one? It seems fairly logical to me that without current-sensing, if a motor is ever run at stall for more than a few seconds it will melt the coils (because I am assuming that the motor driver can deliver the stall current); therefore, current-sensing is necessary to reduce the current at stall to some fraction (50%?) of the stall current rating of the motor to prevent it from melting the coils.

I think the best way to proceed is to measure the stall current yourself. You need to hold the rotor so it doesn’t spin and measure the current. You can do it at a low voltage so the current is small. The stall current will scale proportionally with the voltage.

The RoboClaw does not force you to use its closed-loop control features. You can query the encoder counts from it.

Some applications never encounter stall conditions, or they handle it by using a fuse. Adding current sense makes motor controllers cost more and the particular sensor might not have the range or precision that a particular application demands. We sell some current sensors you could consider using.

- Ryan