Motor speed and current monitoring (I need ideas)

[OM222O]

We're using two DC motors in a project, they run at 150 (+- 10%) RPM and they have a rotary encoder with 2 pulses per rev.
It comes out to about 5.33Hz signals on each phase of the motor.Let's just say 6Hz. We need to match the speed of the two motors (we're setting the direction of them in software so we don't care about reading the encoder perfectly). I had an idea to use a quad XOR chip and re use some parts that we are already using for the other parts of the board (10K resistor and 100n ceramic caps) to detect the rising and falling edge of each phase and combine both of them so we get a higher resolution (4 pulses per revolution) to match the speed of the motors. here is a circuit simulation of my idea: http://tinyurl.com/y98ptn85

as you can see it generates pulses that last somewhere between 0.5 and 1ms. I think if we feed the signals for both motors to interrupt pins on a MCU, it will be able to read them and adjust the PWM output accordingly. Is there a better/simpler way or any specific chips that would do this automatically? I'm not sure how much load this will put on the MCU as it needs to be doing other things in the background as well. I also couldn't find any easy solutions to do current monitoring. all the INA current sense chips are super tiny fine pitch ICs and I've had no luck soldering them with hand.I guess I should just get an op amp and create the same circuit with a few resistors?

Thanks for your help.

[jbb]

Hmm.

Am I right in thinking you:

• Have software control of the motors (e.g. software sets PWM duty cycle for power stage)?
• And are having trouble with speed control because the encoder pulses are so slow?
• Want some decent current sensing in your circuit?

Well, I think the 'obvious' answer is to use encoders with more pulses.  But this could be nigh-impossible, so I suggest you look into some fancy control solutions.  I'll try to look up some references later, but here's the brief idea.

• The DC motor can be modelled in state space coordinates such as current, speed and angular position.  Note torque is basically constant * current in a standard DC motor.
• Typically, multiple control loops are used: the motor current is controlled to make the motor produce torque on demand (fast inner loop), and then an outer loop (slower!) is used to fiddle with the torque to get the speed you want.
• You can build a software model of the motor inside your microcontroller and feed it the same PWM duty command as your real motor.  In an ideal world, they will behave the same.  But they don't, so feedback is taken from the position sensor to periodically update the model.  This is called a closed loop observer.
  
  If done correctly, the observer will produce an estimate of the motors state all the time, even when the encoders are between pulses, and the errors in the observer will be reduced by taking periodic feedback from the encoders.  With some luck, you can control the motor speed (roughly) faster than the encoder pulses come in.
  
  One challenge with this situation is that the rotor winding resistance of the motor is an important part of the model, and it will change as the motor heats up during operation.  A think called a parameter estimator can be added to the scheme to trim the resistance during operation and make the system behave well even over a wide range of operating temperatures.
  

As an aside, I think that some of the INA series come in SOIC 8 packages, which are generally OK to solder.  A whole lot of new parts simply don't (and won't!) come in DIP packages any more).

[Benta]

First, 150 rpm with two pulses per revolution works out a 5 Hz.

The classic way of synchronizing two motors is to have your MCU run an internal timer at 5 Hz (easy).
Sampling (perhaps using interrupts, but much better capture timers) the feedback from the motor gives you the time difference between internal 5 Hz and motor feedback, which can then be used to control the PWM.
Mind you, there are a lot of mechanical unknowns here (eg, inertia), so you're actually looking at a digital PID.

[OM222O]

We will be using an ESP32 to do everything on a robot, e.g. motor control, position tracking, reading different sensor values and making decisions based on that information. I'm just trying to match the speed of both motors so the robot moves in a straight line because there is a small difference between the ones we already have. I'm trying to get 4 pulses per Revelation just for the added accuracy not because the 2 PPR is too slow.

We also want to monitor the motor current so if the robot is stuck on something (e.g. one side hits a corner of a wall or goes on a steep rock) and the motor is stalling, we know it's drawing too much current to shut it down and go in reverse or something like that. I'm just not sure how much of a load all the interrupts from the encoder would put on the ESP32 cause as I said, it should be doing other things in the background as well. And again, for current sensing, I'm not able to find a chip that's easily soldered by hand. If there's a THT chip that would be great but larger pitch SMDs are good enough as well (all I could find were 0.4mm or smaller pitch). I'm also not sure how to implement a good current sense amplifier which has common mode rejection and how to implement one myself. There is a simplified diagram of the INA213 which basically shows two 1 meg resistors, a DC offset and two 20k resistors to get a gain of 50. are there any additional components needed or is that actually all there is in a current sense amplifier?

[jbb]

Those integrated amplifiers are deceptively simple. In this case the on-chip resistors are precision trimmed in the fab. This is essential for common mode rejection, which is critical and very annoying to do with single resistors.

Maybe the INA213AID would suit? It’s in a larger package with 0.65mm pitch legs.

Do read the data sheet - a decoupling cap is required and if you want to sense bidirectional current, check out the applications information. Playing fast and loose with the reference node will cause trouble.

If you want to sense the motor current itself, there will be HF noise from the full bridge, so maybe have a look at Fig 29 and surrounding text in the datasheet.