Jaguars vs Victors [Archive]

tux

24-02-2012, 12:34

Thanks for all the replies!

What gear ratio are you using? Hopefully not just CIMple boxes with no downstream sprocket reduction.

I don't know exactly. It is the CIMple gearboxes, but those drive small pinions and in turn chains and a set of larger sprocket gears at each wheel.

I had mentioned the possible need to go with larger sprockets, but the team did not look happy at that prospect. I still think it may be needed....

Are you using pneumatic wheels by any chance?

No.

Some teams have reported that 1/8" center drop is not sufficient for pneumatic wheels.

I hadn't though of that. On a hard surface it turned very easily, but the test drive was our first time on any sort of carpet. I'm not sure how much work it will be to drop those center wheels down more.

If our wheels are not air-filled, that is not likely to help?

The strange thing is that it was driving around pretty well just the day before... On the 2nd test drive it started out Ok, but then after trying to go over the ramp once, all we could get was flashing red. We tried a fresh battery, but it was all the same, even just trying to move straight forward.

One thing the Jaguar FAQ mentioned is a too-tight chain. I remember working pretty hard to get those chains on. How much of a factor might that be?

Ether

24-02-2012, 13:03

I hadn't though of that. On a hard surface it turned very easily, but the test drive was our first time on any sort of carpet. I'm not sure how much work it will be to drop those center wheels down more.

If our wheels are not air-filled, that is not likely to help?

Dropping the center wheels further will help greatly, if that is the problem. Of course, too much drop and you'll have a bot that rocks back and forth.

One thing the Jaguar FAQ mentioned is a too-tight chain. I remember working pretty hard to get those chains on. How much of a factor might that be?

If the chain is so tight that it doesn't budge at all when you try to wiggle it, it is too tight. Tight chains add friction.

Matt Krass

24-02-2012, 20:26

I'd just like to point out something about this situation.

First, let me be upfront and say I'm not the biggest fan of Jaguars, I prefer Victors because I find them simpler, smaller and generally more robust. I also find that they can take more roughhousing than the Jaguars, which give up somewhat easily in my opinion.

That said, your Jaguars are trying to tell you something, if your system is constantly going in to fault mode and shutting down, your solution should not ever involve getting rid of the device that is shutting you down in favor of one that will ride things out until the (bitter) end. It is faulting out for some reason and you should stop to think about what reason that is. Perhaps the Jaguars are giving up too easily, but I suspect (as others have suggested earlier) you have a legitimate problem.

Bottom line, if your robot is complaining a lot, it might just be whining, or it might be warning you about a problem before it's too late!

I think you've already learned this lesson, but I just wanted to reinforce it.

Kevin Selavko

24-02-2012, 20:48

Could it be that the output wires shorted together when the robot went over the bridge?

PAR_WIG1350

24-02-2012, 21:13

Could it be that the output wires shorted together when the robot went over the bridge?

That should not be possible if everything is properly hooked up and insulated; the wires should be insulated right up to the point where they meet the Jaguars making shorting impossible. With other motors, This is more likely since unshielded female spade connectors can shake loose and come into contact, but these shouldn't be needed with CIMs

vraimondi94

24-02-2012, 21:50

Our team has had a similar problem it could be due to
1) The chains being to tight on your drive train
2) The motors trying to do too much work on the robot and the jaguars are resetting themselves
3) Your gear ratio on your drive train is geared to low and you need more torque
4) Your robot might be too heavy

Solutions:
1) Loosen chains on your robots (unless your not using chains)
2) Use a larger guage wire on you robot and jaguars
3) Change the gear ratio going from small to large
4) Loose weight (I suggest weight watcher :) )

Ether

25-02-2012, 11:33

your Jaguars are trying to tell you something, if your system is constantly going in to fault mode and shutting down, your solution should not ever involve getting rid of the device that is shutting you down in favor of one that will ride things out until the (bitter) end. It is faulting out for some reason and you should stop to think about what reason that is. Perhaps the Jaguars are giving up too easily, but I suspect (as others have suggested earlier) you have a legitimate problem.
^^^ Quoted for truth. If time and resources permit, find the root cause of the problem and fix it.

Alex Chambers

25-02-2012, 13:35

Im not sure why your getting this error but if it makes the jags not work on other systems this might help you to get them running again.I helped fix a similar problem for another team through firmware this year. Their robot encountered the problem when running two cims and using pwn were their jaguars acquired flashing red lights and would not function. I was able to fix their problem using the bdc-com updating tool that the jaguars use for firm ware. to do this:

1.install bdc com on your computer (you can find it on texas instruments sight somewhere)
2.install black jaguir firm ware (i assume your using black jags, if your not you have to make a can connection between the jags)
3.use a db9 to rj11(phone line) cable and connect your computer into the correct can port on the jag,
4.you need a terminator plug so either borrow one at regional s or solder a resistor between the green and red wires on on some phone line then put that into an rj11 crimp
4.5.plug this into your jaguir
5.go to bdc com and see if in the upper right hand corner you get an error called gate fault.
6.if you do have a gate fault reset the jaguar to factory default
7.install black jag 101.bin on your jag
8.it should be unbricked. and the red light should go away
9.if you get the error "cannot access the boot loader" you have to use the reset button to manually factory reset the jag. then use black jag 101.bin on the jag.

Im not 100% certain how the gate fault error happens, i was not there to see this team break their stuff. But by messing with the jaguars firmware through a can to computer serial port hookup i was able to make it work for them again.

or you could just switch to victors, easier solution :yikes:

-note if you don't have the gate fault error im not sure if the firmware reset will help you.

slijin

25-02-2012, 14:04

Im not sure why your getting this error but if it makes the jags not work on other systems this might help you to get them running again.

A fried jaguar, which from the sounds of it was their problem, can't be fixed by magical firmware, no matter how much we want it to :(

dsirovica

25-02-2012, 14:04

We have abandoned Jags in favor of Victors two days before bag-day!
Apparently this is a yearly tradition on our team :o

We also started with 6 wheels, 2 CIMs on CIMple boxes and had friction issues on carpet. Covering wheels with duct tape worked but not cool, so we eventually lost the midddle wheels. The Jags kept cutting out, the Victors don't.

Jags have 2 MOSFETs per H-Bridge link, Victors have 3, and I don't think Victors have a cuttout like the Jags.

I agree with prior comments that this is NOT the way to solve this problem as Jags (one assumes are designed corrctly...) are cutting out for safety reason. As a result we can "fry an egg on the CIMs"! and we can barely make it through a match on one battery.

Turning from standstill is the biggest current drain - 90A per CIM!
Moving first helps a lot.

I suspect that 2 CIMs is simply too weak for a 120lb bot. Gearing down would be the best solution for us, however its bagged...

Joe Johnson

25-02-2012, 15:41

Joe Johnson

25-02-2012, 16:10

As a suggestion, 1 CIM per side without a shifter and with anything approaching grippy wheels is probably going to be a stretch to keep from over working the CIM or the Jaguar (or Victor) or (most likely if you fix the other problems) the 40A Breaker.

I suggest you buy two CIM-Sim from AndyMark or a CIMULATOR from Banebots and use one of the excellent 550 motors that are legal (one of the many FP motors or Banebot 550 motor... -- in general the more power the better) and buy another two Jaguar or (better yet, given my GAH!!! in the message above) two Victors.

If you install this on your CIMPleBox in parallel with your CIM you will have more power to turn but more importantly in your case, you will have two current paths -- and since loses are an I^2 R problem, halving your current can effectively quarter your electrical heat dissipation.

And, as long as you can wire up the speed controllers & press the gears on at the competition , everything is COTS so it doesn't count on the 30lbs allowance (of course you still have to make your 120lbs limit but one battle at a time...)

Wishing us both luck...

Joe J.

Cal578

25-02-2012, 16:57

...you will have two current paths -- and since loses are an I^2 R problem, halving your current can effectively quarter your electrical heat dissipation.
Formula is correct, application is almost correct.
The total current didn't get halved, it just got split into two paths. So, if everything else is the same, the power dissipated per path is a quarter of the original, but you have twice as many paths, so the total power dissipated (lost) is half the original (which is still a good thing).

To put it another way, putting another identical load in parallel with the first means your R is cut in half, which directly says that the power is cut in half.

Also, I just said "if everything else is the same", but if you're changing motors and/or gearing, then everything isn't the same. If new motors or gearing gives you a better match of motor to load, then that will be where you see the biggest improvement, and heat caused by losses becomes a smaller issue.

Joe Johnson

25-02-2012, 17:07

Formula is correct, application is almost correct.
The total current didn't get halved, it just got split into two paths. So, if everything else is the same, the power dissipated per path is a quarter of the original, but you have twice as many paths, so the total power dissipated (lost) is half the original (which is still a good thing).

To put it another way, putting another identical load in parallel with the first means your R is cut in half, which directly says that the power is cut in half.

Also, I just said "if everything else is the same", but if you're changing motors and/or gearing, then everything isn't the same. If new motors or gearing gives you a better match of motor to load, then that will be where you see the biggest improvement, and heat caused by losses becomes a smaller issue.

You are right, I was sloppy. But here is the thing. It is heat that ultimately kills the electronics. If you halve the current per leg, then that leg is going to see much less than half (~1/4 to first order) of the heat it would have otherwise seen.

So from a stress your electronics pov, it is a better than halving. That was my point, which I think is still valid.

Joe J.

Cal578

25-02-2012, 17:20

It is heat that ultimately kills the electronics. If you halve the current per leg, then that leg is going to see much less than half (~1/4 to first order) of the heat it would have otherwise seen.

So from a stress your electronics pov, it is a better than halving. That was my point, which I think is still valid.
I agree, you are right on that point.

enginerd

25-02-2012, 17:58

Alex Chambers

25-02-2012, 17:59

A fried jaguar, which from the sounds of it was their problem, can't be fixed by magical firmware, no matter how much we want it to :(
He described red flashing lights, which suggest to me they may not be fried, usually when a jag is fried it does not have any led at all or the led will display correctly. however as i stated it may not be a gate fault its just that his description mirrored the problem i mentioned.

Daniel_LaFleur

25-02-2012, 18:32

GAHHH!!!!

Jaguars are 4 years old now and they are still so fragile?

We are having fits with the Jaguars. I have been attributing them to some CAN related collateral damage but after reading this thread, I am starting to think that Jaguars are just not safe to use. Seriously.

I do not want my speed controllers "protecting" me by shutting themselves off. If they can't take the heat get the heck out of the FRC kitchen!

This is killing us.

I will have some choice words for FIRST Engineering after the season but man oh man has FIRST a lot of 'spainin' to do...

Joe J.

Dr Joe,

The Jags aren't as fragile as some put them out to be. Here in FIRST we tend to ABUSE speed controllers rather than use them.

That being said, there are a few areas where the Jags need to be made better:
1> CAN control -- The Can-bus and its related connectors tend to be ... touchy. A better positive lock and more robust pin setup would help things immensly.

2> Failure reporting -- The Jag has plenty of processing power. It needs to report exactly what the failure is, not just a flashing LED, so that our control system may deal with said failure.

3> For some reason the Jag seems to be a swarf magnet. Possibly adding a filter to the air intakes would help.

4> Protection from reverse power and reversed input/output. At least create connections that are physically different so that you cannot reverse input and outout wires ... and somehow protext from reversed input power (I havent looked at the schematic to determine an easy one here).

All this being said ... with proper care and feeding ... Jags are a good speed controller and they offer many benifits that the Victors do not.

Matt Krass

25-02-2012, 21:25

Dr Joe,

The Jags aren't as fragile as some put them out to be. Here in FIRST we tend to ABUSE speed controllers rather than use them.

That being said, there are a few areas where the Jags need to be made better:
1> CAN control -- The Can-bus and its related connectors tend to be ... touchy. A better positive lock and more robust pin setup would help things immensly.

2> Failure reporting -- The Jag has plenty of processing power. It needs to report exactly what the failure is, not just a flashing LED, so that our control system may deal with said failure.

