Different efficiencies in stopping DC motor via L293D?

This is from "Figure 5. Bidirectional DC Motor Control" of L293D motor controller datasheet:

Since the last three columns are all labelled "Fast motor stop" there seems to be no "Free-running motor
stop" in bidirectional use of L293D.

My thought was that the same label "Fast motor stop" implies the same time needed to stop if at same speed. I decided to test this and to my surprise it was not true. In addition I tried two other methods to stop and now all 4 show different time to stop behavior.

These are the bitlash functions used:

> boot
bitlash here! v2.0 (c) 2013 Bill Roy -type HELP- 956 bytes free
> ls
function stop3 { a9=0; d10=!d10; d13=1};
function stop4 { a9=255; d10=!d10; d13=1};
function stop2 {a9=0; d13=1};
function stop1 {d10=!d10;d13=1};
function startup { pinmode(8,1); pinmode(9,1); pinmode(10,1); d8=0; a9=0; d10=1; d13=0 };
>

The steps I did for the 4 tests were (200 is not full speed, behavior is dependent on the speed):

• boot
• a9=200
• wait until motor is at speed
• stopN

These are the 4 youtube videos:

I used http://rowvid.com frame by frame analysis. Since the Arduino Pro mini blue LED gets turned on when stop command is executed I determined that time, and then single stepped to the frame where wheel move completely stopped. This is the result:

stop1  1.76 4.16  d=2.40
stop2  3.35 5.99  d=2.64
stop3  2.54 5.26  d=2.72
stop4  2.95 4.75  d=1.80

So it turns out that stop4 does the hardest stop, turning on full speed and then setting 1A=2A. The worst is stop3, setting speed to 0 before setting 1A=2A.

It seems that the active motor break is best with full speed.

Is there anything else that can probably further decrease the motor stop time?

Hermann.

I have never used bitlash, so I don't know what those commands do. I also don't know what the numbers are for stop1 to stop4. I don't know which Arduino board you are using, and I don't know which Arduino pins are connected to what. Are you using analog pin A9 ? Which small Arduino board has A9 ?

The L293D has transistor outputs. I think the "fast stop" will only work with the 4 diodes as in the datasheet. The L293D has also internal clamping diodes, perhaps they can do that as well for small currents.
With the enable low, the outputs should be high impedance. That should result into a free running unpowered motor. However, the diodes are still there, causing a circuit that does not allow free running.

Some Arduino users set a reverse current for a short period for a faster stop.

You could try a modern mosfet motor driver.

I have never used bitlash, so I don't know what those commands do.

Sorry, I am so used to bitlash that I (incorrectly) thought it is clear, its an Arduino playground project:
http://playground.arduino.cc/Code/Bitlash

I also don't know what the numbers are for stop1 to stop4.

These are the functions I defined with different stop behavior, see the output of "ls" command in previous posting.

I don't know which Arduino board you are using,

Arduino Pro mini, no board, see the photo above.

and I don't know which Arduino pins are connected to what.

pin8: 1A, pin9: EN1,2, pin10: 2A

Are you using analog pin A9 ? Which small Arduino board has A9 ?

No, "d8=0" is bitlash short form for "digitalWrite(8, 0)", "a9=255" is short form for "analogWrite(9,255)" (9 is PWM pin).

The L293D has transistor outputs. I think the "fast stop" will only work with the 4 diodes as in the datasheet.
The L293D has also internal clamping diodes, perhaps they can do that as well for small currents.

I read and thought that the "D" in L293D (compared to L293) mean that I do not need external diodes.
Each motor takes 0.21A at maximum efficiency, and I did drive the motors with 12V from 3 LiPos (see data sheet).

With the enable low, the outputs should be high impedance.
That should result into a free running unpowered motor.
However, the diodes are still there, causing a circuit that does not allow free running.

That explains the behavior of stop3 versus stop4:
Setting speed to 0 in stop3 before stopping seems to be free-running then (2.72s).
Setting speed to 255 in stop4 [same as digitalWrite(9,HIGH)] seems to be full motor stopping (1.80s).

Some Arduino users set a reverse current for a short period for a faster stop.

