Motor in the IVth quadrant

VEX V5 Technical Support UNOFFICIAL Tech Support
1

Hi,
I wonder what should I expect from a motor pushed to the 4th quadrant of the speed-torque curve.
Let’s say I have VEX 393 motor that is turning at negative speed (relative to the applied voltage/power),
either due to inertia or externally applied torque.
Now think of it in the terms of this curve:
https://vexforum.com/index.php/conversation/post/75244
where the speed line would continue down on the right side below the X axis - the torque would keep growing.

Can I expect/simulate the motor in this state as having proportionally higher torque up to, like, 29 in-lbs at the speed of -100? (In other words, when set to full speed forward, you need to fight 29 in-lb to turn in 100RPM backwards)
Possibly consuming almost 10A?

This is a real situation (significant mass attached to a motor flipped from 127 to -127) and the motor/controller/battery might become
exposed to such a situation for a split-second during the transition. It could easily happen to PID newbies with very badly choosen Kp
and we have even intentionally triedrisked it once on a robot while capturing a datalog to better understand the dynamics,
but I am rather trying to simulate this system to explain the physics to the students and allowing them to experiment with different
regulator implementations w/o destroying a real robot.

Now, how badly would a real 393 + motor controller handle such abuse? The back-EMF would immediately double the voltage stress on the H bridge in the motor controller, not even counting the wiring inductance. The 10A momentary current may or may not trip the motor or cortex PTC, but would certainly heat it up a bit. The 29 in-lb torque won’t make the gears happy either. But those motors do see such abuse quite frequently, don’t they?

2

Interesting question, but I don’t think you can straight-line project into the 4th quadrant; I think you’re going to have to measure it. Seems you’d need to model the device functioning as a generator under electrical load…

… and I don’t think @jpearman’s curves are going to extend into that domain cleanly/linearly.

That’s a good explanation. But I doubt things are going to work out that neatly. Not to mention that the PTC devices are going to enter the non-conductive region before that happens.

Did you get useable data? What did it tell you?

You could run the experiment while powering a motor through a power expander. Then the most you’d have at risk is the motor, controller, and power expander; the Cortex wouldn’t be at risk.

Again, interesting question. Pop open a motor controller and determine what they use for the H-bridge. Depending on the device, it could be a diode when operated in the reverse condition. In that case, the current wouldn’t backfeed until you hit breakover voltage, perhaps releasing the magic blue smoke, which would stop the whole process. If the H-bridge component isn’t bipolar, (MOSFET?) could it backfeed then? Don’t know, but if it did, something is going to have to dissipate the power. That device, either in the motor controller or the circuit powering it (power expander, in my suggested scenario) isn’t going to eat 10A lightly.

3

Don’t think that’s how you are supposed to interpret the graph.

I really don’t think there is a 4th quadrant. But I could be wrong.

It is Speed - which means it is a scalar quantity. Strictly speaking, there is no negative direction. Even if the motor is turning In The reverse direction, we should only be looking at the magnitude (or the number) that’s all.

4

@nenik

H-bridge MOSFETs inside MC29 motor controller are protected by diodes.

If you spin motors connected to unpowered Cortex at their nominal speed, you will see the LEDs light up on the Cortex, because motors serve as generators and protection diodes rectify this generated voltage back to the cortex. At nominal speed motors expected to generate about 7.5 volts matching the battery voltage.

The way I understand it, all motors’ EMF is rectified back onto cortex power rails and voltage across motor coils will not exceed voltage across rails + 2 times the voltage drop on the protection diodes. Unless motors spin much faster than their nominal speed and generate enough energy to power all loads on the cortex rails, you will not see more than 8 or 10 volts.

Lets assume that for a short time, after MC29 cuts positive current flow, the motor could function as the generator and is able to power Cortex and all its load. Also, lets assume it could provide voltage matching the battery such that the battery will not be supplying any current.

Then, if you command MC29 to open H-bridge path for the current in the opposite direction, there will be two short circuit s each including motor coils as generator (power supply), motor coils’ internal resistance, motor’s PTC, open MOSFETs, and protection diodes (attached to other two MOSFETs). This should result in the stalling current, which is limited by coils resistance, but no double voltages anywhere. (edit: that thinking was incorrect, see next @nenik’s post, circuit includes main battery but no diodes).

Then, as @kypyro said above, the PTC will enter the non-conductive region soon enough to protect H-bridge MOSFETs before they could get damaged from overheating.

In my experience, motor controllers never die from erratic software control, but only from the damaged and shorted wires (when there is no coils resistance and PTCs to limit current and protect MOSFETs).

However, as some of us had experienced during Nothing But Net season, if you command erratic power changes to the motors then one of the internal gears will take most of the damage and fail pretty soon: https://vexforum.com/index.php/attachment/5670d633a8e0c_flywheel_damaged_gear.jpg

So, implementing some sort of the slew control, like limiting power change to 20 units per 20 msec, would be a good idea.

5

Thanks for the feedback.
On the electrical side, things are quite simple. The motor is pretty much a RPM-dependent voltage source in series with internal resistance. This is where the stall current comes from - zero back-EMF, thus the stall current is battery voltage (minus the driver losses/PWM) divided by the internal resistance.