3> For some reason the Jag seems to be a swarf magnet. Possibly adding a filter to the air intakes would help.

4> Protection from reverse power and reversed input/output. At least create connections that are physically different so that you cannot reverse input and outout wires ... and somehow protext from reversed input power (I havent looked at the schematic to determine an easy one here).

All this being said ... with proper care and feeding ... Jags are a good speed controller and they offer many benifits that the Victors do not.

As I stated earlier, I tend to agree that the Jaguars are not well suited to our uses. I find their over-current protection to be overly touchy, but not so touchy that I would dismiss repeated shutdowns without at least analyzing the performance of the system.

In general I don't like my electronics 'helping me' unless I specifically ask them to, including a fixed, sensitive over-current shutdown. As a feature I think it's excellent, but it should be configurable, or at least something that can be enabled or disabled by jumper/CAN.

In my (bad) experience, the Jaguars are no more swarf loving than Victors, and I mean that in that our Victors tend to blow up from swarf (I'm really amused by that word) as often as our Jags. In general I think teams might just be getting worse about swarfing (seriously, it's fun to say) around the controllers.

I would like to see a variety of improvements to the CAN system, including better failure reporting, and an internal software switchable terminator, or even just a jumper we could put in place on the Jag(s) at the end of the line to terminate it. I actually don't have much a problem with the existing physical interface, other than that I seem to have a terrible track record with crimping.

Reverse power protection is a pet project of many people, even I'm toying with it, it's really difficult problem given the currents and voltage we're dealing with here.

Bottom line, the Jags have potential, and we do use them primarily for drive systems (because of the internal encoder support -- which I'm on the fence about) but that is all, I find they are not as robust as Victors, and I find they are not sufficiently polished... yet, but they're rapidly getting there. I think a lot of their 'great features' are as of yet under developed and are more novelty than useful tool.

Also, swarf. Swarfing swarf. (Really, try to say it out loud with a straight face)

Matt

enginerd

25-02-2012, 21:41

Levansic

26-02-2012, 01:22

I don't understand all of the negative feelings about the Jaguars, vs. the Victors. The Jaguars are very adequate for a properly designed electromechanical system. If the jaguars are too "weak", then you're doing it wrong.

Seriously, we often loose sight of the forest from the trees. It is a natural tendency to grasp absolute numbers and attempt to achieve superlative performance. Because of this, many robots in FRC tend to be way under geared, chasing mythical top speeds that our calculations say we should hit. The results are sluggish robots that heat up their immediate surroundings and depleting batteries, motors, and motor controllers at an astounding rate.

Acceleration, not speed is what improves the drive performance. The field is not big enough for a bogged down robot to ever hit top speed. Double or tripple your gear ratio, and the power draw drops significantly. At the same time, your robot will get significantly faster and it will be far more responsive.

In the past, I have seen ~50% increases in gear ratio actually increase a good robot's top speed by ~30%, while improving battery life. Last year, we increased our gear ratio by 120%, and went from constant brown-outs and slow movement to a moderately fast robot that was quite maneuverable. We had other glitches, but the jaguars were not the problem.

dsirovica

26-02-2012, 10:45

Great discussion - to sum it up:

1. Jags may be overprotective of the system causing most FIRST teams to opt for Victors (though probably for the wrong reasons) - solution: get TI to allow a mode of "reckless" on the Jags to account for short bursts of activity in the "danger zone" like a 2.5 minute competition.

2. Gearing down seems to be the most recommended solution.

A related Q: we found that when a Jag stalls at full power it will cut out and also crash the cRio - have others had that experience?

Dean

slijin

26-02-2012, 11:13

I don't understand all of the negative feelings about the Jaguars, vs. the Victors. The Jaguars are very adequate for a properly designed electromechanical system. If the jaguars are too "weak", then you're doing it wrong.

A properly designed electromechanical system, yes, but let's face it - how many of us really get a chance to properly design and iron out every kink of our robot? The fact that designs need to iterated and constantly improved forces us to abuse our robots and consequently crash the Jaguars.

That being said, there are numerous reasons - somewhat attributable to poor design - that Jaguars are considered less robust than Victors. Their 40A overcurrent protection, for instance, may be a nice safety feature, but it's a frequent source of frustration for teams who find that their application may occasionally necessitate current spikes above 40A. Quality control on the physical RJ11 and RJ12 jacks has also been documented to be subpar. CAN issues - both on the electrical and software sides - have been linked to fundamental limitations (http://www.chiefdelphi.com/forums/showpost.php?p=1036569&postcount=11) of and problems with the involved hardware that aren't made explicit to users.

Long story short, it isn't just poor design that generated the "Victors for reliability, Jaguars for features" mantra.

A related Q: we found that when a Jag stalls at full power it will cut out and also crash the cRio - have others had that experience?

That's extraordinarily unlikely. If anything, the Jaguar's built in overcurrent protection should be preventing such a crash. The 24V power supply can handle voltage dips to 4.5V. If your battery voltage is low enough for one 40A draw to sink it below that level, then you need a new battery.

dsirovica

26-02-2012, 12:06

That's extraordinarily unlikely. If anything, the Jaguar's built in overcurrent protection should be preventing such a crash. The 24V power supply can handle voltage dips to 4.5V. If your battery voltage is low enough for one 40A draw to sink it below that level, then you need a new battery.

Sorry I don't know how to add a link to a post , but there are test results posted under
CD>technical>programming>Voltage vs. PercentVbus

In there you will see that the Jags do not cut out at 40A precicely - I believe it is a thermal mechanism. We were getting 100A+ spikes and 80A+ for many seconds before cut out. You will also see a very minimalistic settup and the cRIO crashes consistently -see CIM Test #6 & 7

In the same thread a contributor who appears to be from NI says the 8 slot cRIO (which ours is) needs 19V to work. We did not test that.

So far no one else has responded that they too had cRIO crashes when CIMs stall, so it may be something with our PDB it is an old war scarred PDB so will do more tests and report back when we recover from the post bagging depression :)

slijin

26-02-2012, 13:00

Sorry I don't know how to add a link to a post , but there are test results posted under
CD>technical>programming>Voltage vs. PercentVbusI've been following this thread, actually; I just haven't been reading very thoroughly as I've had work to do. To link to a post, just right-click the post #, which is at the top right corner of a post.

In there you will see that the Jags do not cut out at 40A precicely - I believe it is a thermal mechanism. We were getting 100A+ spikes and 80A+ for many seconds before cut out. You will also see a very minimalistic settup and the cRIO crashes consistently -see CIM Test #6 & 7 To my knowledge, this cutout is done by the firmware, not by a thermal mechanism. The Jaguar (http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf) actually monitors the current. It is, however, designed to handle above 40A (http://www.ti.com/lit/ug/spmu064c/spmu064c.pdf) for a few seconds; speculating on the reason for the "many seconds" is beyond me.

In the same thread a contributor who appears to be from NI says the 8 slot cRIO (which ours is) needs 19V to work. We did not test that.

So far no one else has responded that they too had cRIO crashes when CIMs stall, so it may be something with our PDB it is an old war scarred PDB so will do more tests and report back when we recover from the post bagging depression :)

Both the 2011 and 2012 PDBs are designed to output 24V down to a 4.5V input; I'm not aware of specs for the 2009 or 2010 PDB.

We managed to reboot our cRIO once, but we managed to push our robot to cause a current spike that forced our voltage to around 4V, so I'm not surprised that it happened.

enginerd

26-02-2012, 13:52

dsirovica

26-02-2012, 14:25

Correct he Jag 40A limit is implemented in Firmware:
http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf

Its a 1mOhm 4W resistor via an opAmp into the ADC3 on the Jag processor.

Do we have source code for the Jag firmware ? If so we could relax the constraints they have :cool:

Though this might violate FIRST rules?

Also in the same document you'll see that the Jag has 4 empy slots for 4 more MOSFETS which would make it like a Victor - looks like a Jag IS a Victor with 25% missing MOSFETs and a procesor.

Does anyone have a similarly detailed spec sheet on Victors to conclude a definitive comparison of the two?

There is charm in pursuing everything to its atomic structure - did someone already say that ?

Dean

Ether

26-02-2012, 15:21

Do we have source code for the Jag firmware ?

The source code is freely available on the TI site. It's like an Easter Egg hunt to find it though.

If so we could relax the constraints they have :cool:

Not permitted.

looks like a Jag IS a Victor with 25% missing MOSFETs

I doubt the Jag and Vic are using the same FETs.

Does anyone have a similarly detailed spec sheet on Victors to conclude a definitive comparison of the two?

This question has been asked repeatedly here on CD. The answer always comes back no. Too bad, it would be very interesting to see.

slijin

26-02-2012, 15:37

This question has been asked repeatedly here on CD. The answer always comes back no. Too bad, it would be very interesting to see.

I actually have a couple of dead 884s in the lab that I was going to open to see if I could identify points of failure. If possible (and if I remember), I'll ID the MOSFETs in there.

Ether

26-02-2012, 15:47

I actually have a couple of dead 884s in the lab that I was going to open to see if I could identify points of failure. If possible (and if I remember), I'll ID the MOSFETs in there.

I think Al S. has already posted the Vic FET PN somewhere. I was talking about a complete schematic (such as is available for the Jag) so the discussions could be better informed when we are comparing the Jag and Vic.

nitneylion452

26-02-2012, 16:57

We use Jags for everything. Sure, we've burned a couple out, but that was namely due to carelessness in drilling and sending swarf (gotta agree, it is really fun to say) all over the swarfing place.

