Motor Brake?

how do you program a motor to brake after it has traveled a distance? i want the robot to move forward 5 feet, and i tell the motors to stop (127), but the vex motors only coast and the momentum carries the robot further than i want. after the motors are running(225), should i make the motors go backwards a bit (110, maybe?) and then make them stop?

That would be about the only way to do it; the motors don’t have a “braking” mode.

Keep in mind, though, that your robot is coasting because if its mass, not because of the motors. If you quickly shift the motor into reverse, all that momentum will be shunted into the gearing between your wheels and the motor. This will increase your risk of damaging gears and general wear and tear on the motor. You mind wind up with your motors “breaking” instead of “braking” :rolleyes:

A better approach is to start slowing the robot just before it gets to its final position. If you can ramp the speed up at the start, and down at the end, it’ll be much easier on all the gearing & motors. The heavier/faster the robot, the more important this is.


  • Dean

You could create a braking mechanism for the robot to prevent undue strees on gears and motors. Given it would take some doing, but the concept isn’t that hard. build a mechanism that

A: presses against the wheels or the axles like the brakes on a car.
B: makes it impossible for the wheels to continue rotation via a metal shaft sliding into the spokes of the wheels or a similar device. this has the potential to do even more damage than running the motors backwards if done wrong. Use caution.
C: generates friction with the floor by pressing against it. hopefully you can be sure of the surface you will be driving on.

I have a competition that requires a similar ability coming up in the spring, so I look forward to seeing the solution you come up with.

Out of curiosity, about how long does it take a program for a robot that drives a set distance and then stops to compile and upload? I won’t know the distance my electric vehicle has to travel until competition day. Assume I have a really fast computer.


Depends on what program you are using. RobotC downloads really fast, about 5 seconds. EasyC and MPLAB have a much longer download time (i estimate around 20 seconds) Maybe there is a difference in download time between EasyC Pro and EasyC V2, but i’m not sure.


Another alternative is to write a single program that uses the digital inputs and jumpers to select different distances. You write different sub-programs for each distance that execute according to how you place the jumpers.

Suppose you reconfigure Analog inputs 1-4 to be digital (I prefer this to using digital inputs 5 - 10, because they’re on the end of the strip and are easier to see/feel). Using 4 ports gives 2^4 = 16 possible subprograms. Using more ports (say #1-10) gives 2^10 possibilities.

You could then map distances to jumper configurations, something like:

10 ft: 0000
11 ft: 0001
12 ft: 0010
13 ft: 0011

Incidentally, this sounds something like a Science Olympiad project. If so, is there still a limit on 4 AA batteries used at a time (with a total of 8 batteries impounded, with 4 intended for spares)? Last year, this prevented us from using a Vex robot for this purpose.

hmm…seems like the damage isn’t worth it. i think i’ll just make the motor stop maybe a second before the spot i want to be.

Furstoveall; this is the Science Olympiad Electric Vehicle competetion.
I considered using sensors/jumpers to tell the robot how far to drive, like using a Vex pot (which I don’t yet have) to tell the vehicle how far to drive, and that would probably work pretty well. They change the rules most every year, and I can’t for the life of me find my info sheet, so I’m not sure about the battery deal. I might not use Vex for this anyway though. It’s capable of doing the job, but it might not be the best for the job.

I’d suggest motors + encoder + PID code in C.
After tuning the PID constants, setting the distance is easy, with perhaps a potentiometer to further fine tune the distance

Is this is a common enough Application that it would be nice to have a 4cell + boost supply designed for it? Or is the intent of this rule to eliminate Vex and similar.

For my autonomous program I have the encoders read about 1/2 second after the robot has stopped driving forwards. Then drive back at a slower speed to where the robot should stop.


Though most people quickly point to the potential risks of motors braking, one must also consider the benefits.

I have used motor braking for autonomous navigation extensively over the past 2 years. I have found that if used correctly, the use of motor braking can significantly increase the reliability of your routine while not noticeably effecting the life of your motors.

My recommendation would be to ramp down your drive motors as the robot approaches the desired encoder value. Once the target is reached, reverse the motors at about 10% for ~150 msec before stopping them.

Good Luck

aha, i tried that this year after listening to you explain your “braking method” last year
and it works great!
(i use it for 300 ms but i dont really see a significant difference)

This sounds like a job for a PID loop!

Seriously - this is what PID was made for.

To clarify: I actually use a proportional loop in conjunction with motor braking.

Agreed, a full PID could certainly be used for navigation by encoders.