Re: Non-FRC Motor Controller?
 

The project is making a small to mid-size RC vehicle. Though I'd like to have forward and reverse, it's not totally necessary (I just think it'd be cool to have something that drives), so, for the sake of discussion, let's assume I only need single-directional control.

Re: Non-FRC Motor Controller?
 

That's what the Vics and the Jags do. But the circuit must be designed and controlled properly, using appropriate FETs.

See page23, and page19 Figure 4-4, of this document:

http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf

Re: Non-FRC Motor Controller?
 

I suggest you take a look at the jaguar manuals to see the complexity of driving MOSFETs. Depending on the design, it might take some circuit black magic that would be beyond your ability.

Re: Non-FRC Motor Controller?
 

Are you trying to actually build the electronic motor control from scratch? (If so and you settle for just one direction of motor movement the problem is still advanced but incrementally less complicated).

If not then existing solutions that were previously posted at the start of the topic are cheaper than the Victors and Jaguars and benefit from mass production to keep that cost low. Course if you are using FIRST specification of motors your selection from that list will get more expensive and smaller.

If you're using FIRST specification motors the Victors and Jaguars are not a bad price for what they do.

Can you clarify your intent? I'd prefer not to see your topic derailed.

Also if the price of the Victors is your primary concern let me refer you to this topic from today:
http://www.chiefdelphi.com/forums/sh...d.php?t=106265

Perhaps that will ease your budgeting concerns.

Re: Non-FRC Motor Controller?
 

So, looking at figure 4-4, is this interpretation correct? The basic "OFF" state is q2g and q4g high. To go forward, q1g goes high, then after a little q2g goes low. Back off, q2g high, then q1g low. Reverse, q3g high, then q4g low. Back off again, q4g high, then q3g low. At each "then" is a small delay.

Then what are those zener diodes for (assuming I'm identifying them correctly)? Just in case there's a switching delay that isn't supposed to happen the MOSFETs don't get fried?

And then I can infer there's an oscillator that drives a clock for the whole thing? And the PWM signal is somehow fed into this oscillator that changes the frequency (and forward/reverse)?

Am I understanding this correctly? At this point, it's just theoretical (clearly that's above my skill level), but it's still interesting to understand how all of those "black boxes" work.

EDIT: @techhelpbb - thanks for the link! The links earlier up in the topic were very helpful - I think they give me enough information to make an informed decision.

Re: Non-FRC Motor Controller?
 

rb,
To start the zener diodes are a normal result of manufacture in these devices. there is a typo in the description, it is Q4 that is ON not Q2. In the jag, the control causes only the high side to turn on and off while the low side completes a path for current as described. Note the three states in Fig 4-4. The on board micro interprets the pulse width modulation on the input or the CAN input and converts that to a digital value. Then it generates switching signals to control the output circuitry. There is no relation from control PWM to output PWM pulse widths or frequency. Check the schematic at the end of the document for the actual circuitry and recognize that their is a secondary power supply to generate the high gate currents used in this design. You can get more info by looking at the gate driver here...
http://www.allegromicro.com/Products...Datasheet.ashx

Re: Non-FRC Motor Controller?
 

I think you mean the body diodes of the MOSFETs.
Those are part of the MOSFET and allow current that would reverse the polarity of the MOSFET transistor itself to flow past it instead.

Many other details applicable to the circuit apply. Such as field collapse in the motor. Heating of those diodes. Synchronous rectification. I'd read the text on it.

The Jaguar contains a Stellaris microcontroller. Think small computer. The signals go into the Stellaris. The Stellaris requires an oscillator like most computers. The Stellaris processes the inputs and outputs and produces a new signal that it's programmed to produce from each input that it encounters (sometimes based on additional inputs and outputs as well).

Re: Non-FRC Motor Controller?
 

Yes, at some point the PWM has to be digitally processed - I think 1-49% is reverse, 50% is neutral, 51-100% is forward (based off of reading the WPILib source a while back, so might be a bit off). The code on the microcontroller must be very tightly optimized if they're generating the pulses on the fly - no interrupt timer will give you the time resolution you need - they must be relying on the actual instruction processing speed of the microprocessor. That manual talks about delays in microseconds...

So those diodes are part of the MOSFET? That manual says they're arranged in a circle under the fan - those heat sinks must dissipate a lot of power. I don't quite grok how the synchronous rectification works - seems like black magic to me. The energy in the motor has to go *somewhere*. It's just a matter of where and how quickly (right?). Maybe if they had all that current switched to a capacitor or something, it would make sense, but I don't understand how they get an order of magnitude less dissipated energy without channeling that energy TO somewhere.

Re: Non-FRC Motor Controller?
 

The electrical energy going into the speed controller goes out to the motor, and some of it is dissipated as heat by the MOSFETs.

The motor does mechanical work (that's the whole point of having a motor), and it also gets warm.

To size the speed controllers you need to figure out how much mechanical work you need to do. Then you can select motors based on the rpm/torque requirements, and look at the current requirements and then select speed controllers.

Re: Non-FRC Motor Controller?
 

Courtesy of timers, purpose built hardware functions and the very sequential nature of code execution itself it's very doable with a microcontroller of this scale.

In point of fact many cheap electronic motor controllers use Microchip PICs and Atmel AVRs to perform this function, just slower and with less features.

Yes.

Yes the fan blows directly on the MOSFETs to keep them from overheating.

In other applications where weight and size would not be an issue heatsinks could be used.

In the current design there is no additional headsink beyond the packages of the MOSFETs themselves (obviously the MOSFETs have a little exposed metal on them someone might consider a heatsink).

The Jaguars I've seen have a plastic retainer around the MOSFETs that keeps them apart (generally the exposed metal on these MOSFETs is actually connected to one functional part of the MOSFET, it can carry an electric charge just as easily as the other connections on the MOSFET, for this purpose best to keep them apart).

In effect the issue with synchronous rectification is that the body diodes heat up as the energy coming back from the motor dissipates. The MOSFET transistor (so long as the polarity of the current flow is considered) when fully turned on would have less resistance than the MOSFET body diode. Therefore it makes sense when possible to turn on the proper MOSFET transistor to take the current away from the body diode. The body diode would simply get hotter and take longer to allow the same current to flow. The savings is merely what gets hot as the energy moves. Storing the energy instead of letting it dissipate would be difficult because the exact timing and amount of energy flowing is hard to predict, better to let it dissipate.

Would the circuit function without that feature, yes. However, the MOSFETs as a package would get hotter. Obviously as designed getting rid of heat is a good idea so long as it doesn't make anything significantly more expensive.

Re: Non-FRC Motor Controller?
 

For the forward direction, Q3 is always off and Q4 is always on. So for a single-direction drive you could remove Q3 and replace Q4 with a shunt.

During the ON portion of the output PWM cycle, Q1 is ON and Q2 is OFF.

During the OFF portion of the output PWM cycle, Q1 is OFF and Q2 is ON.

Q1 and Q2 must never be ON at the same time (I think you can see why). Thus, there is always a slight "dead time" where both Q1 and Q2 are OFF when switching states. During this dead time, the intrinsic diode in Q2 allows the inductive current in the motor to continue flowing so it doesn't create a large voltage spike.

So, during the OFF portion of the output PWM cycle, the stored energy in the motor's coils causes current to continue flowing through Q2 and Q4. This current maintains the motor's torque during the OFF portion.

Re: Non-FRC Motor Controller?
 

The microcontroller's timer interrupts must be highly optimized then... at full frequency on a PIT you can't do much of anything between ticks AFAIK, especially if you're on an embedded system.

Anyway, thanks everyone for you help. I learned a lot!

Re: Non-FRC Motor Controller?
 

rb,
The output frequency for the jag is about 15kHz. I can bet that the clock frequency is much higher than that.

Re: Non-FRC Motor Controller?
 

In general, your statement was true only a few years ago. Since then, microcontrollers have had an incredible growth in computational horsepower. It makes being an electrical engineer a lot of fun right now, because we suddenly have gobs of "free" computation to throw at problems. We are literally able to replace physical objects with lines of code, and that is freaking cool.


For reference, the 2006 IFI controller's microcontroller was a PIC18F. These perform on average one 8 bit operation every 4 clock cycles. The Jaguar's microcontroller is an M3-Cortex, which on average performs 1.25 32 bit operations each clock cycle. If they were clocked at the same speed, the M3 performs 5 times as many operations and those operations do more work. Additionally, the associated peripherals do more of the work, and handle things like quadrature encoders without bothering the main core.

Long story short, there is so much additional capability that they end up running the core much slower than it is capable of.

Re: Non-FRC Motor Controller?
 

All I'm saying is that the "DEAD_TIME" period is 2 us. Are the interrupts *that* fast? KHz, sure, but being able to control time to that resolution? They have to be either relying on the instruction speed of the processor to do a delay (noop loop) or sending a signal to a delay circuit, don't they? Or maybe I just don't have enough faith in the hardware...

I guess if the time is available on a port a tight loop with inportl or its moral equivalent could do it. The clock speed is what, a few MHz?