As for the Jaguar's over-current protection, it is a software feature. It is designed to pump out 40A happily as long as you'd like it to (so long as you have it properly ventilated) and is designed to cut out after 2 seconds of 60A. For more information, you can see the Jaguar FAQ (http://www.ti.com/lit/an/spma033a/spma033a.pdf).

dsirovica

26-02-2012, 17:10

A full schematic would be ideal. But the FET PN would go a long way as that is a major component. If you look at the Jag's power path, it has a 1mOhm resistor and two legs of the Hbridge in series with the motor.

The Jag FET spec says:
MOSFET N-CH, TO-220 40V/60V 80A

However it lists 3 FET PNs
IRFB3206PBF: 60V 120A 2.4/3 mOhm (typ/max)
FDP038AN06A0: 60V 80A 3.8 mOhm
FDP050AN06A0: 60V 80A 5 mOhm

We then have an effective series resistance of between 3.4 and 6 mOhm between the battery and the motor, and a max I of between 160 and 240A (I guess no worries on max I).

The real limitation will come from power dissipation on the worst case 5mOhm FETs.
Eg: for 40A, each FET carries 20A.
P=I^2*R =2W
Thermal resistance from Junction to Ambient (no fans open space)= 62 C/W
Ambient T=25C
Therefore operating T= 149 C
The max Junction T is 175 C.

At 50A, Operating T = 219 C --- sizzzle!:eek:

The fan will help, but the math for that is below my age level. And clearly we've seen much higher current levels through Jags and they've survived.
(maybe Jags rarely use the 3rd PN?)

at 50A 1st PN 2.4mOhms: Op T = 118 C --- What a difference!

In the case of adding a third FET in parallel (like the Victor has), and keeping with the same FETs:
The current per FET is reduced by 33%, and the power dissipation by 56%.

This shows that Victors can handle far greater max power than Jags - unless they have very inferior FETs...

dsirovica

26-02-2012, 17:23

Thanks Joe,

From the Jag FAQ:
"... 40 A of continuous current to a heavily loaded motor. However, it is capable of providing much higher currents, but for shorter periods of time. Jaguar provides 60 A for up to two seconds and provides 100 A for approximately 0.2 s. "

that precisely matches the results we saw.

Ether

26-02-2012, 17:35

Black Jag

FDP8441 FET 40V 80A 2.7 mOhm each x2 in parallel

60amps thru Jag = 30amps thru each 2.7 mOhm FET = 30^2*2.7e-3 = 2.4 watts per FET

Gdeaver

26-02-2012, 19:19

Don't forget switching losses from the fet turning on and off. The fet is in the linear region during each cycle for a small period of time. Fets do not turn of instantly. Also, the black jags are switching both h legs on and off constantly.
The Victors are low side switchers. Black jag fets always see some current. Jags do not have diodes or TVS devices to protect the intrinsic diode of the fet from inductive kick back when they turn off. The decision to remove 4 fets from the jag and not re-space them may have messed with the cooling. I like the linearity of the jags and the robustness and size of the victors. Our speed controllers do not have on die temperature protection and no heat sinking for a thermal reservoir. We don't have the perfect controller but our robots keep on competing well. May be some day we will have the perfect controller until then take take your pick they will work most of the time.

Ether

26-02-2012, 20:15

Don't forget switching losses from the fet turning on and off. The fet is in the linear region during each cycle for a small period of time. Fets do not turn of instantly.

Yes. What would be your quantitative estimate of the overall effect (watts averaged over 67μs) of this switching (one rise and one fall every 67μs) for the FDP8441 when the current is 30 amps?

Also, the black jags are switching both h legs on and off constantly. Black jag fets always see some current. Jags do not have diodes or TVS devices to protect the intrinsic diode of the fet from inductive kick back when they turn off.

According to this post (http://www.chiefdelphi.com/forums/showpost.php?p=992030&postcount=54), for any given PWM command, in one leg of the H bridge the low-side FET pair is ON, and the high-side FET pair is OFF. In the other leg of the H bridge, the high and low FET pairs are alternately ON and OFF. Protection from inductive current is provided by shorting the motor through the low-side FETs during the OFF portion of the PWM cycle.

The Victors are low side switchers.

Not saying you're wrong, but what's your source for this info?

dsirovica

26-02-2012, 21:23

Ether, I assume you got the PN FDP8441 from an actual Jag as it is not one of the PNs in their spec sheet?

In any case it is very similar to the best performing one on their list.

Ahm, dating myself here, MOSFETs were not in my undergrad EE curriculum, hence my icon is the much loved 2N3055 :)

Just looking at the datasheet for FDP8441 and the Jag Spec:

1. the FDP8441 max switching times are 77ns ON, 147ns OFF that is about 0.3% of the PWM cycle. So how much power can be relesed in such a short time into an inductive load? Further, the Watage and Temp calcs earlier assumed a 100% PWM duty cycle, anything less will double the FETs over which to dissipate the energy. Worst case would be 99.9% PWM duty cycle. I agree some additional wattage should be added but it may be unecessary?

2. What are all the data about Joules and Coulombs, I would love oto hear a scientific explanation on switching energy, anyone?

3. The Jag datasheet has a writup on how the MOSFET is used to sink motor current thus reducing power dissipation compared to a diode based solution. Maybe Victors don't do that so that would be a -ve for the Vic in this debate.

Mark McLeod

26-02-2012, 21:35

The Victor FETs used are IRL3103 (International Rectifier) or an equivalent like FDB6035AL (Fairchild Semiconductor. Depends on the year of manufacture, and I haven't looked that closely in a couple of years, so they might well be different now.

Ether

26-02-2012, 22:06

Ether, I assume you got the PN FDP8441 from an actual Jag

I got it from the schematic in the RDK-BDC24 Rev B Hardware Design Package. The schematic shows a pair of FDP8441's for each of high+, high-, low+, and low- in the H bridge. Perhaps the FETs have changed since then.

the FDP8441 max switching times are 77ns ON, 147ns OFF that is about 0.3% of the PWM cycle.

The turn-on rise time is 24ns and the turn-off fall time is 17.9 ns. Which would be the correct numbers to use for this analysis?

The Jag datasheet has a writup on how the MOSFET is used to sink motor current thus reducing power dissipation compared to a diode based solution.

That's the alternating ON/OFF of the hi and lo side FET pairs mentioned in my previous post. If the source for that information is correct, then during the OFF portion of the PWM cycle, the motor is shorted through the low-side FETs, providing a low-resistance path for the inductive current in the motor to continue flowing (and producing torque). I assume that if the jumper is in the "coast" position, this behavior is modified for low duty cycles.

Maybe Victors don't do that so that would be a -ve for the Vic in this debate.

I've heard the Vics do not do this, and here's my speculation why they do not: the PWM period of the Vics is so long that even for relatively high duty cycles (say 50%), the motor inductive current would decay before the end of the OFF portion of the cycle, and, for higher motor speeds the motor back EMF would take over and start shoving current in the other direction, effectively reversing the torque. This would reduce the average torque output of the motor. Anyone care to comment?

dsirovica

26-02-2012, 22:52

The Victor FETs used are IRL3103 (International Rectifier) or an equivalent like FDB6035AL

OK Houston we have a problem.

The IRL3103 has 16mOhms, and FDB6035AL 12.5mOhms.
For a 40A motor curent through a 3-FET Vic, this is 2.8W and 2.2W respectively and an operating temp of 201 and 163 C.

Compare that to a two FET FDP8441 Jag: 1.08W and 92 C.

According to this the Jag has superior power.

Reality says different...

Could it be that the Vics are simply driven red hot and we may be operating in out-of spec areas - we do see a lot of failed Vics?

Also my temp calcs assume no fan so that may increase power dissipation significantly - anyone care to analyse forced air vs ambient power dissipation for these geometries?

Now back to the switching power dissipation:

1. anything less than 100% duty cycle increases the number of FETS dissipating power. At 50% cycle we double the dissipation power.

3. I am worried by the "Single Pulse Avalanche Energy (Note 1) 947 mJ"
of the FDP8441. If that means you turn 1Joule into heat on every swichover - we are trullly fried!

So we need help with (1) forced air power dissipation, and (2) switching energy loss in FETs.

I think we stumbled on a structural problem with FIRST: the kids are too young to know this level of detail, and the mentors are too old to know about this new MOSFET stuff, and object oriented programming - for me that meant you have a chair and desk object and a punch-card object ? :o :o :o :]

slijin

26-02-2012, 23:14

I got it from the schematic in the RDK-BDC24 Rev B Hardware Design Package. The schematic shows a pair of FDP8441's for each of high+, high-, low+, and low- in the H bridge.

I thought Dean would've picked up on this (no offense!), so I didn't want to steal his thunder, but the current version (http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf) is Rev C, and lists the following MOSFETs for the H bridge:

International Rectifier IRFB3206PBF
Fairchild FDP038AN06A0
Fairchild FDP050AN06A0

The BOM specs them all to be MOSFET N-CH, TO-220 40V/60V 80A.

Ether

27-02-2012, 09:20

I got it from the schematic in the RDK-BDC24 Rev B Hardware Design Package. The schematic shows a pair of FDP8441's for each of high+, high-, low+, and low- in the H bridge. Perhaps the FETs have changed since then.

I re-downloaded the Kit CD for RDK-BDC24* from the TI site before I posted the above. It still had the RevB schematic in it.

TI could make this information easier to find on their website. I didn't think to download a User's Manual to find detailed technical information like a schematic.

* from the TI website, quote:

Description

This board-specific kit CD contains:

Complete documentation, including Quickstart and User's Manual
Complete source code and schematics
StellarisWare® software including peripheral driver library and example source code

Al Skierkiewicz

27-02-2012, 09:47

Dean,
So lurkers are not confused, the power per device is not a max power spec on the FET but how much power is generated within the device during constant current due to the internal resistance. Please see that the ON resistance of the IRL3103 goes down as the Gate to source voltage goes up. The 12mohm is the more accurate figure. The fan in the Victor seems adequate, it is closely spaced with the devices and the airflow is constantly pushing air away from the tabs of the FETs. Everyone should keep in mind that although each leg has devices in parallel, there are two legs in series with the motor during operation. This series resistance also serves to limit that max current available to the motor. Under normal conditions, the devices do not achieve the indicated temperatures in either controller. If they did we would have had numerous reports of thermal issues over the years.

techhelpbb

27-02-2012, 10:32

There is a bit of a catch 22 with the higher on-state resistance.

These robots are being driven by humans.
Human sees robot go too slow...tells robot to go faster.

Higher on-state resistance means that robot spends more time operating closer to 100% duty cycle (not at 100% duty cycle obviously, but more time with the MOSFETs on) than in a situation with lower on-state resistance.
The more time you spend on, the more surges from the motor you dissipate through the MOSFET's junctions instead of the body diodes (never mind the normal currents).

EricVanWyk

27-02-2012, 15:22

The IRL3103 has 16mOhms, and FDB6035AL 12.5mOhms.
For a 40A motor curent through a 3-FET Vic, this is 2.8W and 2.2W respectively and an operating temp of 201 and 163 C.

Compare that to a two FET FDP8441 Jag: 1.08W and 92 C.

According to this the Jag has superior power.

Reality says different...

These figures don't necessarily say that the Jaguar has superior power, it says that it has superior efficiency at DC. For a given motor current, Jaguars will produce less heat.

At 60 Amps, I predict that a Victor will produce ~7W heat per FET (21W per leg), and a Jaguar will produce ~3.5W per FET (7W per leg). At 40 Amps, I predict 2.5W/ FET for Victor and 1.5 for Jaguar. I included conduction and gate loss for both, but only included switching loss for the Jaguar as I was unable to predict it for the Victor.

I think my numbers should be within 30-50% of reality. I'll wait about 15 minutes after posting to see how thoroughly Ether tears my math apart :)

Also my temp calcs assume no fan so that may increase power dissipation significantly - anyone care to analyse forced air vs ambient power dissipation for these geometries?

Unfortunately, I left all my thermal simulators behind when I switched hats to software.

You can sort of eye-ball it by looking at heat sink spec sheets and backing out a bit. For example, the cheapest TO220 heat sink I can find is Aavid's 5073 (http://www.aavidthermalloy.com/sites/default/files/products/boardlevel/aavidstandard_rohs.pdf#page=38). If I'm reading things correctly, it is 25C/W in stagnant and 4C/W in a tornado. If I use the back of a napkin and wave my hands enough, I might be able to convince myself that we could hope for a 3x to 6x case to ambient impedence reduction from the fans... ish?

At the very least, it is enough of a reduction that we aren't above the 175C junction temperature limit.

I ran my calculations assuming 10C/W case to ambient because it is a round number within the range. I don't know what the real number is, I'd bet higher.

3. I am worried by the "Single Pulse Avalanche Energy (Note 1) 947 mJ"
of the FDP8441. If that means you turn 1Joule into heat on every swichover - we are trullly fried!

If that was the case, each Jaguar would be generating 15kilowatts of heat from this mechanism alone. This is several times the entire robots power budget. This is a rating for how much energy it can handle when the voltage across the FET exceeds the breakdown threshold.

This paper does a much better job of describing avalanche events than I can: http://www.irf.com/technical-info/appnotes/an-1005.pdf

I've heard the Vics do not do this, and here's my speculation why they do not: the PWM period of the Vics is so long that even for relatively high duty cycles (say 50%), the motor inductive current would decay before the end of the OFF portion of the cycle, and, for higher motor speeds the motor back EMF would take over and start shoving current in the other direction, effectively reversing the torque. This would reduce the average torque output of the motor. Anyone care to comment?

I agree with your statement. The Vic chop rate is well below the electrical time constants of the motors.

Dean,
Please see that the ON resistance of the IRL3103 goes down as the Gate to source voltage goes up. The 12mohm is the more accurate figure.

Yep. The 16mOhm number is for driving the gate with 4.5V. When the junction is at 25C, 12mOhm is the expected figure. When the junction is warm, expect 30-50% more resistance per figure 4. For a Victor pushing 60 Amps, I predicted that the junction temperature would be ~104C and ~17mOhms per FET. This was with a very optimistic thermal impedence estimate, so the actual resistance is likely to be higher.

Also, swarf. Swarfing swarf. (Really, try to say it out loud with a straight face)

Matt

Swarf!

dsirovica

27-02-2012, 15:57

Trying to answer the few Qs above and then report on my crash-course on MOSFET-101:

Yes the Power (W) we address in this thread refers to the thermal power dissipated/generated inside a MOSFET as a result of driving a CIM motor. The absolute max power rating of these MOSFETs is much higher but that assumes ideal heat-sinks which we do not have in Jags nor Vics.

The most significant parameter we focussed on so far was the R DS(ON) resistance of a fully conducting MOSFET. Hence it is critical to now the Part Numer (PN) of the MOSFET in your speed controller. As usual, different generations (even batches) of Jags & Vics will have different PNs. One hopes the variations in the critical parameters will not be great - but life is not always such.

For the Jags we have discovered 4 PNs so far:
IRFB3206PBF 3mOhm
FDP038AN06A0 3.8mOhm
FDP050AN06A0 5mOhm
FDP8441 2.7mOhm

and for the Victors:
IRL3103 16mOhm
FDB6035AL 12.5mOhm

The R DS(ON) in mOhms is listed above as that is the critical parameter (so far). Since Power dissipation is P=I^2*R, one can see how important this number is.

As was pointed out, I may have mixed the use of RDS max and RDS typ, but as you will see shortly we have a bigger problem.

MOSFET-101:

A pretty good paper is "A Power MOSFET Tutorial":
http://www.microsemi.com/en/sites/default/files/micnotes/APT0403.pdf

Using this and a few other (harder to read links below) papers on the web, I will summarise the pertinent points here:
http://www.eetimes.com/design/power-management-design/4218373/Calculating-power-loss-in-switching-MOSFETs
http://www.btipnow.com/library/white_papers/MOSFET%20Power%20Losses%20Calculation%20Using%20th e%20Data-Sheet%20Parameters.pdf

Power losses (Pl) in any component operating in the switch-mode can be divided in three groups:
a) Conduction losses (Pc)
b) Switching losses (Psw)
c) Blocking (leakage) losses (Pb), normally being neglected as this is in the micro-Amp region.

