Go Down

Topic: motor control (Read 877 times) previous topic - next topic


Does this sound doable with an '328 family processor?  I'm thinking 0.05425 uS resolution is faster than the uC clock speed, so not possible to get there?

"I have some questions about yet another project (still part of the same larger project).  Are you familiar at all with how RC servos work?  Brief rundown - servo receives a pulse every 20ms or so, and the width of that pulse basically defines an absolute position that the motor should seek out, generally within a range of 180 degrees the servo can travel.  The pulse width is typically between 1000uS - 2500uS.  I am using a servo controller as part of this project that will control the pulse width to within 0.05425 uS resolution, within a range of  10-2390 uS.

RC servos usually use a potentiometer for position feedback and a small DC motor with high gear ratio to generate significant torque.

I need an MCU circuit built that will basically act as an digital RC servo controller, like that typically found inside an RC servo, but it will use an optical encoder for feedback and a stepper motor as the source of motion.  The MCU will need to read a typical servo control pulse and translate that in to a desired target position for the optical encoder.  It will immediately output TTL step/direction pulses to a separate stepper driver until the desired encoder position is reached.  The MCU will constantly be comparing the target position with the actual position of the encoder and correcting the position if it is not in the correct place.  If the position is correct (within a certain "dead-band" window) no step pulses will be outputted. 

The tricky part might be that the step pulses must be output within a specified rate of acceleration/deceleration to avoid exceeding the possible physical acceleration rate of the motor.  That rate would be determined through testing and permanently programmed in to the MCU.  Beyond that the MCU would need to constantly monitor how close it is getting to its destination and reduce the step frequency accordingly to avoid overshooting the destination.

A few other features would be necessary on the board, like the ability to slowly "home" to a nearby index mark on the optical encoder upon power-up, then define that as the zero position (typically this is the "center" of the servo travel range, defined by a 1500uS pulse width).  Furthermore, a scale factor would be set via a couple jumpers, allowing the number of encoder pulses travelled per uS of pulse width to be varied.  This would allow the total allowable travel of the motor to be varied."

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.


If .05425 uS resolution is not possible when measuring a pulse width with a '328 family processor, what would be the minimum resolution practical?



The '328 can run 16MHz, and the timers can run at CPU frequency. By definition this gives you 1/16th of a microsecond precision. 1/16 is .0625. If you could run at 20MHz, you could pull off .05us. Depending on speed requirements, you may be able to to get significantly more precision by oversampling.

I'm skeptical of the need for such precision. We are talking 15 bits of precision here; I doubt that any of the off-the-shelf RC signal generating hardware is that precise. If you aren't using off-the-shelf hardware, then why use RC servo protocol at all? It's an old and inefficient protocol; the only point in using it is for compatibility with existing hardware.


The problem comes in when you are also trying to keep up with the encoder. Unless you are using a very low res encoder you will also need to use interrupts for the encoder and that will affect timing. Get rid of the encoder and it gets more doable. can you have part of your sequence run the "servo" to one physical limit or the other and "re-zero" it? you could then run it open loop.


If it becomes too much for the chip to evaluate the encoder and the RC pulses simultaneously, what about offloading the encoder interface to an external quadrature counting chip like this, with a serial interface:


Would that make it easier?

Go Up