I did that experimentally, but it does not sound healthy and I did read at several places that full speed reversing of motor is not something one should do, hear into this youtube video (reversing direction at full speed every second):

Perhaps I will have to give it a try.
I did normal stopping with my Arduino Uno robot at speed of 3.1m/s after 2 seconds (the LED gets turned on then) at the leg of grand piano 1.5m ahead of kitchen door:

The (high) speed did not avoid (loud) hard stop at kitchen door:

Here is complete "Arduino robot, first autonomous full speed test" video:

The used motors and wheels did show 9.89m/s in Motor test station:

The weight of robot was comparable, not sure why Arduino Uno robot did "only" 3.1m/s at full speed.
If it is friction at half table tennis ball (the only real difference) then I would not have awaited to loose more than 6m/s.

I am trying to get even more speed by more powerful motors.
And the robot has ultrasonic sensor now with range 2-400cm:

But even 4m is short notice if I cannot get stopping under control.

"Thunderstorm" robot does 3.1m/s on average with many turns, and is able to stop nearly immediately:

Not sure how to stop that abrupt, but the video proves that it is possible.

You could try a modern mosfet motor driver.

What would be the advantage of a mosfet driver over L293D?

Hermann.

HermannSW:
What would be the advantage of a mosfet driver over L293D?

Everything (just kidding not everything of course, probably a little more than everything).

If you are going to use stronger motors, the L293D is even a bigger problem.
A mosfet driver can be like this one : Pololu - DRV8835 Dual Motor Driver Carrier

Using a reverse voltage for a motor that is still going forward can be bad for cheap motors. The current will be higher than the normal currents. Some motor drivers have current limiters, and with good quality motors, I think it should be no problem.

That video with the fast stop is typical a motor-brake when a motor is shortcut. A mosfet driver can do that.
It depends a lot on the motor and the type of the motor. A very cheap motor probably won't brake a lot, but high quality motors for RC are far more efficient and will brake a lot better when shortcut.

For full brake a "enable" signal must be 100% active. When you use analogWrite(200), it is only 78% active, and also the braking is only 78% active.

Thanks Peter,

this really works!

Some Arduino users set a reverse current for a short period for a faster stop

I just did 200ms full speed motor reversal before really stopping.
The effect is phantastic, reduces time to stop from 1 second by previous best method to 0.2 second:

Copying in youtube video description with the details:

By a discussion on arduino.cc I learned that quick stop can be done by driving motor in reverse direction for a short time.

New function stop5 does exactly that, set enable to high (d9=1) and then reverse motor direction (pins 8 and 10), wait for 200ms and then call stop4.

Video shows this sequence of commands:
boot
a9=255
stop4
boot
a9=255
stop5

stop4 stops within 1 second (20.23-21.23), stop5 does stop in 0.2 second(!) (36.80-37.00).

＞ boot
bitlash here! v2.0 (c) 2013 Bill Roy -type HELP- 956 bytes free
＞ ls
function stop3 { a9=0; d10=!d10; d13=1};
function stop4 { a9=255; d10=!d10; d13=1};
function stop2 {a9=0; d13=1};
function stop1 {d10=!d10;d13=1};
function startup { pinmode(8,1); pinmode(9,1); pinmode(10,1); d8=0; a9=0; d10=1; d13=0 };
function stop5 { d9=1; d10=!d10; d8=!d10; delay(200); stop4 };
＞

Hermann.

That is indeed a big improvement (and extra stress for the motor ).

Just an update, I did stop motor from full speed (above 50km/h) to full stop by full reverse powering very often now, and have never seen a problem with that.

From physics lessons long ago at school I know that the distance s for constant acceleration dependent of time t is:
s = 0.5 * a * t^2

Regardless at which speed I start full reverse power braking, it is a constant negative acceleration. So I assumed that the slow down curve has to be somewhat quadratic.

In order to investigate that with my slow android camera (gives 15fps) I did draw North, South, East and West, doubled and doubled again to get 16 directions in Motor Test Station. After having done that I realized that what I did is well known:

