New Speed Controller Announced

[Al Skierkiewicz]

Originally Posted by MikeDubreuil

[*]The Jaguars run on 12V (from the literature). Can you assume they know the robots electrical system will be 12V in 2009 with some sort of 24V transformer for the cRio?[/list]

Mike,
The power distro has a 12 to 24 volt convertor built into it to run the CRIO.

[Greg McKaskle]

Originally Posted by Billfred

Perhaps someone can find this out: If we go wild on speed controllers for 2009, will we be able to enable these features in 2010 when it's the night before ship day and we need just that one extra speed controller?

The speed controller FW will upgradable via CAN. So any features currently disabled because of missing SW/FW are field fixable.

In response to another posted question. FPGA updates on the cRIO are done via a PC based tool, which is free.

[Adam Y.]

Originally Posted by EricVanWyk

Luminary is not getting into the motor control business. They are in the motion control controller business. The Jaguar is essentially a reference design that shows professional EEs how easy it is to create a strong motor control algorithm using their processors.

I agree. If you look at their demonstration boards the only motor application that is missing is a regular DC motor application which is generally the most trivial. I don't know if they plan on making money with the Jaguar. Some companies adopt a loss leader approach to these products while others tend to price their products to correspond to the cost of manufacturing.

As far as I know the current plan is to distribute them via Digikey, for any controllers needed on top of what's included in the kit

That is not good. Digikey tends to mark up the prices from the manufacturers prices. Not by that much but it is a little irritating to pay ten dollars more.

[dtengineering]

Originally Posted by Adam Y.

Digikey tends to mark up the prices from the manufacturers prices. Not by that much but it is a little irritating to pay ten dollars more.

I can't comment on Digikey's markup, but do want to point out that for Canadian customers Digikey ships from within Canada, meaning that each order saves about $35 in brokerage fees relative to companies that ship UPS from the states. (Yes, pretty much EVERY order of robot parts out of the USA goes through a brokerage firm, and you can end up paying a $35 brokerage fee on a $10 part.) They also bill in Canadian dollars, which makes some of the book-keeping a bit easier. Their delivery time is much faster for Canadian customers than USA-only suppliers, unless you feel like spending $50-$100 on international express shipments.

I would be delighted to see Digikey as part of the FIRST supply chain... so long as they keep these controllers in stock north of the border as well!

Jason

P.S. And a big "thank you" to Andy Mark for shipping from within Canada and eliminating brokerage fees.

[yodameister]

Not cool. Not cool at all!

Originally Posted by Greg Needel

Pictures are up.....OMG that thing is HUGE




HUUUUUUGGGGEEEE Rochester HUUUUUGGGGE (anyone from upstate NY will get that reference)

[Tom Line]

Being a controls guy who was converted from Mechanical, can someone explain what "CAN" is and why it is so beneficial?

[Kingofl337]

Intelitek Uses CAN on our industrial line of CNC products.

Short Version: CAN is basically a serial communication standard that allows devices to be daisy chained.

Controller -> Device -> Device -> Device -> Device -> Terminator

Long Version: http://en.wikipedia.org/wiki/Controller_Area_Network

[Kevin Sevcik]

CAN == Controller Area Network. It's a multicast serial network protocol and bus specification. In this case CAN 2.0A/B, which is a little more flexible and faster. The Jaguar flyer declares a 1Mbit/s rate, but doesn't bother us with piddling details like what application protocol they're planning on using.

In practical terms, it's a 3-6 wire bus that you'd connect all of your speed controllers and other CAN devices to, either daisy chaining through devices or branching out from hubs, but avoiding loops. Then the cRIO would talk to EVERY device on the bus, sending it commands and receiving data back at a reasonably good data rate. It's all digital, so you worry much less about noise mucking with your analog signals or interrupts or speed controller frequency drift mucking with your commands to the motors. Plus, you could get feedback from the speed controllers if they're equipped to sense current, etc.

Primary downside would be that you're now running (probably) 5 wires to each speed controller, sensor, etc. Plus every new device on the network reduces the speed you can talk to the others. And finally, bus termination, addressing, and a host of other details become pretty important to keeping communication fast and stable.

If you want a slightly technical description in more MechE terms, a CAN bus is something like if you had an intercom system in your house, where your only option was to talk to all the stations at once. Since it's a multicast bus, you have to announce just who your messages and replies are intended for so a conversation would go something like: "Hey Tom, I need your credit card info to pay for this spiffy new FRC controller." To which you might reply, "Hey Kevin, I'm still broke from the last FRC gadget you had me pay for!" And so on.

Also, since it's a multicast bus, you might get two people trying to talk at once. This could obviously cause confusion, which CAN solves in a few different ways, depending on the physical implementation. The simplest is that some messages have a higher priority than others and basically talk over the other messages. If a speaker hears someone talking over them, they wait till the end of that message then try again. There's various other methods, but the upshot is that everyone gets their say eventually, but some people have a higher priority than others.

