Re: Non-FRC Motor Controller?
 

I'm not saying this is the way it's done, but there is a third option. Most microcontrollers have a readable MHz system clock. Read the clock, turn Q1 off, read the clock until 2us have elapsed, turn Q2 on.

Re: Non-FRC Motor Controller?
 

The way they've drawn the arrows in Figure 4-4 makes it look like they're allowing current to flow through the MOSFET when source is more positive than drain. Doesn't the drain have to be more positive? It seems like even if Q2 is on it would only allow one way current (ignoring the diode - but they don't show flow through the diode...)

Re: Non-FRC Motor Controller?
 

The collapsing magnetic field in the motor's coils induces a voltage drop across the motor. This voltage causes current to flow in the direction shown in the Figure. Under these conditions, Q2's drain voltage is negative wrt its source (ground), but the gate voltage is still positive wrt ground.

Re: Non-FRC Motor Controller?
 

The Stellaris isn't just a microprocessor. It's a microcontroller. It has dedicated timing hardware connected to output pins. The software can set up all the timing in advance and let the hardware do its job.

Re: Non-FRC Motor Controller?
 

As shown in the schematic on page 23 of the document I referenced earlier, the Jag uses an Allegro MOSFET driver chip to drive the H bridge. The 2us dead time is handled in that hardware¹ and is configured with an external resistor.


¹ see page1 column2 paragraph4

Re: Non-FRC Motor Controller?
 

If you've seen how you can control the intensity of an LED via the Arduino library's analogWrite() function, it is the exact same principle for controlling a motor. How this is usually done on a microcontroller involves a circuit called a "timer", included on the chip's die with the processing core, which the majority of microcontrollers have (in some form). Basically, it increments 1 on every timer clock cycle, which is derived from the system clock, but may be the system clock divided by 2, 4, 8, etc (there are some chips which include a frequency multiplier to drive a "fast counter", but we won't talk about those).

The more complex portions of the timer include hardware to automatically toggle a pin on or off when the timer reaches a certain value - therefore, you can have it running in the background, and if you set the pin to toggle on timer count 127, you will have about a 1/2 duty signal coming out of the pin it is toggling (assuming timer overflow at 255, which is common). There's also more complex functionality related to receiving an interrupt when the timer overflows, or recording the value of the timer when a pin changes state, etc. But we just care about the automatic pulse generation.

You can, basically, drive a MOSFET directly from the pin of a microcontroller. However, it is not ideal. A MOSFET works solely on charge potential on the gate (switching pin) of the device. This means no current flows into or out of the gate pin... long story short: it is a capacitor. When you turn the signal to the gate from "off" to "on" (and to some extent the other direction too), it spends time somewhere in between full on and full off as the microcontroller pin must overcome the gate capacitance - this is bad, because when it is in this stage current still flows through it, but the MOSFET has appreciable resistance and dissipates energy as heat.

What does this mean for you? You want to change states as little as possible. Someone mentioned the Victors switching at roughly 15kHz, I think the Jaguars switch at 30kHz. That is actually pretty fast. PWM frequencies as low as 120Hz can be used (and I think that is the frequency which older Victors used).

Do you really need to consider these things? Maybe, maybe not. I made an H-bridge out of discrete MOSFETs, and it runs cool. If you are worried you can buy MOSFET driver chips or MOSFETs which contain their own drivers, that's really all the extra circuitry you'd need.

Re: Non-FRC Motor Controller?
 

Victors switch at 150 Hz while the Jags switch at 15 kHz. This is simply a design choice between the two manufacturers. The lower switching frequency gives better low speed power but sacrifices linearity over the power range. The higher switching frequency interacts with the motor inductance to give a more linear response over the entire power range but suffers at low power. The FETs used in the Jaguar have slightly less "ON" resistance so in theory should run a little cooler, the Victor has three FETs per leg vs. the two used in the Jag.

The MOSFETs used in the Jaguars are driven by a high current gate driver capable of 2 amps of gate drive.

Re: Non-FRC Motor Controller?
 

What do you mean by "better power" in this context.

Re: Non-FRC Motor Controller?
 

More current per pulse is applied to the motor during the lower throttle values at the lower switching frequencies.

Re: Non-FRC Motor Controller?
 

I also seem to recall that a lot of the heat produced from a transistor in a PWM application comes from the time when the transistor is transitioning from ON to OFF... when it is fully on, it doesn't give off much heat because the voltage drop across it is fairly low, and when it is fully off it doesn't give off much heat because there is essentially no current flowing through it... but the transition time involves current flow and voltage drop and while very brief is non-zero. Thus a high PWM frequency could lead to increased heating relative to a lower frequency. The PWM frequency needs to be matched to the transistors that are doing the work... faster transistors can handle higher frequencies.

Its easy to manipulate the duty cycle at a constant frequency, but it seems that it could make sense to shift PWM frequencies "on the fly" as well as duty cycles in order to get the best of both worlds when it comes to speed controller response....

Chuck McManis, a BattleBots veteran, has presented some well-written information on speed controllers and MOSFETs on his site:

http://www.mcmanis.com/chuck/Robotic...sc2/index.html

Robot Power has some interesting designs, including schematics,

http://www.robotpower.com/

Which led me to an interesting part that I'm looking forward to trying out:

http://www.infineon.com/dgdl/BTN7960...17642084e76a7c

If I recall they are about $5/each on Digikey and throttle 30A easily when simply hooked up to a PWM source (PIC, Arduino... even a good old 555 timer should do it...) Mind you, as Chuck points out in his article about FETs, just because the silicon on the chip can handle high current doesn't mean it's package or your circuit board can!

Jason

Re: Non-FRC Motor Controller?
 

The BTN7960 and 7970 are nice chips. Cost has gone up. When you look at the cost for some of these motor drivers, the jag and vic appear to be a bargain.

Re: Non-FRC Motor Controller?
 

Jason,
In the Victor, the series resistance of three FETs in parallel is 4 mohm. At 100 amps that would equate to about 80 watts total device dissipation, or 12.6 watts at 40 amps. The FETs used in the Jag are lower on resistance but there is only two of them now. At 40 amps, about 6.4 watts at 100 amps, 40 watts.

Re: Non-FRC Motor Controller?
 

Those are some interesting specs on the Jag and Victor, Al... I know that once we tried the Jags in our drive system our drivers wouldn't let us go back to the victors... the fine control response was just that much better. That response was due to the high PWM fequency, but I hadn't looked into just how much more efficient the new FETs were... that is quite an impressive difference... I guess they can switch as often as they want and still run cooler than the victor.

However as to the original poster's request for information on non-FRC speed control options... there are lots! Check out RobotShop, or any of the online robotics vendors... ROBOT or SERVO magazine... or take a look at the end of the BTN7960 datasheet listed above... if you can make a circuit board and program a microcontroller you should be able to build a decent speed controller for less than $20 that should easily handle the power requirements for a mid sized robot.... and without many of the hassles that come from building the control from "scratch".

Jason