Then I used a video for up to now record run with 14.37m/s or 51.7km/h, where I made the Arduino do a full stop by reverse powering for 1800ms. This is the animated video I created from it (whith blue lines from center nail passing the front lit LED). In order to know when braking happens, I lighted LEDs on pins 13, 1 and 0 in addition to the always lit power LED. This gives thick LED arcs easily distinguishable from thin line of just power LED on. In order to be able to see something the animated .gif is slowed down by factor of 10:

Next I determined roughly the angles of the blue auxiliary lines and determined the distance in meters to the point of full stop. Finally I played with coefficients of quadratic function in order to fit the measured points well and came up with 2.8 and -0.3 (you can view image in new tab to see it at a better resolution):

1073×569 85.2 KB

This shows pretty well that in fact the braking curve is quadratic, the linear term may be caused by friction. For completeness these are the 28 frame pictures being basis for the animated .gif. They are screenshots from video viewed by rowvid.com in order to know the time each frame happens at hundredth of second resolution:
https://stamm-wilbrandt.de/en/forum/mts.brake.frames.zip

Yes, more than 8m braking distance is a lot and a no go for robot running in house (at least in my house), but speed is 51.7km/h and I don't think robot moving autonomously will ever come into that speed range.

There is the problem of knowing how long to reverse power at a given speed to get to a full stop and do not start moving into the opposite direction. This may be solved by using a mouse sensor for detemining whether motion still happens. Since speed of both robot motors may be different (eg. when in curve), having two such sensors vertically and "looking" on each wheel's motion should allow to do a perfect full stop:

Last, but not least, the slow android camera is fine for recording normal stuff. For more details slow motion camera is useful, and I am happy that my younger son bought a LG G Flex 2 android phone with 120fps.

I did not find anything easy allowing to single frame step through a 120fps slowmo back and forth, so I googled and based on what I found did my own 120fps viewer (do "View Page source" for details). It shows a short 2.8 second video of Motor Test Station run without Arduino, just with a finger tap, with 341 frames, and does fps snap-in time:
http://stamm-wilbrandt.de/videos/120fps.html

Hermann.

Peter_n:
Using a reverse voltage for a motor that is still going forward can be bad for cheap motors.

Not just cheap motors - large DC motors must never be abused like this, it can physically
damage the machine due to the huge stall currents of a high efficiency large motor. Typically
controllers for large motors limit the current to the windings to prevent damage, and voltage
across the terminals is dominated by back-EMF

Mark, thanks for the warning.

I did roughly hundred of these full stop runs, all with the same 15V motor, here is the datasheet page with the details:
http://www.produktinfo.conrad.com/datenblaetter/225000-249999/228959-da-01-en-Motor_SFK_130SH_14190.pdf#page=5

I think this is not a "large DC motor" in your words.
Do the technical details for this motor say it is good or bad?
Which detail in spec is important to judge?

I did most of the runs in 15-16V even above the spec range.
Is full braking from 15.2V with 14.37m/s to full stop the worst possible wrt back-EMF?

What can be the problem, the motor itself or L293D motor controller?

I had quite some problems with voltage spikes when trying to drive a motor from ESP8266, never had problems with a real Arduino (Nano/Pro Mini). Are the "real" Arduino's more spike resistant than eg. ESP8266?

I do all these motor experiments because I am a software guy and have to try out what works on the hardware side and what does not work,

Hermann.

Oh you'll know a large motor, it drives industrial plant and weighs more than a person!

Hi Mark,

you did not answer my other questions. Since your statement seems to be on very large DC motors only, and 100 runs with my 15V 2.16Ncm DC motor never showed a problem, it seems to be save to do full reverse power braking, right?

Hermann.

I found another application for reverse powering robot DC motor other than braking:
Turning a robot powered by two DC motors without changing both motor speeds!
Just change direction (reverse powering) one DC motor for some time / until some sensor event.

This works fine for caterpillar robot

as well as two wheel robot:

Both animations were created with makeagif.com from 90fps (Raspberry camera 640x480) youtube videos (played at 25fps), therefore what you see is aready slowed down by factor of 3.6.

Hermann.