a) Conduction Losses:
This is primarily our friend R DS(ON).
This value is highly affected by 2 other parameters:
(1) The Gate Voltage - the higher the gate the lower RDS. Luckily for us the Jag uses a MOSFET driver chip and one assumes drives it at near Battery voltage - I am guessing that the Victor has a similar driver. At 10V on the Gate we are down to the spec RDS.
(2) The temperature. The higher the junction empo the higher RDS. All MSOFET datasheets have that graph. The Y axis is typically a Normalized RDS, and X-axis T (C). One can see that from ambient 25C (spec RDS) to 150C RDS can almost double! So keep it cool:yikes:

b) Switching Losses:
This is where it gets really messy...
There's 2 losses, Capacitance, and Crossover:
(b1) Capacitance loss:
This is due to charging and discharging the "capacitors" within a MOSFET. However with our 12V battery and 15KHz this is down to 1-2mW and also I think this energy is dissipated outside of the MOSFET so we can ignore it as far as heating goes.
(b2) Crossover loss:
This is more interesting. Essentially it is due to the "slow" swichover from full-ON to full-OFF and back. See Figures 14 and 15 in the first link above, and look at the bottom shaded "switching energy" graph. Now for some reason the MOSFETS we are using do not have a spec for this Eon, Eoff data. It is also apparent from the same graph that the Turn-On Rise Time, and Turn-Off Fall Time is not the time during which most of the energy is released! I find it hard to believe that the industry hasn't yet standardised on the representation of this parameter? We must have mentors that work at MOSFET manufacturing companies - how do we get to them?...

Anyhow, I did some back of the envelop and assuming similar energy curves as APT50M75B2LL for our Jags E switching is 0.5W. For the Vics that would be negligible due to the slower PWM cycle.

Therefore, if we use the following:
Jag MOSFET FDP8441
Vic MOSFET FDB6035AL
Motor Current 40A and 60A
Operating at red-hot 150 C junction T
PWM duty cycle 99%

we get the following power dissipation at the ON MOSFETs (40/60A):
Jag = 1.8/3.4W
Vic = 3.2/7.3W

And (no fan) T operating:
Jag = 137/238C
Vic = 227/479C

Jag wins hands down!

Something doesn't compute - as the Vics should all be burnt !
1. The fan probbaly has a very strong heat dissipation effect.
2. The Jags could be driven much harder than the Vics if only we dissabled the software cut-out mechanism ::ouch::
3. Lets open up a few Jags & Vics and confirm the PNs (maybe we can replace the PNs on the Vics with the better ones - they are only a couple of $ each -just kidding - its probably against the rules!

Here is the math for those who want to tinker:
P= I^2*R
R= RDStyp * the Temp factor

T=P*RJA+Tamb

Where:
I is the current in the ON MOSFET in Amps. Motor Current divided by 2 for Jag and by 3 for Victor.

R is from the MOSFET datasheet. Use RDS(ON) typical. Temp factor from the datasheet table.
Jag FDP8441 RDStyp=2.1mOhm, Temp factor (150C)=1.55
Vic FDB6035AL RDStyp=11mOhm, T factor (150C)=1.65

RJA is the Thermal Resistance Junction to Ambient from the datasheet:
Jag FDP8441 RJA=62C/W
Vic FDB6035AL RJA=62.5C/W

Tamb is 25C

dsirovica

27-02-2012, 17:04

Eric wrote his post while I was researching mine:
Hey Eric how did you guess the W numbers so accurately ?

Yup its all in the fan! If it gets us 10C/W then the even the VICs at 60A come down to <100C! We should do a temp measurment on those.

The 15KW avalanche energy was a total red herring. Just ignore it we are not avalanching in FIRST :)

Basicaly to place a simplified answer to the title of this thread:

The VICs win in terms of being able to get more power out of them.
The Jags are overly protective and their power could be increased significantly without harming the system - especially for a FIRST 2.5 minute competition event.

Dean

Mark McLeod

27-02-2012, 22:34

A current Vex Victor 884 uses an Infineon 2N03L13
Now I seem to remember that change being introduced circa 2007.

http://www.infineon.com/dgdl/SPP_B_42N03S2L-13_040604.pdf?folderId=db3a304412b407950112b4271a7 43b94&fileId=db3a304412b407950112b4271adf3b95

Had a travel meeting tonight and got a chance to check one I just purchased.

Al Skierkiewicz

28-02-2012, 08:29

Guys,
You are scaring me and half the population as well. While you are taking the approach of worst case analysis, the common use for these devices is much less than predicted. A good FRC design will generally not choose to run at ~60 amps (the max power power output of the CIM). While short bursts into this range are common, they are not continuous. At 60 amps, the CIM would be dissipating over 300 watts and we know that few teams are burning up their motors or their controllers. So I believe that most teams are running in the recommended normal operating area of 30 amps or less. At this current the temperature numbers seem more in line with experience in the field for both devices using fans.

dsirovica

28-02-2012, 10:40

Al: Thank You for bring us back to earth!

It is by no means necessary to be able to follow this debate in order to be a great FIRST participant.

One of the genius ideas behind FIRST is that it enables kids of different backgrounds and skills to actively participate by leveling the playing field. The design of the KOP, the game rules, strategies, community effort, etc. The body of knowledge behind the scenes and the way it is organized to serve a noble cause is just phenomenal.

As a new mentor, and one of the little cogs in the FIRST ecosystem, I was dismayed when one morning after another 1AM night of frantic redesign a few days before bag-day, the robot showed up with all its Jags replaced by Vics! The reasoning was – they kept cutting out, we always have problems with them, we've always switched back to Vics and we carry a bag of replacement Vics as they die!

Well needless to say, in the professional world, this is not a satisfactory assessment of the situation and resulting decision...

BTW, on a more humorous note, that same night when the kids where left home alone :-) our robot almost went for a midnight skinny dip – one wheel was over the edge of the pool! Maybe it was a Jag that prevented that fiasco!

I see the pursuit of this thread as a way to close one of a gazillion of open issues that many struggle with and forever debate on these fora. I believe that a little extra effort to push for a definitive understanding and resulting recommendation is going to save this community a huge effort. We must though ensure that the mechanism exists to capture, save, and make this knowledge readily available when next time someone asks Jag vs. Vic? Can you just imagine what the total effort spent on this is ? Our team has spent many person-days on this just this season. It has a huge spill-over effect too. Our mechanical design called for a JAG-based PID shooter control, so all that work is down the drain too!

Back to the topic for a moment:
Thanks Mark for the latest Vic PN 2N03L13
It is very similar to the other one I used in the math FDB6035AL
The parameter of interest is RDS the New PN is
10.3mOhms(25C), 15.5mOhms(150C) so just a little better – not too significant.

BTW: in my posted equation for the MOSFET Power dissipation I forgot to show the Pswitching contribution, so the formula should be
P= I^2*R + Pswitching which is 0.5W for our Jags and 0W for Vics

The numbers presented are still valid.

Al is also right – as others have said – we are investigating an area of operation that is near, and beyond the “red-zone”. Proper design would call for staying well clear of the edge of the normal operating zone (kids take note!). Jag designers know that, so they designed the cut-outs to ensure the system stays clear of that zone. We all know that once a system is deployed it will be pushed -accidentally, or on purpose, to its extreme. So the Jags just cut out, while the Vics burn!

It is like the 0-11 setting in the Spinal Tap amplifier :-) users want, and will always push to go to 11!
So I do think the Jag should allow for an “11” option and a disclaimer User Beware :-)

Seriously, IMHO, the Jag can relax its protection a bit and still be quite safe. Especcially I think there could be two modes (1) for regular long steady-state operation, and (2) for short bursty operation like a FIRST competition. Yes yes I can hear you say users of (1) will use the (2) setting to solve a mechanical design problem... c'est la vie!

Al Skierkiewicz

28-02-2012, 14:59

techhelpbb

28-02-2012, 18:11

Dean,
If I were to hazard a guess, I would think that the trip characteristics are more to protect the onboard power supplies over the FETs. At the currents and durations listed, I would guess that the voltage drop to the three terminal regulators is likely to cause them to drop out if the trip points were to be relaxed.

It's actually quite easy to brownout the Jaguars already with the sorts of systems common to this competition. As I have suggested elsewhere it's a shame that the Jaguars don't have a separate place to insert power for their logic (something common to older educational robot designs), a lower drop out regulator or more energy storage (larger capacitor, battery, etc).

Of course the bigger problem with the brownout as it is, is that if you're not in the default modes you have no non-volatile place to store things if you do brownout. If that changed perhaps it would be less an issue.

Joe Johnson

28-02-2012, 18:15

Can we all agree that the FIRST control system, while each change seemed to make sense at the time, had morphed into something that has cross over the line if sanity?

I am quite serious.

FIRST should really think things through from start to finish.

I know that it is unlikely that the CRIO is going anywhere soon, but that doesn't mean that we have to keep everything else.

If I were king, I think I'd look hard at a PDBoard that was 3-4" thick, essentially nothing but relays, FET and fins, hermetically sealed with a brain to do the switching, a big fat battery connection for current going in, a bunch of smaller (Non Wago please) connections where the current goes out to the motors.

I think it makes a ton of sense.

Joe J.

EricVanWyk

28-02-2012, 18:27

Can we all agree that the FIRST control system, while each change seemed to make sense at the time, had morphed into something that has cross over the line if sanity?

I am quite serious.

FIRST should really think things through from start to finish.

I know that it is unlikely that the CRIO is going anywhere soon, but that doesn't mean that we have to keep everything else.

If I were king, I think I'd look hard at a PDBoard that was 3-4" think, essentially nothing but relays, FET and fins, hermetically sealed with a brain to do the switching, a big fat battery connection for current going in, a bunch of smaller (Non Wago please) connections where the current goes out to the motors.

I think it makes a ton of sense.

Joe J.

Yes. A thousand times yes. Sometime over a beer I'll have to show you the (rejected) Power Interface. I don't know when I'll get the chance to resurrect it, but I swear it will happen one of these years.

techhelpbb

28-02-2012, 18:33

I don't know about major overhauls (there are already unforeseen consequences from that sort of thing in the past 14 years I've been involved in U.S. FIRST).

