The Vexmen of Brandywine Robotics

Blog Post

Troubles Tripping Circuit Breakers With 10 Big 393 Motors?

This information and post would not be possible without the contributions on the Vex Forums made by James Pearman, a moentor on team 8888 in California.

Well we all thought it was great when we could use as many of the big 393 motors as we would like last year, but now we don’t have a choice and Vex no longer carries the smaller 269 motors. So what tends to happen is you run your robot too hard and the circuit breaker trips either in the motor of the Cortex stopping all activity for a period of time before it resets – sadness ensues.

This is not Vexnet drop outs, but due to the fact you are drawing too much current through the components for too long. In simple terms, you are pushing your robot too hard jerking it about and doing bad things.

What is happening inside the Cortex is when you tell your motor to go from 0 to 127 instantly, a current “spike” will happen. Driving all four drive motors at once or all your lift motors at once will do that. Also continuing to drive into a wall, lifting under the bridge, futilely going over the hump, or fighting with another robot can lead to higher current draw as well.

Here is a picture of what happens when you jam the motor to full speed when viewed on an oscilloscope that measures the signal and the current seen by the motor and cortex.

As you can see in the picture, the yellow line is the current and the blue line is the PWM signal being sent. (more on PWM later on). Notice how the yellow line spikes up as the current goes like crazy into the hungry motor wanting to drive at full speed. Multiply this by four for your drive wheels and whatever you are doing for your other arms and you will be tripping the circuit breakers in no time.

The circuit breaker is called a PTC which measures the temperature and saves the Cortex or motor from a horrible permanent death by switching off the current for a time. If you open up the Cortex or a motor you will see these yellow looking things.


Source

Inside the Cortex there is a PTC on motor ports 1-5 and then a separate PTC covering ports 6-10. There is also a PTC in each of the 393 motors. You should see only one side drop out or one motor drop out but you might trip everything.

So what we want to do is even out that current spike from happening? There are a few solutions, like drive at a more reasonable pace but that is difficult to control or you can use some software to get you out of trouble. Those longer duration current draws will not be helped by this solution, but the normal driving like a madman and autonomous changes to full speed movements will.

Option 1: Slew Rate Control

Havok just got this code last weekend and they stopped all their circuit breaks for the rest of the day. Others have been running with it for a while like 81M, 90C, and a few others. Since other teams are breaking down due to current, it’s time to share the wealth.

The most simple solution is called slew rate control which will gradually move your motor to the desired speed over time. Gradually is sub-second, but it drops the current spikes significantly.

In this picture, the slew rate has been applied. You can see the yellow current lines are well within range. This will keep your motors and Cortex happy unless you try and engage in a serious shoving match.

Here is a link to the code:
Original posted code on Vex Forums

Come see Glenn to get the 81M function file to add to your code.

1) Include the functions file right below the competition template include. Or put the information into your code. The file should be in the same directory as your code so robot C can find it.

#include “81M_functions.c”

2) Add the following line to autonomous and driver control (or just once if you are keeping tasks active across the game controls but that is more advanced). You can elect to use slew rate only in driver control if you would like.

startTask(“MotorSlewRateTask”);

3) Replace any reference to motor[yourMotorname] with motorReq[yourMotorname]. This can be accomplished through Edit –> Find and Replace of motor[ with motorReq[

Do not compile directly from the functions file, it won’t work since there’s not a main() function! You have to compile and download from your team’s code file.

One new concept for most teams will be needed – background tasks in Robot C. You need to start a background task to set the motor values to the motor versus what you requested them to be set in motorReq[]. What a background task does is it loops around in the background at the same time as your current set of activities. This is especially useful for things like setting an arm height and having the task constantly get you there in the most efficient means possible, or you can keep track of where you are on the field, or any number fo things. In this case we’ll be seeing what we want the motor to be set to and what we will allow the motor to step to.

Each of the background tasks needs to have a while loop to keep going or else it will finish up in one pass. Also, in order for the control to come back to the other tasks, you need a bit of a wait to allow robot C to see what else needs to be done. In the motor slew rate task, we are going to go at a pretty good rate of speed and as just about as fast as the motors respond. We will wait between 15 and 20 milliseconds. If you don’t your driver control task will never get any execution time.

What this specific background task is doing is looping through all the motors on your robot and seeing what the motor is set to right now and how far away you are from that target value. The motorReq[] is what you want it set to, the motor[] is what it is, and motorSlew[] is the stepped value that gets you on the way to your target value. You step up or down by the slew rate of 20 each time through. So it takes a few 15 millisecond loops to go from 0 to 127. But this is a good thing since you will not be spiking the current too much. It’s not really perceptible to you in most cases.

One downside is that it works on the slow down side too. So it takes a slightly longer time to jam on the brakes for your wheels. If you want to play with the code to allow for this condition, go ahead and change it.

One other downside is if you are trying to run a P or PID loop, the slew rate acts as a damper to the system not allowing for huge swings in signal that elongates how long it takes for your arm to get into position. However, it will save the current spikes so pick your poison.

Second Option – Smart Motor Library

Now there is a second solution to this that was alluded to in the PTC link above – estimating the current of the motor and stop overheating from happening all together. This takes things one step further. It is much harder to implement too.

Smart Motor Library

The smart motor library will use slew arte plus it will estimate either the current or temperature of the motor base upon the signal you give it versus the counts received from the I2C motor encoder or a potentiometer on the arm. It will tell the motor to back off if it sees trouble. It works fairly well, but instead of dropping out all together, you will get your motors slowed down for you by the software.

If the library sees you are drawing too much current because your wheels are not moving, it will ramp back the power to those motors to try and prevent a PTC trip. The theory is waiting a short amount to get the wheels to catch up is better than the few seconds left waiting for the Cortex to reset and Vexnet re-establish itself.


Original post

In this picture you can see how well the estimated current matches the current measured going to the motor. You can install LED lights to let you know you are being limited by the software too!

The downside to using this library is if you have a P or PID loop, the scaling back of the motor makes the constants you took so long to tune get really off and cause undesired activities.

The other downside is it takes a bit of coding effort to enable it. You call SetMotor(motor_name, new_speed) versus calling the motor[] or motorReq[] variables. So no simple find and replace for this one.

PWM Signals

A PWM signal is a pulse width modulated signal meaning the cortex sends out bursts of control to the H-bridge 2-3 wire adapter. The longer the signal, the difference in the motor value you get on the other end.

IN the Vex motors, a short PWM burst corresponds to full speed negative and 0 is half way along, and full speed is all the way along. The 2-3 wire converter takes the pulse and gives the right voltage to the motor to drive that appropriate speed.

PWM explaination

More information on the 393 current draw when each of the pWM signals are given:
motor Torque curves of the 393 motor.