The motor driver fully open in opposite direction is quite simple too, with 2 conducting FETs in the bridge, it is pretty much a low-impedance (the combined bridge resistance is in tens of milliohms, less than that of the battery) voltage source. So, with motor being forcefully turned full speed in the opposite direction, the back-EMF of 7V gets added to the driver’s 7V, and this 14V pushes current through the winding resistance of <2ohm, thus over 7A. Current is what causes torque and unless the magnetic circuit gets saturated, pretty much linearly.

So there might be some step around the zero speed due to cogging and stall friction, but the overall slope should stay the same.

OK, I did. MC29 uses FDS4935 P-FET at the high side and IRF8313 N-FET at low. Cortex is similar, though the low side uses AO4818. All of those are 30V devices, so there is quite some headroom for the voltage stress. All of them are FETs with the internal body diode structure and can handle pulse currents in excess of 30A. So that part of equation is pretty sound (except maybe for shorts, since everything else on the power path is deliberately strong and the PTC isn’t as fast)

Not really - based on the direction, the back-EMF would change polarity. Thus, it would either subtract from the controller-provided voltage, or add to (easily extending over the battery voltage).

Yes, we’ve gathered very interesting data, though the experiment was biased by its structure - the gravity (arm swinging overhead 180 degrees) and the rigidity of the parts used. Anyway, it supports my theory - when the arm was still moving against the applied power, the braking torque was immense (stopped the shaft pretty much instantly), while to actually get the arm moving back took much longer (“only” stall torque available). The data also show a beautiful resonance in the arm, which I initially mistaken for quantization noise. See the data excerpt below (sample, time, angle+delta, motor power)


266 , 3.330, 3062+34   , 127
267 , 3.340, 3096+33   , 127
268 , 3.350, 3129+31   , 127
269 , 3.360, 3160+32   , 127
270 , 3.370, 3192+34   , 127
--------------------------------------------
271 , 3.380, 3226+17   , -127
272 , 3.390, 3243+46   , -127
273 , 3.400, 3289+24   , -127
274 , 3.410, 3313+15   , -127
275 , 3.420, 3328+6   , -127
276 , 3.430, 3334+1   , -127
277 , 3.440, 3335+0   , -127
278 , 3.450, 3335+0  , -127
279 , 3.460, 3335+0  , -127
280 , 3.470, 3336+1  , -127
281 , 3.480, 3336+0  , -127
282 , 3.490, 3336+0 , -127
283 , 3.500, 3336+0 , -127
284 , 3.510, 3333-3 , -127
285 , 3.520, 3314-19 , -127
286 , 3.530, 3290-24 , -127
287 , 3.540, 3274-16 , -127
288 , 3.550, 3251-23   , -127
289 , 3.560, 3228-23   , -127
290 , 3.570, 3205-24   , -127
6

I don’t know what I was thinking before. Now, that you have explained this so clearly - it became very obvious! With FETs resistance close to zero - the circuit is pretty much the main battery and motor’s EMF source in series supplying voltage to motor’s internal resistance, thus almost doubling stall current at the beginning.

However, I have some questions about your results:

  1. What was your exact setup? I assume you plugged motor into MC29 and not 2-wire port on Cortex. Did you measure angle with quad encoder or IME?

  2. Do you have an explanation for samples 271 and 272 or they look to you like instrumentation error due to some sort of delay in receiving sensor value?

  3. It took about 60 msec to fully decelerate, but probably less time, assuming delay in sending command to motor controller. Then there was about 60 msec of no apparent movement, then 50 msec of acceleration but to a slower velocity.

It looks to me like it was picking gear slop when the readings were around zero, and then smaller steady velocity was achieved as a result of the reduced PTC conductivity. Did it achieve faster speed (around -34) later?

  1. If you are going to conduct more experiments - you may want to log both IME and quad encoder values. The the difference between those readings could give additional insights into how motor’s internal gears behave.

Also, here is a great thread that describes RobotC firmware timing in respect to tasks and how it relates to sensor input (an important topic that still gets me confused). You will probably, find it very interesting:

7

  1. On the setup: think long thin arm fixed to a gear, with heavy end. Pot to measure angle (~15 “ticks” per degree). Values obtained through datalog. Motor through MC29, so the command delay could be anything between 2 and 50ms, based on luck (is there a way to phase control loop to the motor command delivery?)
    Likely important detail - pot was neither on the motor nor the arm, but rather another gear, not in the way of force.

  2. I have a theory, which might be wrong - flexing of the arm. There was more resonance at 287 and even later on when the motor stopped (beyond 290). But yes, datalog phase noise would explain it too :slight_smile:

  3. Flexing + gravity. The motor switchover point was with the arm just horizontal, moving down. So both the momentum and gravity were highest, fighting against the motor. The motor had enough power to stop the gears, but the heavy end surely went further, storing the kinetic energy into the arm flex, then getting catapulted back up, relieving the motor a bit at sample 286. It never reached -34, fighting gravity. The code also did cut power 200ms from the switchover (with arm going up for another 200ms. I regret we don’t have this experiment on camera). And no, I don’t think the PTC tripped - that would have much more pronounced effect.

  4. Great idea, next time we get crazy enough (and not on a competition robot), I’d suggest it.

Thanks for the links to the threading internals. Deep in the thread, it even shows a way to phase-lock the control code to the motor update timing (using nIfiSPIMsgCounts). What I still wonder though, is the precision of the datalog timing. We used 10ms samples, I though the cortex was quite idle on the user side, but checking the code for the experiment, it was likely busy waiting: “waitUntil(SensorValue(armPotLeft) > 3200);”.
So, how precise would be the datalog timing?