Plus, many teams have invested a small fortune in parts.

I am quite comfortable with the Victors, and I think that they have historically functioned quite well.

That being said, rolling everything into a single module to add to the cRIO carries with it the disadvantage that the students don't get to really glue it all together.

Additionally, this module idea with everything in it is...sort of the like the Jaguars with a single CAN bus...a single point of failure. I should hope that great care would be taken to insure parts would be available quickly if things go badly and the smoke comes out.

I think the Jaguars just need really 2 things:

1. A good comprehensive, easy to grasp, document set designed to help design with them within this environment.

2. A little design work so that the next revision better addresses a few of the things I often see vex people.

(On a side note I very much favor modular design. It leaves room for much innovation and it allows competition between part sources that...when supervised properly...helps keep the quality high and the price low.)

Al Skierkiewicz

28-02-2012, 19:25

Joe,
We really need to get together and talk. Are you up for a challenge? I have an assignment you might be interested in.
Al

Joe Johnson

28-02-2012, 20:10

Joe,
We really need to get together and talk. Are you up for a challenge? I have an assignment you might be interested in.
Al

Right now I am getting my team ready for BU in 22 days, but after that, yeah, maybe.

As to those who say teams have invested bucks in all the crazy quilt hardware that is required to make the current system function, FIRST can always grandfather that hot mess in for a few years. But seriously, this current system is far from free. It cost a lot of money (and labor not to mention blood, sweat, and tears) to wire up all these distributed devices.

And for what? Not much in my humble opinion.

Think about it. If FIRST wants to keep the router on the robot morphology, then this box could be ethernet device. Just like the Jaguars, they could force the device to prove it is running an approved version of firmware and then have that firmware shut everything off if an enable message that only FIRST approved software can generate (although rumor has it that folks have broken the Jaguar protocol -- in theory a reasonably secure system could be designed, we are not running military hardware here -- there is not a lot of benefit to someone being able to spoof the enable/disable signal on a FIRST robot).

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

techhelpbb

28-02-2012, 20:47

And for what? Not much in my humble opinion.

Things I think a student can learn from this system as it is designed:

1. How to wire robotics systems.
2. How to deal with modular systems (like those often found in automobiles, HVAC, industrial application) and their complexities.
3. Electronics (and frankly given I was a vocational technical student for electronics in high school I know this is very good thing to learn at the relevant age bracket). (I feel that this is a challenge that is not being well served however...the pathway to provide electronics education from this is not well defined.)

I am concerned about the idea of reducing the entire project to the sort of thing we find in the other age brackets with Lego NXT and Vex controllers. Not that these aren't admirable for handing you a system (and the limits of that system) in a simple box but because teams actually do manage to make this work. What I feel we as a group need to do is stop 'bleeding' and start working smarter. We need a process to vet vendors and fill the holes where they exist.

techhelpbb

28-02-2012, 21:41

Think about it. If FIRST wants to keep the router on the robot morphology, then this box could be ethernet device. Just like the Jaguars, they could force the device to prove it is running an approved version of firmware and then have that firmware shut everything off if an enable message that only FIRST approved software can generate (although rumor has it that folks have broken the Jaguar protocol -- in theory a reasonably secure system could be designed, we are not running military hardware here -- there is not a lot of benefit to someone being able to spoof the enable/disable signal on a FIRST robot).

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

Yeap, in effect I already have this.

I have a robot controller made from Parallax Propellers (several).
The Propeller produces a virtual serial port over the USB connection typical on the development board.
I have that connected to a dual band NetGear N WiFi router running a patched version of DD-WRT.
This NetGear box has a USB port for sharing printers, I snagged it to plug in the Propeller (handy that).

Therefore the WiFi box in this case is hardware provided by NetGear and software mostly provided by the DD-WRT community.

I chose the Parallax Propeller because of the 8 cogs and the many shared I/O lines. With this you don't need to task switch you can run 8 process with one in each cog at 20Mips (if you don't overclock). With a few of them (and they are cheap) you get dozens and dozens of I/O.

Reading encoders is not a problem when you have 20Mips to do whatever you feel like with (in BASIC, assembler or C). ;)
I can send code to it...and it doesn't take like 5 minutes to do either!

I get around the power issue the same way the cRIO basically does. The battery is pulled through a step-up regulator from whatever the battery voltage is to 24VDC (sort of like the cRIO) and then 3 step-down regulators provide 3.3VDC (for the Propellers), 5VDC for various I/O and 12VDC for relay coils (yes I have electromechanical relays on this...and they work dandy). The battery can cave well below 3VDC and this will not even blink. It's easy to get to 5V I/O using either level converters or 2N7000 MOSFETs.

Currently this frame is equipped with Jaguars and one speed control I built myself (my speed control does CAN as well thanks to some handy parts from Microchip).

techhelpbb

28-02-2012, 22:00

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

Now that I've explained what I've already built since last year, I'd like to point out that this may not be an arms race that is wise to start.

There are countless high performance items that could end up on robots. Parallex Propellers, GreenArray GA144s, Altera and Xilinx FPGA and that's not counting the likely laptops and embedded PCs that'll show up.

And yes...this probably would get crazy:
http://www.objectivej.com/hardware/propcluster/index.html
(Pull the red wire...the red wire!)

Someone's bound to show up with a laptop on the robot this year.

Matt Krass

28-02-2012, 22:10

There are countless high performance items that could end up on robots. Parallex Propellers, GreenArray GA144s, Altera and Xilinx FPGA and that's not counting the likely laptops and embedded PCs that'll show up.

And yes...this probably would get crazy:
http://www.objectivej.com/hardware/propcluster/index.html
(Pull the red wire...the red wire!)

Now this said, someone's bound to show up with a laptop on the robot this year.

There's really not much preventing that this year, there is a variety of ways to mount an embedded PC on the robot and have it use the cRio as a pretty pricey, FIRST controlled I/O expander, using an Ethernet link or something similar. In which case it behaves like the system you and Joe described.

Personally, I'd really like to see FIRST open up the control system with a design competition. Let teams design and submit control system ideas, designed around what teams want/need and their resources and let the FIRST community and it's thousands of brilliant minds weigh in. We already have a competition to design robots in the winter and spring, why not control system summer and fall?

While the guys at NI and TI have done an admirable job, I do agree the current system is an amalgam of several good ideas with bits hacked together to work in a manner that's.... well let's go with frustrating. But those guys were small in numbers, and probably did not have all that much to work with. I sincerely think the mentors and students of FIRST stand a good chance of coming up with an effective, workable solution to our somewhat oddball use case. Even if only because of the sheer amounts of brainpower we have at our disposal.

But this isn't the thread for that idea. I'm not sure that thread exists (yet).

Back on-topic:
It'd be really interesting to see a qualitative side-by-side test of a new Jag vs a new Victor with both buried in temperature sensors and voltage and current probes. Perhaps even some rig with an active matching network between a Jag and a Victor running in complement. Say the Jag running 'forward' supplying a steady current in the 30A range, and the Victor running 'reverse' sinking the same current, with some kind of active FET arrangement to regulate current flow between the two. This would ensure that they're both being exposed to very close to if not the exact same conditions across all tests. You could do these tests at a variety of power levels and compare.

Eric, Joe, Al, what do you guys think of that idea?

Al Skierkiewicz

02-03-2012, 12:38

Matt Krass

02-03-2012, 13:50

Matt,
I like the idea of a competition. I would like to assemble a list of what such a system must have prior to any competition. I am an official old guy and I try to help rookies whenever and wherever I can. In the past we had some pretty easy to use hardware that an inexperienced mentor and students could take out of the box, look at a simple block wiring diagram, start adding wires and have a robot driving in an hour or two. Granted, it didn't have the computing power some of the new software geeks wanted and it had some other limitations that were solved by the manufacturers. However, it had a few good qualities as well. It was small, lightweight, easy to use, easy to control and had sufficient tally lights to tell you what was happening.

According to our students, I'm also an official old guy (I don't get it) but I think I have a few good years left ;) I have had extensive experience with the IFI controllers and the current cRio controllers and I wholeheartedly agree. The new system is vastly over-complicated for our use case. As far as the new computing power... Eh. In terms of raw power, yes it's more capable, but we burn up a good ton of that with CAN, TCP/IP, the VxWorks RTOS, etc. At the end of the day, I don't think it really works out to be much of a difference. I feel we have the same challenge in getting the thing working with sensors and vision tracking that we had in 2006, only now everything is more expensive, and requires more configuration. And because we're so far from the bare metal, I feel a lot of the impact is lost. Students no longer have to understand why a pot or encoder works, just how to type "Encoder" in to their programming language and have magic numbers show up. What kind of problem solving do you learn from being handed premade solutions?

