We are working on a robotics project employing a differential drive.We are facing problems with one of the motors .While one of the motor runs fine, the other motor humms and sometimes doesn't run when connected through L298n driver,but works fine when directly connected to a battery.Tried checking the driver and everything is fine with it when tested with the other motor.How can I solve this problem?
Thanks in advance
Motor specs- DC motor with encoder
12V , 1A ,rated torque- 7kg-cm, stall torque – 17kg-cm
Electrical – DC motor humming troubleshoot
dcdrivermotor
Related Solutions
I don't think your motor driver is designed to handle the supply +/- connected but VCC/Ground not connected. You should always have both supplies to the motor driver and the ATMega either ON or OFF, an not have one ON and the other OFF (ATMega ON, driver OFF is probably alright, but you would have to be careful.)
If you require it to function like that, you should take specific measures to allow it to work.
The motor driver should be fully powered or not powered at all at all times. So, instead of using the Vcc/Ground from the ATMega, use a 7805 or the like and generate 5V from the 24V supply. Use this to power the Motor driver's VCC (and NOT the ATMega's VCC)
Once you've split the supplies, you need to translate the logic signals from the ATMega's supply to the Motor Driver's logic supply. Since you're talking about 24V/5A, or over 100W, I'll gather these are fairly heavy duty motors. It's worthwhile to go the extra mile and do this using optocouplers. Optocouplers / optoisolators allow you to translate signals from one supply to the other without any copper / conductive attachment between the two sides. This is useful for a number of reasons, but also tends to expensive. Analog devices has a line of iCoupler isolators which don't use optics but use another method instead. Isolation of this kind (usually identifiable by having separate grounds on both sides, not just separate supplies as in level translating buffers) will make sure that you can run your logic signals from one side to the other without worrying about noise coupling back into your ATMega's ground and supply and all that.
You can avoid proper isolation and use a simpler (and cheaper) level translating buffer like TI's SN74LVC2T45 and family, but you may see strange behaviour come from the high currents that are switching on the motor side.
It's not unusual to find that under near-full-power-out conditions the motor will be about 50% efficient. This is a big motor but it still applies: -
Next, you estimate how much mechanical power you need (2 pi n T) where n is revs per second and T is torque in newton.metres. If your dc motor's data sheet doesn't provide this information (like the graph above) then get one that does.
If you don't know how to calculate your mechanical power requirements you need to learn and start with: -
Force = mass x acceleration courtesy of Isaac Newton
Mass is what you want to move and acceleration is final speed divided by time to get to that final speed (i.e. what you want it to do).
Force x distance = work done and work done per second = power.
Don't forget friction as a loss and if it moves fast then there will be other losses due to moving air around.
Best Answer
This type of problem (where you have two supposedly identical "channels" and one is working but the other is not working) is easy to solve when you have the equipment in your hands. Find the difference(s). There must be difference(s) between the two channels, otherwise their behaviour really would be identical!
It is worth noting that difference(s) might be hidden due to a faulty assumption. For example, in your case, you are assuming that the motors have identical specifications and so are identical. In fact, one motor might be different than the other e.g. mislabelled, faulty manufacturing, damaged by previous use, etc. So always check and list your assumptions.
Two approaches to find differences which are quite suitable for beginners include:
Move devices/modules, one at a time, from the "failing" channel to the "working" channel and test whether:
(a) the problem stays with the original "failing" channel (then the problem is not the component you moved to the other channel), or
(b) the problem moves with the component to the other channel (then the problem is related to the component which you moved, although it might not be the component itself, but connectors, wiring etc. that were related to the move).
One risk to this approach, is that by disturbing the electrical connections to move components between channels, you might change the problem, or it might disappear, without you knowing why (e.g. you might fix a high resistance connection when you move a wire).
Or:
Make relevant measurements between the two channels, to find where the difference is. In your case, this would include measurements with DMM and 'scope to see if the supposedly identical PWM signals being sent to drive the two motors really are identical, If not, then you can use additional measurements to narrow down whether the cause is hardware or software (PWM generation).
This approach has less risk of disturbing the cause of the problem than option 1 above (it is bad news if the problem "goes away" without you knowing why, because it could return in the future!) but it requires test equipment and ability to interpret the measurements.
Troubleshooting is not taught enough in many engineering courses. Learn fault-finding techniques at every opportunity and add them to your personal library for use later. Some good formal techniques are taught by Kepner-Tregoe and others. I have (over-)simplified their approach in my example above. Those simplified techniques would often not be appropriate in more complex cases.
An (unofficial) example of the Kepner-Tregoe "IS/IS NOT" approach is available here: http://www.itsmsolutions.com/newsletters/DITYvol6iss19.htm Although that is a software (IT) example, you can see how the possible causes are tested to see whether they match the problem description and other data.