The downsides I listed above equate to problems like trying to talk to two people with the same name, throughput problems if 40 people are all trying to talk at once, and physical problems like someone falling asleep with his finger on the Speak button and snoring over everyone. Of course, it's still better than the tin-can phones and telegraphs we're currently using.

Response to Adam:

Short Version: CAN is basically a serial communication standard that allows devices to be daisy chained.

Controller -> Device -> Device -> Device -> Device -> Terminator

Other network topologies are possible if you're using repeaters. Industrial versions can admittedly get a little pricey, but if FIRST is making us a bunch of other stuff anyways it'd make some things a little easier.

[Qbranch]

CAN is why it takes so long to feel comfortable driving a hybrid electric vehicle.

Nothing is connected to what it controls!

-q

(oh yeah and it carries control signals about airplanes and farm equipment, along with the occasional power plant, generator set, etc... the company I've worked for for the past three summers makes (among other things) CAN enabled industrial control modules)

[Joe Ross]

Originally Posted by Joe Johnson

As to claims of linearity, that depends on what you mean. The output may actually be very linear, but the system need not respond in a linear way.

My experience in automotive systems is that when you go from low PWM freq (100-400Hz) to higher PWM freq (10-20kHz), the motors do not respond the same, especially at low duty cycles.

For example, if, in order to get a system moving, we needed say 20% duty cycle at 100Hz, we would need to bump the duty cycle up to 30-40% at 10kHz PWM freq.

This was very puzzling but we eventually attributed this our mechanical system's time constant. At 100Hz, the mechanical system's time constant was such that the system had time to react during a single PWM pulse -- These "full on" pulses provided a kick to get the motors and gears turning. At 10kHz, the system can only react to the average not the individual pulses, so it required more on time to get things rolling.

Through the private beta test channels, I asked these types of questions. They just released some test data publicly, which show a very nice linear response without any slow starting when driving a CIM motor. http://forums.usfirst.org/showthread.php?t=10182

[The Lucas]

I'm bumping this thread to link to the Luminary Micro's Jaguar Motor Controller Characterization thread on the First Forums and attaching a copy of the excel sheet (for those who are not FIRST Forum members). This is obviously very important data for everyone to consider when controlling their robot and I am glad they can provide it to us so early in the process (thanks Joe Hershberger ).

EDIT: I started writing this post before Joe Ross posted (beating me to it) but got side tracked. I guess we think alike for where to post this data in this older thread.

A few comments: I am impressed with the linearity of the CIM Speed vs Pulse Width. However, I am not sure (and not qualified to speculate not a ME) how well this will linearity will translate to speed of a motor under load (normal 4 motor drive of 130 lb bot). In my experience, at lower powers on the victors the drive motors just hum so will the jaguars just hum (depending on gearing obviously) for a the lower portion of these graphs. Maybe a fast rise like the victors is better in this case?

[rwood359]

A few comments: I am impressed with the linearity of the CIM Speed vs Pulse Width. However, I am not sure (and not qualified to speculate not a ME) how well this will linearity will translate to speed of a motor under load (normal 4 motor drive of 130 lb bot). In my experience, at lower powers on the victors the drive motors just hum so will the jaguars just hum (depending on gearing obviously) for a the lower portion of these graphs. Maybe a fast rise like the victors is better in this case?

The linearity (assuming that it holds under load) makes it easier to build a table replacement for a custom response curve. Define the dead zone, fast rise to first motion, low slope at low speed for precise control, steeper slope to get to full speed.

[Al Skierkiewicz]

Brian, Joe and Dr. Joe,
These functions are more attributable to the segment spacing of the commutator vs motor speed vs PWM switching frequency. Each motor type will respond differently and the overall inductance of the windings will play a part as well. Often linearity is affected as much by the mechanical frictions within the motor and the load at low RPM as with any of the other variables. The "hum" in motors controlled by Victor controllers, I believe, is directly attributable to the low PWM frequency and short pulse duration. I have often observed teams who failed to calibrate the controllers and were supplying minimum pulse widths to their motor at rest. These short pulses were sufficient to bump the motor armature but could not supply enough current to overcome the friction in the drive train. One of the advantages to using 12 volt PWM is to get the motor moving while giving some speed control at low RPM. I expect the higher switching frequency to produce less hum in future systems. The upcoming season will give us some data on linearity under real world loads, stress on the motor in forms of heating, brush and commutator arcing, RF interference, etc. It will be interesting.

[Doc Wu]

Originally Posted by Greg Needel

HUUUUUUGGGGEEEE Rochester HUUUUUGGGGE (anyone from upstate NY will get that reference)

Hey, he was a sponsor of team 1507 for two years...

[jskene]

According to an NI video on the RIO, its dimensions are: 11.3" x 3.5" x 2.3", and it weighs 2.2 lb.

It will also withstand a 50g impact, so it sounds like it could do double duty as a bumper.