(Yes, FIRST is not about teaching engineering it's about Inspiration, but what is so inspiring about learning to expect someone to do your job for you?)

So here is my list...
1. Out of the box it has to work for rookies running default software or at least is easily loaded with default software without any other programming in less than one half hour.
2. Can control Jags or Victors, Spikes or whatever control devices someone wants to include to drive motors and such.
3. Can run down to 4 volts input.
4. Has imbedded wireless controls of some sort.
5. Has sufficient software power to process sensors, cameras, etc. and development includes C++, Java, Labview or any other development software in general use.
6. Has at least a serial port and an ethernet port, several would be ideal.
7. Has sufficient I/O for at least 8 or 16 PWM, relay, solenoid, digital and analog ports and/or can be simply expanded for the I/O needed (i.e. plugin modules).
8. I/O is easily accomplished without sophisticated tooling.
9. Is a mature product or product line available to all teams, domestic and foreign.
10. Always of interest is something that is low cost, or is manufactured by a company interested in donating sufficient quantities to help our teams keep costs low.

Please keep in mind that team expansion is increasing by leaps and bounds and could easily reach 8-10,000 in this decade. Please feel free to add to this list your requirements.

I think the architecture of the IFI system is pretty close to this. It was much more self contained. I think a similar structure with more horsepower (but not so much more that we need all the support systems the cRio has) and a simpler development environment would be ideal. Especially if we did away with the silly licensing issues we always seem to have every January.

On top of that, a big requirement from me is that it be more robust, and i don't mean in terms of environmental conditions. I mean high school students plugging it in backwards and short circuiting it and getting swarf (still laughing) in it. I think the blue bits are quite well designed, based on the fact that my students haven't managed to kill them yet :cool:.

I would be remiss if I failed to thank our current suppliers for their continued support to this organization, especially NI, IFI, TI and all the other suppliers who make this competition fun for our students and challenging for our mentors.

While I am somewhat critical of the system we have now, I'd like to make it clear I don't think it's a failure or oversight of anyone working on the system. Engineering constraints are a bear, and I think everyone involved has done a great job, I just think they may have been starting at a serious disadvantage with the wrong platform for the job. So I also thank the suppliers and engineers for their help.

Matt

techhelpbb

02-03-2012, 14:47

I think the architecture of the IFI system is pretty close to this. It was much more self contained. I think a similar structure with more horsepower (but not so much more that we need all the support systems the cRio has) and a simpler development environment would be ideal. Especially if we did away with the silly licensing issues we always seem to have every January.

While I am somewhat critical of the system we have now, I'd like to make it clear I don't think it's a failure or oversight of anyone working on the system. Engineering constraints are a bear, and I think everyone involved has done a great job, I just think they may have been starting at a serious disadvantage with the wrong platform for the job. So I also thank the suppliers and engineers for their help.

Matt

The one shortcoming of the IFI system I've seen recently was the documentation for the cables to connect them to the radios.

Surely that would not seem to me to be a design issue, but rather a process issue in that once it was designed and it worked the information should have been distributed.

This only became more critical after FIRST shifted to the cRIO because teams like ours have a rather sizable pile of these and of course the cables have been lost.

I was able to figure this out because I fix electronics all the time, but a search for this pinout didn't seem to produce results. I certainly don't blame anyone for that sort of thing. It's just one of those things that after you figure it out, you really should have a place to distribute that information.

(Unless someone has this information somewhere, I'm willing to provide what I discovered provided it doesn't violate IFI's intellectual property and anyone wants it.)

I to would like to clarify that I have nothing against the work of the vendors involved. I work with them beyond FIRST all the time, I just would like to find a pathway to clear communications and a good fitting solution.

Dave Flowerday

02-03-2012, 15:22

So here is my list...
1. Out of the box it has to work for rookies running default software or at least is easily loaded with default software without any other programming in less than one half hour.
2. Can control Jags or Victors, Spikes or whatever control devices someone wants to include to drive motors and such.
3. Can run down to 4 volts input.
4. Has imbedded wireless controls of some sort.
5. Has sufficient software power to process sensors, cameras, etc. and development includes C++, Java, Labview or any other development software in general use.
6. Has at least a serial port and an ethernet port, several would be ideal.
7. Has sufficient I/O for at least 8 or 16 PWM, relay, solenoid, digital and analog ports and/or can be simply expanded for the I/O needed (i.e. plugin modules).
8. I/O is easily accomplished without sophisticated tooling.
9. Is a mature product or product line available to all teams, domestic and foreign.
10. Always of interest is something that is low cost, or is manufactured by a company interested in donating sufficient quantities to help our teams keep costs low.

*cough*
http://www.vexrobotics.com/products/vexpro/217-2180.html
*cough*

It has everything on your list except CAN and Ethernet. However, it DOES have a USB host port (which should also be on your list), so adding Ethernet is trivial (or better yet, use USB devices like cameras instead of Ethernet - they're cheaper). I'm sure there's some USB->CAN device out there, or someone could make one. Best of all, it's made by a manufacturer with a proven track record.

Solutions to this issue clearly exist (or are at least a lot closer than what FIRST has now). I don't think this is a technological problem, however.

techhelpbb

02-03-2012, 17:35

It has everything on your list except CAN and Ethernet. However, it DOES have a USB host port (which should also be on your list), so adding Ethernet is trivial (or better yet, use USB devices like cameras instead of Ethernet - they're cheaper).

Firstly I like this product and what it was based off of, so this is not intended to downplay what it is.

I don't know if for the purposes of FRC you're not just better off buying a cheap general x86 embedded board or laptop to put on the robot for that price. It would serve a lot of purposes, offer Ethernet, WiFi, and even most cheap netbooks have 2 USB root hubs for at least 2 webcams. A cheap multi-tt capable hub might allow more. The hard drives can easily be replaced (or come as is) with solid state drives, or you can always use flash USB drives, compact flash or camera memory in a suitable reader with BIOS boot support (or some combination with an appropriate boot loader).

Plus if you use something like the driver's station you might be able to work a bulk discount.

Additionally, when the control system is no longer the current model, this leaves you with...a PC.

Obviously this VEX product offers the integration with PWM, digital to analog conversion, and other aspects, but it's not hard to add most of that to an x86 computer, or even supplement the computer with a powerful microcontroller or FPGA via USB, USB-CAN, USB-RS232, USB-422/485 or ethernet.

This is very broad and while I love this communication, I wonder if we've manage to hijack this topic. Perhaps we can start a new topic and link it?

The last I read in this topic the idea was to produce measurements to compare the Jaguar and the Victors and the interest in that effort.

Al Skierkiewicz

02-03-2012, 18:43

Guys,
Before we start making recommendations I would still like to get a list of must haves and would like to haves if possible. I like the USB ports idea.

Matt Krass

02-03-2012, 19:03

The last I read in this topic the idea was to produce measurements to compare the Jaguar and the Victors and the interest in that effort.

I'm a fan of this idea, I didn't mean to accidentally kick off a whole new topic in here :) to that end I've started a new thread here (http://www.chiefdelphi.com/forums/showthread.php?t=104114) to continue this discussion.

Back on to Victors and Jaguars, I'd really like the opinion of some of the veteran EEs around here on my idea for a test rig I mentioned earlier. Essentially, I'd be alternating between a Jaguar sourcing current to a Victor and the opposite, using something with a sufficiently intelligent brain to control both and perhaps some kind of active load between them. While doing this, we can monitor all of their vitals (mostly temperature of the FETs in question) and we can do some pretty terrible things to them and see how they handle it.

A bank of FETs with beefy heat sinks combined with some smoothing LC networks off each speed controller would make a nice load I think, how about it?

Matt

techhelpbb

02-03-2012, 19:05

Guys,
Before we start making recommendations I would still like to get a list of must haves and would like to haves if possible. I like the USB ports idea.

One issue with USB is the cabling. It's fine for webcams and the like, but a lot of peripherals have molded connectors and that's not always easy to work with if you have to snake framework in your robot (sure you can cut off the connectors but that can cause issues). However, a controller that has USB host capability in plural opens the door to a lot of cool cheap COTS hardware (http://www.thinkgeek.com/geektoys/warfare/8a0f/ stuff like that.).

Lower part of this moved to new topic...http://www.chiefdelphi.com/forums/showthread.php?t=104114
Thanks

techhelpbb

02-03-2012, 19:21

Moved to new topic...http://www.chiefdelphi.com/forums/showthread.php?t=104114
Thanks.

Matt Krass

02-03-2012, 19:34

EDIT: I'm removing the comments here in the interest of thread purity, I've reposted them in the new thread I made for control system design thoughts, linked below

I'm loving these suggestions, but as you pointed out, we're really derailing this thread, so I'm going to ask that you guys divert to the thread I made for this here (http://www.chiefdelphi.com/forums/showthread.php?t=104114).

Thanks,
Matt

techhelpbb

02-03-2012, 19:52

I'm a fan of this idea, I didn't mean to accidentally kick off a whole new topic in here :) to that end I've started a new thread here (http://www.chiefdelphi.com/forums/showthread.php?t=104114) to continue this discussion.

Back on to Victors and Jaguars, I'd really like the opinion of some of the veteran EEs around here on my idea for a test rig I mentioned earlier. Essentially, I'd be alternating between a Jaguar sourcing current to a Victor and the opposite, using something with a sufficiently intelligent brain to control both and perhaps some kind of active load between them. While doing this, we can monitor all of their vitals (mostly temperature of the FETs in question) and we can do some pretty terrible things to them and see how they handle it.

A bank of FETs with beefy heat sinks combined with some smoothing LC networks off each speed controller would make a nice load I think, how about it?

Matt

A consistent load would be essential or it might poison your experiment.

I'm not sure what you mean by the Jaguar sourcing current to a Victor however.

Would it not be easier to just have a consistent load and a consistent source of power as static factors in your test?

I should think you'll need to monitor the load and source of power quite carefully and if that monitor is digital it'll have to have pretty high bandwidth for transients.

Matt Krass

02-03-2012, 20:35

A consistent load would be essential or it might poison your experiment.

I'm not sure what you mean by the Jaguar sourcing current to a Victor however.

Would it not be easier to just have a consistent load and a consistent source of power as static factors in your test?

I should think you'll need to monitor the load and source of power quite carefully and if that monitor is digital it'll have to have pretty high bandwidth for transients.

The configuration I had in mind was a Jaguar running forward, bringing it's load node up high to +12V, and the Victor running reverse, bringing it's load node down to 0V, so that current flows:

Jaguar M+ (at 12V) ---> Dynamic Load ---> Victor M+ (at 0V)
and
Jaguar M- (at 0V) <--- Dynamic Load <--- Victor M-(at 12V)

In this configuration, both active legs see a stable constant current load, so both get a complete work out. Halfway through the test I'd flip the directions and work the other legs just as hard. Since the loss in the FETs are resistive and related to current, we'd only need constant current, not constant power, so the declining battery voltage is not necessarily a problem.

If my description still doesn't make sense, I can draw it up really quick and see if that makes more sense. The idea is the load current passes through both legs of both bridges while the FETs are monitored.

The problem with a consistent load is that resistors heat up and change resistance, and other components have similar temperature dependence. However I have not (yet) done the math to see if this variance is enough to warrant the trouble of a dynamic load. Perhaps it isn't necessary, though I agree I'd not want to use a digital controller to regulate the load, merely to program an analog feedback loop to regulate it due to bandwidth concerns.

Matt

techhelpbb

02-03-2012, 20:42

The configuration I had in mind was a Jaguar running forward, bringing it's load node up high to +12V, and the Victor running reverse, bringing it's load node down to 0V, so that current flows:

In this configuration, both active legs see a stable constant current load, so both get a complete work out. Halfway through the test I'd flip the directions and work the other legs just as hard. Since the loss in the FETs are resistive and related to current, we'd only need constant current, not constant power, so the declining battery voltage is not necessarily a problem.

If my description still doesn't make sense, I can draw it up really quick and see if that makes more sense. The idea is the load current passes through both legs of both bridges while the FETs are monitored.

The problem with a consistent load is that resistors heat up and change resistance, and other components have similar temperature dependence. However I have not (yet) done the math to see if this variance is enough to warrant the trouble of a dynamic load. Perhaps it isn't necessary, though I agree I'd not want to use a digital controller to regulate the load, merely to program an analog feedback loop to regulate it due to bandwidth concerns.

Matt

I see what you're thinking but be careful, I'm thinking the Jaguars don't entirely work like that in the off part of the cycle.

Matt Krass

02-03-2012, 20:49

I see what you're thinking but be careful, I'm thinking the Jaguars don't entirely work like that in the off part of the cycle.

Simple solution, run both at full blast and let the dynamic load regulate the current (this actually makes sense for a bunch of different simplicity reasons, but it also deprives us of the results of switching loss/downtime for the FETs which will very likely affect the results)

I'm curious, what effect are you expecting to see during the off cycle part of things that would be a problem?

Also, this idea is really not fully fleshed out, it's still on the back of the napkin, so I'm expecting people to poke lots of holes in it, so they can hopefully be filled in

Matt

techhelpbb

02-03-2012, 21:24

I'm curious, what effect are you expecting to see during the off cycle part of things that would be a problem?

Synchronous rectification on the black Jaguars.
http://www.ti.com/lit/an/spma033a/spma033a.pdf

I like this description, so with respect to ST Microelectronics I quote it here from this datasheet http://www.datasheetcatalog.org/datasheet/stmicroelectronics/7048.pdf page 8.
(This is a courtesy to the audience that may not understand what this is. I'm quoting this because I like the description in this datasheet. The datasheet does not pertain to any part in our systems.)

A motor is an inductive load. When driven in PWM mode, motor current is switched on and off at the
25kHz frequency. When the MOS is switched off, current can not instantaneously drop to zero, a so-called
”free-wheel” current arises in the same direction than the power current. A path for this current must be
provided, otherwise high voltage could arise and destroy the component. The classical way to handle this
situation is to connect a diode in an anti-parallel configuration regarding to the MOS, so that current can
continue to flow through this diode, and finally vanishes by the means of ohmic dissipation, mainly in the
diode due to its 0.8V direct voltage. For high currents, dissipation can be an important issue (eg: 10A x
0.8V makes 8 W!). Furthermore, high speed diodes have to be used, and are expensive.

A more efficient way to handle this problem is to use the high side MOS as a synchronous rectifier. In this
mode, the upper MOS is switched ON when the lower one is switched OFF, and carries the free-wheel
current with much lower ohmic dissipation. Advantages are : one expensive component less (the fast
power diode), and more reliability due to the lower dissipation level.

However, we have to take care not to drive the two MOS simultaneously. To avoid transient problems
when the MOSare switched, a deadtime is inserted between the opening of one MOS, and the closing of
the other one. In the TD340 device, the deadtime is fixed to about 2.5 microseconds. This value is the time
between the commands of the gate drivers, not the deadtime between the actual MOS states because of
the rising and falling times of the gate voltages (due to capacitance), and the MOS characteristics. The
actual value of the deadtime for a typical configuration is about 1.5 microseconds.

Please keep in mind that people often use the body diodes of these MOSFETs as the anti-parallel high speed Schottky. So these diodes get hot and that heats up the MOSFET transistor as a whole. That's the advantage of this feature in the black Jaguars as apposed to the previous generation.

Course it might be trouble if other things are injecting power in the bridge. Usually motors can't return more power than you put into them unless something turns them faster than the speed control (it may be more voltage than you put into them with less current, but in the sense of power it must be less than you put in unless something adds mechanical energy and makes the motor into a generator). I may be misunderstanding but from your original proposal it would seem that a black Jaguar might dissipate the energy in the load from the Victor....that would be quite a bit more energy than I think would be normal even for a motor that had extra mechanical energy being added to it's rotation (at least in the scope of what we can build with these parts).

Matt Krass

02-03-2012, 21:34

Synchronous rectification on the black Jaguars.

Please keep in mind that people often use the body diodes of these MOSFETs as the anti-parallel high speed Schottky. So these diodes get hot and that heats up the MOSFET transistor as a whole.

I was aware of the Jaguars synchronous behavior, but I thought it wouldn't be a problem because, if I'm looking at my sketch correctly, when the off cycle occurs the terminals of the Jaguar reverse polarity and match those of the Victor, at roughly (but never at exactly the same time) that the Victors low side FETs disengage. Perhaps it just oversight on my part, but I don't believe this would be a problem, since the terminals would either be open at the Victor, or connected to the same node as the corresponding Jaguar terminals, not flowing any current?

It's entirely possible I'm missing something right in front of my face, am I? :)

Also, since the Victors don't have synchronous rectification (to the best of my knowledge) and only switch the low side (again, to the best of my knowledge) I suppose the body diode on the bottom FETs get's a work out when the Victor is in it's off cycle and the Jaguar isn't, I assume this is where your concern about heating comes in?

Matt

Ether

02-03-2012, 22:02

Synchronous rectification on the black Jaguars.
...
I like this description,

I like this one (http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf) better, see Pages 18* & 19.

The Black Jags use the low side to provide the path for the inductive current during the OFF portion of the PWM cycle.

* there's a typo in the third paragraph in the section at the bottom of Page 18 titled "Switching Scheme". It should read "and Q4 on the low-side"

techhelpbb

02-03-2012, 22:07

I like this one (http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf) better, see Pages 18* & 19.

The Black Jags use the low side to provide the path for the inductive current during the OFF portion of the PWM cycle.

* there's a typo in the third paragraph in the section at the bottom of Page 18 titled "Switching Scheme". It should read "and Q4 on the low-side"

Good catch, thanks. Hmm, I wonder why they didn't do this the other way or flip it over for the higher duty cycle.
Wouldn't it make it even more efficient?

Per this:
"During PWM_OFF, assuming a 40 A load, Q2 losses are approximately 40W without synchronous
rectification. This drops to just 4W if synchronous rectification is used (Rds-on = 2.5 mΩ).
Synchronous rectification significantly improves drive-stage efficiency, particularly at lower duty
cycles (50% and less) when the PWM_OFF time is longer that the PWM_ON time."

Besides I would think the Jaguars would tend to spend more time at a higher duty cycle in our application.

techhelpbb

02-03-2012, 22:13

I was aware of the Jaguars synchronous behavior, but I thought it wouldn't be a problem because, if I'm looking at my sketch correctly...
Matt

Sorry, I'm not following. It might just be me, but I think I should take you up on your offer to provide that illustration of what you propose.

Ether

02-03-2012, 22:16

Hmm, I wonder why they didn't do this the other way or flip it over for the higher duty cycle.
Wouldn't it make it even more efficient?

Why would that make it even more efficient? All the FETs in the bridge are the same.

techhelpbb

02-03-2012, 22:38

Why would that make it even more efficient? All the FETs in the bridge are the same.

"During the PWM_ON period, Q1 on the high-side and Q2 on the low-side provide a path that increases current in the motor."

Shouldn't this be Q4, not Q2 (for one thing it's a contradiction to the diagram on the next page, and for another it wouldn't make sense as it is written versus how an H-bridge functions).

On what I just proposed I'm not sure but it would seem to me that dumping that energy into the low side of the bridge runs the risk to mess with the lower side reference 'ground'. Since the high side would have to be driven higher than the supply to saturate the MOSFET anyway, because the high side is N-Channel MOSFETs, wouldn't it less risky to dump that energy to the side that is already able to exceed the supply rail which might shift down anyway? I mean might not a shift in the lower reference cause the lower MOSFET to not be entirely saturated?

Hmmm, might not matter, guess it would depend on just how not ideal the lower reference 'ground' really is.

Ether

02-03-2012, 22:50

"During the PWM_ON period, Q1 on the high-side and Q2 on the low-side provide a path that increases current in the motor."

Shouldn't this be Q4, not Q2

Uh, yeah:

* there's a typo in the third paragraph in the section at the bottom of Page 18 titled "Switching Scheme". It should read "and Q4 on the low-side"

Matt Krass

02-03-2012, 23:07

Sorry, I'm not following. It might just be me, but I think I should take you up on your offer to provide that illustration of what you propose.

Excuse the crudity of this model, it's not to scale...

So, with the Jaguar in forward, and the Victor in reverse, in the on period for both, Node A will be at +12V, and Node C will be at 0V, flowing some current through dynamic load R1, and B would be at 0V and D at +12V, so current is flowing the opposite way through R2.

When the PWM goes off, let's assume the Victor stays on longer for the sake of argument, so C stays at 0V, D stays at +12V, and A also goes to 0V, and B goes to +12V... No current flows.

Ok, so what obvious thing did I miss? :)

techhelpbb

03-03-2012, 00:51

Uh, yeah:

Sorry, didn't notice that before when you wrote it. Thanks.

techhelpbb

03-03-2012, 00:54

Excuse the crudity of this model, it's not to scale...

So, with the Jaguar in forward, and the Victor in reverse, in the on period for both, Node A will be at +12V, and Node C will be at 0V, flowing some current through dynamic load R1, and B would be at 0V and D at +12V, so current is flowing the opposite way through R2.

When the PWM goes off, let's assume the Victor stays on longer for the sake of argument, so C stays at 0V, D stays at +12V, and A also goes to 0V, and B goes to +12V... No current flows.

Ok, so what obvious thing did I miss? :)

Now I see what you intended. Thanks.

Well for one thing there's the current sensing resistor in the Jaguar which is not in your diagram.
If you look at Ether's link of the manual it's in the schematic on page 23 pretty much dead center.

Matt Krass

03-03-2012, 01:00

Now I see what you intended. Thanks.

Well for one thing there's the current sensing resistor in the Jaguar which is not in your diagram.

I left out things like that and the control electronics for brevity, I was more referring to any obvious reasons that my scheme wouldn't work that I overlooked.

I think in this scheme, the sychronous behaviour of the Jaguar is not a problem. I also suspect some inductive and capacitive components on each ESC might be wise to smooth out the output so the load is more stable, especially given the (wildly) different switching frequencies involved.

EDIT: I'm just curious, could you describe what you thought I meant?

Matt

techhelpbb

03-03-2012, 01:18

Matt Krass

03-03-2012, 01:35

Okay, but the current sensing resistor in this case is limiting the current to the Victor as well. So you can't fully test the Victor's power range like that. Plus I don't think they have the same on-state resistance so the Jaguar might drop more voltage. Might not matter for what you plan.

I thought you planned on powering the same load with both speed controls, because you started off in the singular tense in the first proposition post. Clearly, however, you intend to use 2 loads and that's just fine.

The only thing is that the terrible things (as you put it before) involved here are not really inductive or motors?

I sort of ask because while I understand the heat concerns entirely, obviously there are quite a few other concerns in the comparison.

I fully expect they don't have the same on-resistance, that is why I want to go for constant current loads, so we can measure the performance of the FETs, getting an empirical comparison of the 3 FET leg of the Victor vs the 2 FET leg of the Jag. If we measure the voltage drop and temperature across the FETs on each side we can see which heats up faster, which loses more power to heat, etc.

As long as the power source doesn't run out of volts and the load can compensate, the current sense resistor should be canceled out by the adaptive load.

Matt

techhelpbb

03-03-2012, 11:15

(Back to what I was communicating with Ether about...)

I wrote:

On what I just proposed I'm not sure but it would seem to me that dumping that energy into the low side of the bridge runs the risk to mess with the lower side reference 'ground'. Since the high side would have to be driven higher than the supply to saturate the MOSFET anyway, because the high side is N-Channel MOSFETs, wouldn't it less risky to dump that energy to the side that is already able to exceed the supply rail which might shift down anyway? I mean might not a shift in the lower reference cause the lower MOSFET to not be entirely saturated?

Hmmm, might not matter, guess it would depend on just how not ideal the lower reference 'ground' really is.

The high side current limit resistor is probably why they used the low side as the current going back up through the high side would heat that resistor. So that resistor makes the high side's path back to the battery positive less than ideal as long as it exists (even if the transistor remained fully saturated while it did that).

Trade off I guess.

Ether

03-03-2012, 11:37

The high side current limit resistor is probably why they used the low side as the current going back up through the high side would heat that resistor. So that resistor makes the high side's path back to the battery positive less than ideal as long as it exists (even if the transistor remained fully saturated while it did that).

Trade off I guess.

The current sense resistor would not be in the path of the inductive current if the high side were used for shunting

The inductive current would flow in a loop: through the motor, through one pair of high-side FETs, then through the other pair of high-side FETs back to the motor.

dsirovica

03-03-2012, 20:50

Guys,

if you use a Jag to drive a Victor you will get into a pickle. The two PWMs are free running and will produce all sorts of beating products. It will be very confusing to figure out whats going on. May be fun though!

What we have is really pretty simple. For the Jag we have decent documentation for the Vic we don't so we are guessing a bit for the Vics.

For the Jag, during the HIGH PWM cycle, we have:
Battery,
Current sensing Resistor,
Two Mosfets in parallel,
the Load (Motor),
Two more Mosfets in parallel.

During the LOW PWM cycle, we have:
the Motor that is shorted via two sets (in series) of two parallel Mosfets.

The Mosfets are driven hard-ON and hard-OFF at 15KHz by the driver chip.

All the other components are “in the noise” - that is they matter very little and can be ignored for our purposes here. It is fair to assume that these other components are engineered properly, and are not limiting the behavior we observe.

Based on the previous discussion in this thread it seems that the practical limitation we have is thermal overheat due to high amperage. The Jags have software that cuts out way before meltdown (perhaps too soon, sacrificing maximum power), while the Victors can burn in the field but as a result deliver more power than the Jags. This gives Victors an apparent power advantage, and it seems many teams prefer them for that. The sad thing is that the Jags actually could deliver more power than the Vics if allowed.

I've been playing with a simulator – it is really cool and answers many of the questions we posed here. I would advise all to play with this, see:
http://www.linear.com/designtools/software/
It is very noble for LT to provide this for free – its a great educational and practical tool.

LT doesn't have the exact MOSFETS we have, but you can get close, or design your own.
I entered a simplified model with just one Mosfet. I don't have a Motor model, so I assumed a Stalled-Motor equivalent of an Inductor and series Resistor. A good approximation for a CIM is L=200uH, R-80mOhms (please advise if you have better data on this). See:
http://i.imgur.com/1cNXB.png

You can see the Current through the Inductor is ~60A. In reality we were getting 55A see real picture of a PWM driven Jag and stalled CIM Search for the "Voltage vs. PercentVbus” thread for more motor pics:
http://imgur.com/0IjKf

To give more details on the simulation parameters if you want to play with it (it takes just minutes to do this):
V2 is 12VDC. R3 is the internal Battery resistance (ours measured about 20mOhms)
L1 is 200uH, and R2 is 80mOhms these numbers seem to match a stalled CIM based on some measurements we ran in the aforementioned thread. It would be great if someone has the SPICE models for FIRST motors!
I just used a Diode D1 for the flyback shunt. You can see this would dissipate 30W if the Jags didn't use the Mosfets for this! As the current through D1 is 60A during the LOW PWM.
V1 is the PWM:12V, Period=75us (for 15 Khz), I gave it a rise and fall time of 2.5us each. It runs for 200 cycles or 15ms.
R1 is an arbitrary value. You can see that the Mosfet's parasitic capacitance is spiked through this R and that is where the Capacitive loss is converted to heat – that stays in the Mosfet Driver chip – I will let you all run this to see the trace of the current through R1 – it is cool!
The Mosfet I picked is IRFH5004, this has an RDS of 2.2mOhms and I doubt this simulator takes heating into account so RDS probably stays at 2.2mOhms. In our reality we are heating these puppies driving RDS to about 150% of typical value.

The main things still missing are the forced-air cooling equations for the Jag&Vic (ie. What thermal C/W number should we use) and all the documentation that we don't have for the Vics.

And for the advanced student, here is the Fast Fourier Transform (FFT) of this PWM signal on V1 – it is mind boggling what LT Spice can do !!!
http://i.imgur.com/7Fjh2.png
You can see the main component at 15KHz, and the square wave's harmonics at 3X intervals.
This is much simpler and hugely more powerful than the Fortran punched card program I used for very primitive Fourier Analysis in my college days :-)

