dual DC motor PI controller

Hey guys,

I'm planning to do closed loop (PI or PID) DC motor speed controller. The CPU will have to:

  • read current input values (from analog joystick -> ADC, or from RC receiver -> pin change interrupts)
  • read multiple ADC values like voltage, motor current, temperature
  • read and calculate current motor speed from 400 CPR encoder (thats 1600 impulses/rev)
  • compute PI
  • generate 1 or 2 PWM to drive H-Bridge
  • serial communication (UART or I2C) with other uC (report motor status or get control inputs)

The problem is, that most of these things will be doubled, to control two independent motors. I'm assuming max speed of each motor to be about 400 rev/min, thats ~7rev/sec. Then encoder kick's in. That's 11.2k impulses/sec from just one encoder. The idea is to use pin change interrupts to read the signal, count the tacts and then convert it to speed in constant time loop (like 100Hz or so). The same loop will be used to compute PID and update motor outputs.

Do you thing that is possible, or is it just too much? If that's possible, probably I will have to use some direct AVR instructions to run it faster.

Any advice would be appreciated.

If you just want to control the speed then an encoder that produces 1 pulse per revolution is sufficient.

Using the encoder you have maybe you should only call the PID function after every 400 pulses.

You may be interested in my explorations. One of my objectives was to avoid the use of floating point maths to improve the speed of the PID calculation.

...R

An encoder that produces 1600 impulses/rev is in fact a 1600 count/rev encoder in 4X mode.

You don't have to use all the impulses, though. If you just use the rising edge on one channel, that would be 400 pulses/rev. I agree with Robin2 that even this value is serious overkill for a speed controller, and greatly complicates the problem.

Robin2:
If you just want to control the speed then an encoder that produces 1 pulse per revolution is sufficient.

Thanks for this link!

I forgot to say, that my object, which actually is quite big robotic platform will be more dynamic than static object.

Please consider, that my max RPM is 400 (I'm sensing RPM after gearbox), and mostly it is going to be 50-200. For such a low RPMs and 1 pulse/rev I will get huge error. Lets assume RPM 60, thats 1 rev/sec and 1 imp/sec. The first problem is delay between last measurement. The second - resolution. For 120 RPM there will be 2 imp/sec etc...

My strategy is to measure time between lets say 50 pulses and that will be proportional to angular velocity. Than scale that value so 400RPM (my max possible RPM) will be 255 and -400RPM will be -255 -> that would be input to PI regulator.

I agree that 1600 pulses/rev is overkill, but you can find cheap (like 10$) encoders on ebay.

Please correct me if I'm wrong.

I will get huge error.

Actually, the longer the time between pulses, the more accurate the measurement of average rotational velocity.

For a large robot the speed won't change very rapidly, so you are overemphasizing the need to sample rapidly.

MadSciencist:
Please consider, that my max RPM is 400 (I'm sensing RPM after gearbox), and mostly it is going to be 50-200. For such a low RPMs and 1 pulse/rev I will get huge error. Lets assume RPM 60, thats 1 rev/sec and 1 imp/sec. The first problem is delay between last measurement. The second - resolution. For 120 RPM there will be 2 imp/sec etc...

So maybe you need more than one pulse per rev but I can't see the need for 400. Use the 400 pulse encoder but only recalc the PID values after every 40 pulses or, perhaps, 20 pulses. I'm pretty sure there a mention of that sort of thing (not by me) in the link i gave you.

To get the best value from any advice you need to see the main message (in this case fewer pulses) and consder how it can be adapted to your requirement if it is not specifically suited to it.

...R