Hi i am working on a line follower robot . I am using a 9v battery (HI WATT) to run the two motors with L293D. But the two motors are not running identically . One of them is faster.

Is this due to insufficient power. I had earlier used a 12v supply which had a large power rating (dont remember rating) which blew of l293d driver.

please suggest me a power supply for this.

Your title says they are 12v DC motors! Are they? If so how could you imagine they would work properly with a 9v battery? What sort of 9v battery? A puny PP3 that is not intended to power a motor?

If the L293 burned out is is almost certain that the motor drew too much current.

So what is the stall current of the motor? What is the current drawn by the motor running with its normal load? You need a driver board that can handle the stall current without overheating.

How long do you want the motor to run from the battery? Amps x hrs = Ah. Multiply by 2 to get the required battery capacity with a margin for error and an allowance for the optimism of battery manufacturers.


But the two motors are not running identically . One of them is faster.

Yes two motors will always run at different speeds unless you take measures to regulate them.

Is this due to insufficient power.

Not quite. It is due ( amongst other things ) to unequal voltages applied to each motor due to your motor drivers not being electrically identical. But even if you adjust the motor's voltage to be the same two motors can never run at the same speed. They need to be controlled, that is you need to monitor the number of turns and adjust the voltage so that the two run together.

@ Grumpy_mike . That is where i am facing problem. My project was to save the path followed by line follower and retrace it . I was able to do this forward path tracing but then to make it retrace the path backwards , here the left motor and right motors are changed in position thus they are not having same speed so i am not getting the output.

I will try not to reverse the robot and use L293D s pin to go backwards , maybe it will work as the same motors will take the same turns.

Do you think that L293D will also be able to drive the motors the same way backwards , or it will change.

Do you think that L293D will also be able to drive the motors the same way backwards

How can we possibly say? My car has many 12V DC electric motors - one of them starts the diesel engine, one winds a window up and down, another adjusts the headlights. How about you tell us something about your motors?

The motor is a generic one i am not able to find the manufacturer but it is of this type. This is the datasheet of a similar motor

Do you think that L293D will also be able to drive the motors the same way backwards ,

No not exactly. You need more electronics in your robot if that is to work. You need to have a rotary encoder on each motor and record the number of pulses it gives you. Then when you play it back you need to make sure that you control the motor power such that you get the motors running at the right rate.

Basically you can not do what you want with the electronics you have.

I am simply giving 4 states to the robot that is (LEFT, RIGHT, FRONT, BACK) and i am recording the time for which they are in that state and again reading these values back from EEPROM and then running the robot at those states for that time.

And as i said i am able to retrace the robots path in forward direction with a good accuracy . the backward path is causing problems

Yes I understand that, you have to understand that life does not work like that and there is a lot more to engineering than assuming everything works perfectly, consistently and reliability.

I will not be able to do what you have suggested as i have 15 days to complete it . I am ready to compromise on accuracy so do you have any other suggestions.

You could always try and incorporate a fiddle factor into your software.

This will adjust the time of the motor depending if it is running forward or backwards. You will have to find out what this factor is by experimenting with the hardware you have.

So for example if one motor runs at exactly half the speed of the other ( I know it doesn't but it makes the illustration easier ) then if you run it for three seconds in one direction you run it for 1.5 seconds in the other direction.

Gotta love those fiddle factors! :D

(And incidentally, that probably is the best way to approximate what you want without the proper hardware. It's actually called "calibration".)

It’s actually called “calibration”

No :slight_smile:

thank you i will try that :) .


It's actually called "calibration"

No :)

No this is not really calibration, fiddle factor is more accurate. However, you can try and calibrate your fiddle factor.

However, yeah, if you do what mike said, you'll be able to at least get the thing to drive in a straight line. I had to do something similar for a microcontroller class and our solution was to find PWM factors for both motors such that they ran at the same speed, and then work from there. It wasn't the best, but it didn't involve extra hardware either.

The bot -mechanical- system does not 'behave' equally in forward and reverse directions. You've got software and mechanical assembly and adjustments such that everything behaves -repeatably- going in one direction. That's very very cool.

You didn't mention if you've got four wheels, three wheels, a roller ball, or a plain skid for balance. In reverse the -entire- mechanical system works in reverse, with drastic effects. Everything changes, starting at the gearbox. There are no perfect gears. A -slight- misalignment or variation in the -finest- detail of a gear will cause 'different' behavior between the two gearboxes, when it's run forward and then in reverse. Try going in a purely straight line with no navigation/line follower, in forward and then reverse, and you'll see some differences.

Another example, with worse effects. A simple skid -trailing- the drive wheels, the skid -follows- the wheels and whatever variation/imperfection is sees in the surface it's sliding on has a slight but minimal effect - so you have good repeatability. Reverse the motion with the 'skid leading,' and any bumps/bounces/imperfections in the sliding surface are -amplified- by the skid in a sense 'controlling' the fine-tune of the direction. A grain of sand will throw it off. I'd bet that not only does the reverse motion not match the forward motion accurately, it's also never the same variation(s) twice in a row. It may seem completely random, and that's caused by the random surface.

I mentioned skid, but the same applies to ball or wheel. For example a wheel has a wheel and axle. When it's 'following' the variations in the surface its riding on causes it to lean and wobble different ways, on a micro scale, but not with great effect on the leading driving wheels. That's why it's fairly repeatable in forward motion. However in reverse motion the -slightest- variation in the surface the wheel is riding on, just a grain of sand, will cause a lean/wobble in whatever random direction and amount,and very effective steer the bot on a random direction.

The mechanical assembly is not perfectly aligned. It can't be. Worse, it can -never- be aligned close enough to track in reverse as it does in forward, because the variations of the surface are -amplified- in the reverse direction. If the alignment/mechanical oddities/balance were 'off' enough in the forward direction, that it couldn't track repeatable, that could be fudge-factored / fiddle-factored to correct. But the effects will -always- be worse in reverse.

A real world analogy. Put your arm out the window of a moving car, with fingers flat, and hand pointed backwards 'with the wind.' It's not hard to hold your arm in a straight line. Now point arm forward, and it's drastically harder to hold your arm in a straight line. That's because when the hand is trailing the arm it's just following and along for the ride. But when leading it 'steers' where the arm points.