techhelpbb

03-03-2012, 23:14

The current sense resistor would not be in the path of the inductive current if the high side were used for shunting

The inductive current would flow in a loop: through the motor, through one pair of high-side FETs, then through the other pair of high-side FETs back to the motor.

This is very true, but I would think only after the delay when the other half of the high side turns on.

( I hate to put this below a post like the one directly above, dsirovica that was a very good post.)

Ether

03-03-2012, 23:26

This is very true, but I would think only after the delay when the other half of the high side turns on.

Are you talking about the 2 microsecond shoot-through delay? During that time, the intrinsic diode of the non-conducting high-side FET pair would complete the current loop. The inductive current doesn't flow through the sense resistor, because there is no path to ground.

techhelpbb

04-03-2012, 00:20

Are you talking about the 2 microsecond shoot-through delay? During that time, the intrinsic diode of the non-conducting high-side FET pair would complete the current loop. The inductive current doesn't flow through the sense resistor, because there is no path to ground.

Wouldn't the bias current of the INA193 reference ground to some extent?
Though it's certainly not going to see anything more than 20uA.

No you're right...while it might impart noise on the measurement it wouldn't produce any appreciable current flow in that resistor so it wouldn't heat it.

dsirovica

04-03-2012, 20:26

Techhelp & Ether, just to clarify and hopefully close on the “Dead Time” issue.

(BTW, you cannot use the high-side for the inductive current path as Q1's Intrinsic Diode is pointing the wrong way)

This is reasonable well explained in:
http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf
On Page 18 under “Motor Output Stage” and “Switching Scheme”, and shown in Figure 4-4
on Page 19.

From there I quote:
“The 2μs DEAD_TIME period starts with Q1 turning OFF. Current continues to flow through the
load, with the path being completed by the Q2 intrinsic diode and Q4. The voltage drop across Q2
is equal to a forward-biased diode.”

In Figure 4-4 they show 3 red-current paths happening in this sequence:
1. “PWM_ON” during the PWM-HIGH cycle
2. “Dead_TIME” -the inner red arrow on the low-side. When Q1 shuts off the current HAS to continue flowing through the inductor(Motor) – (for a convincing and memorable learning experience -see below). This current is pushed out of the inductor(Motor) into the already ON Q4, then via the bottom wire (just happens to be connected to ground though that is not relevant here), through Q2, and sucked back into the inductor(Motor). Now Q2 is OFF, so the current passes through the “intrinsic diode” of Q2 (shown on the right of Q2's gate). The power dissipated in this diode is what this discussion was all about, and is P=I*V. V is the voltage drop across this diode, lets say this is 0.8V. I is say 60A, so the Power dissipated is 48W. But the duration of this is set 2us(microseconds). Therefore the energy per event is E=P*t, so E=48W*2*10^(-6), or 96uJ. Now there are two of these events per PWM cycle (the documentation doesn't state the duration of dead-time for the ON transition, but one assumes (danger!!!) it is also 2us, and there are 15,000 PWM cycles/second, so the total Power for this mechanism is P=E*2*15000/s=2.88W, or 1.5W per Mosfet – This IS rather significant given our earlier numbers in:
http://www.chiefdelphi.com/forums/showpost.php?p=1135666&postcount=50
However – this 1.5W is produced in the non-driving low-side Mosfets. Now, these same Mosfets take the full inductor current in the next sequence:
3. “PWM_OFF” during the PWM-LOW cycle. This current is shown in the outer red arrow on the low-side. The Jag switches this Mosfet ON as it dissipates much less power than the intrinsic diode. So why not switch it on immediately after switching Q1 OFF. The reason is engineering safety margin of 2us to ensure both Mosfets are never ON at the same time. I am guessing that the designer chose 2us for good reasons, probably to allow for different PN of Mosfets etc. in the future so that the design need not be reexamined for each PN change.

This would suggest that the worst case power dissipation will be on the LOW-PWM cycle because then we have both the Mosfet ON conduction as well as this reverse diode power loss of 1.5W. Therefore a lower PWM duty cycle would yield a higher thermal dissipation. However, at low duty cycles we will not be able to attain high current as that is driven by the HIGH-PWM period. The following picture, with our simplified Mosfet driver, shows that at PWM duty cycle of 25% we only attain 30A on a stalled CIM – as compared to 60A for a 50% PWM duty cycle.
http://i.imgur.com/iO447.png

So lets try to find the worst case power dissipation – which will be our limiting factor for maximum power output.

From a prior post on this thread we concluded the following:
Jag FDP8441 RDStyp=2.1mOhm, Temp factor (150C)=1.55 => effective RDS=3.26mOhms
Power dissipated due to 15KHz switching = 0.5W
At current=60A with 99% duty cycle Pmosfet=3.4W
This is for each of the two high-side driving Mosfets.
So lets fix 60A into the motor, and a Junction Temp of sizzling 150C.

Now we know that the low-side Mosfet has an additional 1.5W due to the 2us Dead_Time. So we want a PWM duty cycle that uses the low-side more. Lets try 50%.

We then have the following power contributions to the low-side Mosfet:
P on_current= 50%*30A^2*3.26mOhms= 1.5W
P dead_time= 1.5W
P switching= 0.5W

Ptotal= 3.5W for each of the two low-side non-driving Mosfets
Ptotal=1.5W for each of the two low-side driving Mosfets (I am guessing these are full-ON all the time)
Ptotal= 2W for each of the two high-side driving Mosfets (this came down from 3.4W as we reduced the PWM cycle)
Ptotal= 0W for the non-driving high-side Mosfets

We might be able to dissipate a bit more power on the limiting Mosfets by going to a lower PWM cycle, but then we will start to see a lower max Amperage – so this late in the day – I am content to say the max power dissipation is 3.5W on the two non-driving low-side Mosfets – that is where I would stick a thermometer! Any offers for more than 3.5W ?

--------

So for the promised “memorable learning experience” above:

Lesson: an inductor always resists changes in the current.
Explanation from physics: A current in the coil builds a magnetic field inside the coil. Any changes in that magnetic field induce a current in the coil. Therefore once you “charge” a coil with magnetic energy, that energy will want to sustain the current in the coil. If the coil circuit is discontinued, then the voltage will rise until...

Take a 9V battery and any old transformer, such as one from a wall-wart. Connect the battery to the secondary windings – the low voltage side. Hold the two primary wires in one hand – make sure they touch your skin, but not each other. Then in a couple of seconds, disconnect the battery. DISCLAMER: never use anything bigger than a small 9V, or AA, AAA, battery. Never use any transformer bigger than what you can cup in one hand. Do not do this if you have any medical condition. Do not do this if you are in an environment where you can hurt yourself by falling or bumping into things due to a sudden jerk.

When I was a high-school freshman in a boarding school in England a couple of us played the following trick: during lunch we asked a dozen friends around the table to grab a fork in one hand and a knife in another and create a ring. We then proceeded to execute the experiment above with the dozen kids connected to the primary winding on a transformer. Knifes and forks went flying in the dining hall with screams to accompany the pandemonium. Lesson: be aware of unintended consequences :-)

Ether

06-03-2012, 10:16

(BTW, you cannot use the high-side for the inductive current path as Q1's Intrinsic Diode is pointing the wrong way)

Not true.

See attachment.

To use high-side for inductive current path, switch as follows:

For positive (forward) motor current:

Q1 Q2 Q3 Q4

on on PWM ON

on * Dead Time *current flows thru Q3 diode

on on PWM OFF

For negative (reverse) motor current:

Q1 Q2 Q3 Q4

on on PWM ON

* on Dead Time *current flows thru Q1 diode

on on PWM OFF

This is reasonable well explained in:
http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf
On Page 18 under “Motor Output Stage” and “Switching Scheme”, and shown in Figure 4-4 on Page 19.

Yes, we know. This was already mentioned in post#82
http://www.chiefdelphi.com/forums/showpost.php?p=1137840&postcount=82

dsirovica

06-03-2012, 11:04

Quite right Ether,

The H-Bridge is a mirror image, so you can do with one half what you can with the other.

Thnaks for pointing that out.
Dean

dsirovica

07-03-2012, 21:50

Just to add to this body of knowledge, for any of you still following this discussion:

Can anyone guess why the Jag designer chose to use the Low side of the H-bridge to close the inductive current loop vs. the top side?

Follow on Ether's thumbnail diagram LEFT (two posts up).

Using top loop to short the inductive current:
In the PWM-High cycle Q1 and Q4 are on.
When PWM=Low, we switch off Q4, and the voltage on the right motor terminal spikes to 12.6V. Then the Intrinsic Diode of Q3 starts to conduct and we are in the "Dead Time". After 2us, the Jag switches on Q4. The voltage needed on the the Gate needs to be 22V (12V Battery+10V VGS)

In the actual case of using the Low-side shunt we just need +10V on the Gate of Q2. (We still need +22V on the gate of Q1.)

So one might think it odd that we need 22V in a 12V battery powered circuit. Well the genius of this lies in the H-Bridge driver chip:
http://www.allegromicro.com/en/Products/Part_Numbers/4940/4940.pdf
This chip has an on-board power supply, and also a mechanism to “float” the driver stages of the High-side Mosfet drivers so they float on the corresponding Mosfet Source pin voltage whatever that is 0, or 12V. That way they can always drive the Gate at 10V above the Source. The Gate voltage to drive Q1 is also +22V.

The real issue however is that the H-Bridge driver's internal power supply mechanism uses Bootstrap Capacitors to ensure sufficient voltage to drive the high-side gates. The capacitor is recharges only when the Motor Terminal is at 0V. Therefore there needs to be periodic dips to 0V for each of the Motor terminals. The Jag document addresses this, in:
http://www.ti.com/lit/ug/spmu130c/spmu130c.pdf
“One restriction with the boot-strap capacitor method is that the capacitor voltage will decay to an unacceptable level unless a low-side MOSFET is periodically switched on. This state only occurs when the motor is running full-forward or full-reverse.”
This would occur also at any power level if the High-side were used for the inductor current shunting. The driver chip will sense this and temporarily switch off the top Mosfet, and switch on the bottom Mosfet to get the Motor terminal to 0V and recharge the bootstrap capacitor.

See the simulation below for the two mechanisms. The 3 traces are I(L) current through our stalled CIM (at 50% PWM), Blue V – Voltage on the left Motor Terminal, Red V – Voltage on the right Motor Terminal. You can see that when the High-side is used for the inductor current, the voltage on the left Motor Terminal never goes below 11.2V and would not keep recharging the left Bootstrap capacitor.
http://i.imgur.com/2pZ6X.png
(The simulation does not use the forced-ON of the Mosfet to prevent the Diode current from being the limiting thermal parameter.)

FYI, the 2us Dead_Time is defined by an external resistor on the H-Bridge driver chip (R34) and is used twice per PWM cycle, so our Power calcs earlier still hold.

I think this horse is truly dead :(