New Talon Speed Controller [Archive]

Tom Line

26-09-2012, 14:18

We'll be receiving a number of Talons and will be testing them alongside our Labview beta testing. It's an extremely exciting product. Active cooling isn't needed. It's got a conformal coating so it's got all the debris protection of the old victors. The higher switching frequency should give a linear response on the order of a Jaguar.

I'm a curious about their PWM input rate though. We know that a standard victor is around 17ms. A Jag is somewhere in the ballpark of 5ms.

What does .9 - 2ms @ 50hz mean? Does that mean it will respond in .9-2ms, but only accepts a change in input at a maximum of 50hz (meaning that the actual best response is 20ms)?

cbale2000

26-09-2012, 14:20

I'm excited! If you look at the comments/ratings page on the AndyMark page for Talon, it says that Team 67 demoed them at IRI, they didn't reset like jaguars do, do to high current!

Personally I'd be a bit more interested to know how these perform compared to a Victor rather than a Jaguar (especially considering how much better reliability Victors have from Jags anyways).

If this turns out to be a controller that would give us the reliability of something like a victor, but with the smoothness of control from something like a jaguar, I'd think it would definitely be the way to go.

Jon Stratis

26-09-2012, 14:21

A few notes:
- First, this is not an AndyMark product. It's made by Cross the Road Electronics, and AndyMark is only an outlet for sales.
- It sounds like the new Victor 888 will give this a run for its money, since both have a linear output.
- The passive cooling is a very nice touch
- The conformal coating is something that has been much, much needed in FRC applications. It's nice to see a speed controller that finally has one!

All that said, keep in mind we don't know what will be legal next year. Worst case, we'll still be limited to the Victor 884 and the Jaguar. Best case, those will both still be legal, but they'll add the Victor 888 and the Talon to the list!

Personally, I don't see any benefits the Victor 884/888 has over the Talon. The only benefits I can see from data provided for the Talon over the Victor 888 are the heat sink and conformal coating. Obviously, the linear output is another benefit over the Victor 884. Looking at the documents for each, I believe the Talon also has a slightly smaller footprint than the Victor 884.

Bringing the Jaguar into the mix, we know it has a larger footpint, which is a negative. However, it also has a linear output like the Talon and 888, and provides some additional functionality through the CAN interface and the ability for direct sensor feedback when using CAN.

For me, Jaguars have been preferred up until now (specifically for drive train) due to their linear output. These new controllers though, if FRC legal, completely change the equation. It seems that it now becomes a question of size versus functionality - if you don't need those inputs on the Jaguar, why use one? Depending on the number of speed controllers used and the number of DIO ports used, there might be size/weight tradeoffs available for using Jaguars and CAN, avoiding the need to include a second DIO module and DSC. Definitely something to look at!

Ether

26-09-2012, 14:26

What does .9 - 2ms @ 50hz mean?

Per the user manual, .9 to 2ms is the pulse width (duration of pulse).

50Hz is the frequency (max? or nominal?) of the pulses that can be processed.

falconmaster

26-09-2012, 14:28

I am curious if they perform the same as Jaguars at the low speeds, does anyone know? Andy? Mark? Do you know? How about Cross the Road?

Ricky Q.

26-09-2012, 15:20

A few notes:
...
- The conformal coating is something that has been much, much needed in FRC applications. It's nice to see a speed controller that finally has one!

Personally, I don't see any benefits the Victor 884/888 has over the Talon. The only benefits I can see from data provided for the Talon over the Victor 888 are the heat sink and conformal coating. Obviously, the linear output is another benefit over the Victor 884. Looking at the documents for each, I believe the Talon also has a slightly smaller footprint than the Victor 884.

Just for a point of clarification, the Victor 884 featured conformal coating. The new Victor 888 will as well.

Best,
Ricky

Camren

26-09-2012, 15:21

The best part of this is the fact that a rectifier prevents back flow into the controller. Which fried the majority of are jaguars.

Jon Stratis

26-09-2012, 15:38

Just for a point of clarification, the Victor 884 featured conformal coating. The new Victor 888 will as well.

Best,
Ricky

Awesome, I had no idea it did... I looked through the users manual (http://content.vexrobotics.com/docs/ifi-v884-users-manual-9-25-06.pdf) and didn't find any mention of it... where is this sort of information documented?

Ether

26-09-2012, 15:39

The best part of this is the fact that a rectifier prevents back flow into the controller. Which fried the majority of are jaguars.

It's not clear what your intended meaning is. What rectifier are you referring to? Which controller? And what is "back flow"?

plnyyanks

26-09-2012, 15:51

The best part of this is the fact that a rectifier prevents back flow into the controller. Which fried the majority of are jaguars.
Do you mean reverse polarity protection?
WARNING! The Talon does not have protection against
reverse polarity. It is important that the user ensures that
power has been connected in the correct polarity before
powering the Talon. If polarity is reversed, the Talon will be
permanently damaged.

(See Page 4 (http://www.crosstheroadelectronics.com/Talon_User_Manual_1_1.pdf))

Camren

26-09-2012, 16:10

Ok to clarify my above post.

Are team has found that any sort of free wheel action on the robot (ie pushing it) Causes the motors to become a generator that sends current back into the motor controller. Well with the Jaguars they didn't have anything to stop it so we fried a lot of them. The new Talon controller has The Talon features locked anti-phase rectification that provides more efficient delivery of power to Brushed DC motors. This type of rectification returns current to the power source during the freewheeling period of the motor and during direction change.

IndySam

26-09-2012, 16:12

Ok to clarify my above post.

Are team has found that any sort of free wheel action on the robot (ie pushing it) Causes the motors to become a generator that sends current back into the motor controller. Well with the Jaguars they didn't have anything to stop it so we fried a lot of them. The new Talon controller has

We have been pushing around robots with Jags as long as they have been available and have never experienced this problem.

Camren

26-09-2012, 16:17

We have been pushing around robots with Jags as long as they have been available and have never experienced this problem.

Interesting but in how long of increments like a few feet we have found that they would be fine. but a rookie pushing the robot down a hallway instead of using a cart was a problem. Also it could depend on if the robot is on or not.

Jon Stratis

26-09-2012, 16:34

Camren

26-09-2012, 16:45

Like IndySam, we've been doing this for years with no adverse affects on the Jaguars. This includes pushing it from one room to another (probably 100 ft). This is almost always with the robot off - we never push it long distances with it on... although just last night there was some small pushing going on to manually line the robot up for some testing while it was on (a few feet at a time).

This lead me to think that it is when the robot is on it leads to adverse affects if pushed more then a few feet. I have noticed that when on the robot is harder to push but that could just be me.

Ricky Q.

26-09-2012, 17:35

Awesome, I had no idea it did... I looked through the users manual (http://content.vexrobotics.com/docs/ifi-v884-users-manual-9-25-06.pdf) and didn't find any mention of it... where is this sort of information documented?

It is currently documented only on the Product Web page. We'll make sure the manual for the Victor 888 includes this information.

Thanks,
Ricky

Ether

26-09-2012, 17:43

Ok to clarify my above post...

From the scant technical detail so far available (if there's a schematic I haven't seen it), I can't see any reason why the Talon should be any different from the Jag when not powered, or when powered with a zero throttle command (in the deadband zone, you're either coasting or braking, not regenerating - someone please correct me if this in incorrect).

Tom Line

26-09-2012, 19:52

Per the user manual, .9 to 2ms is the pulse width (duration of pulse).

50Hz is the frequency (max? or nominal?) of the pulses that can be processed.

Ether: So do you see anywhere where it gives us the actual response of the Talon? 5 ms like the Jag, or 17 like the Victor?

I'm curious because I know some teams switched to Jags for better shooter control this year specifically because of the 5 ms response over the 17.

Ether

26-09-2012, 22:07

Ether: So do you see anywhere where it gives us the actual response of the Talon? 5 ms like the Jag, or 17 like the Victor?

Sorry Tom I haven't seen that anywhere. I assume Mike will provide that info the next time he visits this thread.

I'm guessing that the 50Hz number (20ms period) was given because it corresponds to the 20ms TeleOp period? The Talon may be capable of processing pulses coming in faster than that. But there's the driver issue. As I understand it, if you send commands at 10ms (100Hz) to the Victor driver, for example, you still get a 17ms period coming out of the driver.

maddoctor90

26-09-2012, 23:39

From the Talon User Manual "A Talon is a device used to control the rotational velocity (speed) of a brushed DC motor through modulating power over time. The Talon accomplishes this through an efficient form of rectification known as locked-antiphase rectification. This type of rectification returns current to the power source during the freewheeling period of the motor and during direction change."

From this quote and from what I perceived form talking to a guy from crosstheroadelectronics at IRI, I believe the Talon does have some regenerative capabilities. How they work and when they are active are two things I would love to have some clarification on.

rachelholladay

26-09-2012, 23:42

Well this is fairly exciting. I must confess that I would like to do a three way comparison of Victor vs Jaguar vs Talon. Last season we had issues with our gun for a while and were able to track that in part to what seemed to be the non-linear-ness of a Jaguar. We ended up swapping it for a Victor, which greatly improved the situation. Based on the supplied charts from the User Manual, the Talon seems to have pretty good linearity. That would certainly be an interesting series of tests for Beta Testing. (I am also wondering if the David Relay will be coming back for more testing, it was a neat little box of fun)

Although a rather minor point, I really like the lights feature, "The rate at which the led blinks is proportional to the percent throttle. The faster the LED blinks the closer the output is to 100% in either polarity." From the Jags and Victors I am very reliant on the color change for basic testing and while the blinking will probably serve more as a qualitative measure, it seems like a neat feature to have. (Although I'm sure that if I work with the Talon, a month later I'll have stared at blinking lights enough to go a little crazy).

I am a little surprised that there seems to be no CAN support, especially since this comes from Cross the Road Electronics, a vendor that supplies not only a lot of CAN equipment but 2CAN as well. There would have to be a major change in hardware to accommodate it, so I guess we should not be expecting CAN + Talon any time soon.

Looking ahead for the season my two logistics questions would be: what will come in the Kit (Rookie and Veteran)? If AndyMark is not selling Jaguars, who will?

JohnSchneider

27-09-2012, 01:44

Lack of CAN means we still have to use Jaguars :/

connor.worley

27-09-2012, 01:52

Lack of CAN means we still have to use Jaguars :/

Why is PWM out of the question?

jason701802

27-09-2012, 02:17

We have been pushing around robots with Jags as long as they have been available and have never experienced this problem.

We have killed at least one Jag this way (I think two), as well as another my hooking the output to power (which is almost the same thing) (all the Jags were tan). The one (or two) we killed, died when the robot was pushed fairly quickly. Since then, we try to avoid pushing the robot or at least push it slowly. We've never killed a Victor this way and have pushed these robots around much more aggressively.

Gdeaver

27-09-2012, 08:35

Mike Copioli

27-09-2012, 10:37

Sorry Tom I haven't seen that anywhere. I assume Mike will provide that info the next time he visits this thread.

I'm guessing that the 50Hz number (20ms period) was given because it corresponds to the 20ms TeleOp period? The Talon may be capable of processing pulses coming in faster than that. But there's the driver issue. As I understand it, if you send commands at 10ms (100Hz) to the Victor driver, for example, you still get a 17ms period coming out of the driver.

This was a typo in the User Manual. The actual refresh rate is 333Hz or (3 ms). The input capture is driven by an interrupt so as long as there is some space between the edges of the input pulse, the output will update correctly.
If your pulse spacing is 3 ms or greater you should have no problem.

Mike Copioli

27-09-2012, 11:27

The .9 to 2.0 ms with a 0 output at 1.5 ms asymmetric response confuses me. Why did they do this? This is going to lead teams to terrible out of the box experience. If the Talon is hooked up to the controller and the present Victor motor drive routines are used, then a team will not get full power in 1 direction. This will require calibration. One more step for teams to screw up. Which will lead to rants and support issues. The pulse timing is listed as 10 bit or 1024 buckets. With calibration there will be less settings in one direction than the other. Does it matter? probably no. The question this year will be " Did you calibrate your Talon." Response - "I don't know." "You have to calibrate your Talon." "How do you do that?" and on and on. Cross the roads - It's time for a firmware up grade before you let this thing out in the wild. Your life will be better if you correct this now before the Chief Delphi Flamming starts. Why was this done? Is it a clock counter timer issue? Asymmetric I don't like it. I don't remember ever seeing a commercial speed control with asymmetric response.

Ok,

Sit down, relax...I assure you the sky is not falling.

There were a couple typos in the user manual, the ACTUAL expected pulse width is 1.0-2.0 ms with the center = 1.5 ms. The user manual should have read .990-2.010ms. The reason for the 10 us gap is to over drive the pulse to ensure that any error in the input pulse does not cause the output to transition between full on and chopped. Let me make something perfectly clear; This is not necessary for the Talon to function smoothly or symmetrically, just a recommendation. On top of that the Talons firmware has 10 us(2%) of padding on each extreme of the input pulse.

Screwing up calibration is not really possible. The calibration values are checked against bounding values. If the cal values are outside of those boundaries the Talon will simply use the last "good" calibration values. The worst that could happen is truncation of the output.(full throttle is obtained at a lesser input value) But even then all you are really changing is granularity or resolution. Remember the Talon is 10 bit, the Victor uses 8 bit(which BTW is more than enough resolution)

Also to assume that you would only have two speed controller classes as before would be presumptuous. The Victor and Jaguar classes both use different timing parameters for full forward, full reverse and center. The Victor class uses 2.035ms = MAX, CEN = 1.526ms, MIN 1.032ms, this is also asymmetrical. If the Talon is deemed legal a Talon Class would most likely exist.

As far as calibration is concerned, if you are not already calibrating your PMW based motor controllers, you should be. Calibration not only corrects for pulse timing discrepancies, it also scales the out put MIN, MAX, and CEN to your joystick MIN, MAX and CEN.

So you can relax there is no need to upgrade your firmware, or flame the thread(although from my experience this will happen anyway). It was simply a mistake in the user manual.

JesseK

27-09-2012, 11:54

Calibration of motor controllers is a pretty standard practice in RC (especially in the quad rotor world). If the controllers aren't calibrated, the motors will not be in sync (i.e. receive the same power input) -- which could be an issue for motors that are mechanically linked. In quadrotors, the motors are linked via software PID for stability purposes, meaning uncalibrated motor controllers will cause a quadrotor to crash almost immediately.

Brian Selle

27-09-2012, 12:10

If the Talon is deemed legal a Talon Class would most likely exist.

Any hint from FIRST as to when we might know if the Talon is legal? Before Jan 5th?

mikets

27-09-2012, 12:39

Mike,
We switched to use CAN bus last year and was starting to enjoy using it. Plus we have invested in a couple of 2CANs. Any idea if Talon will eventually support CAN?

Jon Stratis

27-09-2012, 12:44

Any hint from FIRST as to when we might know if the Talon is legal? Before Jan 5th?

I suggest the first hint will probably come to the Beta Test teams, but there probably won't be any guarantee until kickoff!

Mike Copioli

27-09-2012, 13:59

Mike,
We switched to use CAN bus last year and was starting to enjoy using it. Plus we have invested in a couple of 2CANs. Any idea if Talon will eventually support CAN?

The answer is yes. And thank you.

dsirovica

17-10-2012, 19:34

Greetings, a new season has begun! and we seem to have a new speed controller that looks like a Vic!

A quick look at the Jag schematic says that when the robot is pushed, the generated current will try to flow in such a way to charge the battery. But if the battery is not connected the voltage to the PDB will keep rizing... Is there something in the PDB that will shunt this current - or something will blow!

Dean

Ok to clarify my above post.

Are team has found that any sort of free wheel action on the robot (ie pushing it) Causes the motors to become a generator that sends current back into the motor controller. Well with the Jaguars they didn't have anything to stop it so we fried a lot of them. The new Talon controller has

Al Skierkiewicz

18-10-2012, 07:42

Camren,
The type of locked antiphase PWM modulation that is used in the Talon is simply the method that used to turn on the FETs that provide motor currents. The FETs in the Talon, Victor and Jaguar all have diodes that provide a path back to the power supply while the motors are coasting or being pushed. This diode is a result of manufacture as I understand.

Rickie and Jon, not to mislead, the conformal coatings on the Victors protect the circuit board components, but the leads of the FETs are still sometimes exposed. Metal swarf still can kill a Victor but they are far more immune to this than the current TI/Luminary production Jaguars. I am going to guess (highly recommend) that the IFI production runs will contain the same conformal coatings as current Victor products. The really difficult component in the Jag to coat is the current sense resistor since this can dissipate large amounts of power/heat. However, if metal falls across it, there isn't likely to be any catastrophic failure since the value is so small.

Ricky Q.

18-10-2012, 07:56

Camren,
I am going to guess (highly recommend) that the IFI production runs will contain the same conformal coatings as current Victor products. The really difficult component in the Jag to coat is the current sense resistor since this can dissipate large amounts of power/heat. However, if metal falls across it, there isn't likely to be any catastrophic failure since the value is so small.

Al,

Yes, the Jaguar will feature the same conformal coating as the Victor.

Best,
Ricky

dsirovica

18-10-2012, 12:13

Sorry I've been out of the loop on this all summer:
What was the outcome of FIRST's RFP for Jaguar replacement?

Thanks,
Dean

connor.worley

18-10-2012, 12:17

Sorry I've been out of the loop on this all summer:
What was the outcome of FIRST's RFP for Jaguar replacement?

Thanks,
Dean

http://www.usfirst.org/roboticsprograms/frc/blog-10-03-12

Ricky Q.

18-10-2012, 12:17

Sorry I've been out of the loop on this all summer:
What was the outcome of FIRST's RFP for Jaguar replacement?

Thanks,
Dean

Dean,

Going forward, IFI will be manufacturing, selling, supporting, and donating Jaguars to the 2013 Kits of Parts.

More details are here: http://www.usfirst.org/roboticsprograms/frc/blog-10-03-12

Ricky

dsirovica

18-10-2012, 12:56

Thanks and excellent news!

I noticed he following:
"Second, the firmware will be modified to remove the current limit protection "

That is great too as that was probably the most significant issue with the Jag (there are others elaborated on on the blogs). However, I hope the current limit is only increased rather than dissabled completely (as in by shorting R23).

Thanks,
Dean

Dean,

Going forward, IFI will be manufacturing, selling, supporting, and donating Jaguars to the 2013 Kits of Parts.

More details are here: http://www.usfirst.org/roboticsprograms/frc/blog-10-03-12

Ricky

electroken

18-10-2012, 16:22

This was a typo in the User Manual. The actual refresh rate is 333Hz or (3 ms). The input capture is driven by an interrupt so as long as there is some space between the edges of the input pulse, the output will update correctly.
If your pulse spacing is 3 ms or greater you should have no problem.

All of our testing over the last 2 weeks has been at a refresh rate of 242Hz, as I was too lazy to reconfigure the PIC we're using for pulse generation.

I hope the Talon gets FRC approval. So far, this thing is bulletproof.

Tom Line

18-10-2012, 18:16

I'm super interested to hear what the electrical nerds have to say about this product. Is there any reason to stay with the Victor over the Talon (cost aside)?

Here's hoping we get some of these in the kit of parts.

So far, we've seen a whole lot of reasons to choose the Talon over the older Victors. The biggest one for us is that the talon is showing linearity as good as the Jag, better control around the zero point (smaller dead band), and a victor-sized footprint.

For an idea of just how bad the linearity is on a the Victor, look here:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/10-11-12_Day_3.shtml

Many teams have fixed that in software - so it can be done, but it's an extra step that is better handled in hardare.

Of course, there's a new Victor coming out as well. It's not exactly fair to compare an old product to the new Talon. Apples to apples will be the new Victor vs. the Talon.

Racer26

19-10-2012, 10:07

Wow. That non-linearity is pretty ugly.

Jon Stratis

19-10-2012, 10:53

For an idea of just how bad the linearity is on a the Victor, look here:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/10-11-12_Day_3.shtml

Darn, I was planning on doing a test like this later this fall (I was waiting for the new Victor)! When the new Victor comes out, can you add results from its performance and let us know here? I'd be very interested to see how it compares.

The Talon definitely looks good!

EricVanWyk

19-10-2012, 11:00

So far, we've seen a whole lot of reasons to choose the Talon over the older Victors. The biggest one for us is that the talon is showing linearity as good as the Jag, better control around the zero point (smaller dead band), and a victor-sized footprint.

For an idea of just how bad the linearity is on a the Victor, look here:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/10-11-12_Day_3.shtml

Many teams have fixed that in software - so it can be done, but it's an extra step that is better handled in hardare.

Of course, there's a new Victor coming out as well. It's not exactly fair to compare an old product to the new Talon. Apples to apples will be the new Victor vs. the Talon.

You really need to have some form of inductive load on an h-bridge to measure its linearity. The current gen Victors are very non-linear, but your measurement technique significantly over-states this.

Essentially, for a given bridge frequency and rectification style there is inductance * average current combination above which the bridge is nicely linear. Below that threshold, you will see weird non-linearities that are highly dependent on the specific motor and amount of current flowing. Above that threshold, it is close enough to "perfectly" linear.

Ether

19-10-2012, 11:08

For an idea of just how bad the linearity is on a the Victor, look here:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/10-11-12_Day_3.shtml

Wow. That non-linearity is pretty ugly.

Darn, I was planning on doing a test like this later this fall (I was waiting for the new Victor)! When the new Victor comes out, can you add results from its performance and let us know here? I'd be very interested to see how it compares.

Guys:

Read the fine print. That's open-circuit voltage linearity.

When connected to a loaded motor, the Vic 884 is much more linear.

Jon Stratis

19-10-2012, 11:12

Jeff Pahl

19-10-2012, 12:53

Yup, that's why I said a test like it, not the exact same test :p I've actually been talking with one of our mechanical mentors for the past 10 minutes about how we could best do a simulated load to repeat this testing with our team... We were thinking of putting two CIMs into a gearbox, and setting one of them to Brake (sending it a 0 signal), while trying to drive the other one. Any better ideas out there?

If you can get your hands on a big programmable DC load, connect the second CIM to that and you can then vary the load on the drive motor across a wide range. Finishing building mine has been on the "list of stuff that never gets done" for a while now.

You also can just put big various power resistors on the second CIM. We used to call them "toasters" in the motor lab.

Joe Ross

19-10-2012, 13:16

For anyone thinking about doing similar testing this offseason, I would recommend using the PWM class rather then the Jaguar/Victor Class. This removes any bias from scaling built into the Jaguar/Victor Classes.

Ether

19-10-2012, 13:22

For anyone thinking about doing similar testing, I would recommend using the PWM class rather then the Jaguar/Victor Class. This removes any bias from scaling built into the Jaguar/Victor Classes.

Or use this (http://www.chiefdelphi.com/media/papers/2702).

Jon Stratis

19-10-2012, 14:00

Joe - This is a rather interesting point. Using the PWM class would allow you to more accurately evaluate the speed controllers in a "stand-alone" fashion. However, that doesn't represent real-world (maybe FIRST-world is a better term?) use. When we use the speed controllers, we use the appropriate class to control them, specifically to allow the built in libraries to aid in scaling to give us a better response.

My thought is that teams would rather see results as though it was on their competition robot. However, it could be a great learning opportunity to run it both ways - then we could view concrete data on what the built in libraries actually do for us, and show the students the actual reason for doing things the way we do them.

Joe Ross

19-10-2012, 14:15

Ether

19-10-2012, 15:04

Someone mentioned apples-to-apples in an earlier post.

An argument could be made that for purposes of comparing the various motor controllers to each other, you want to run them without intervening third-party software.

Tom Line

19-10-2012, 18:52

Thanks for the suggestions guys. We'll go back and retest the linearity under a constant-load scenario. We'll trying using the PWM as well, to see if anything is significantly different.

Also, it appears we've had an offer to start testing the Victor 888's. I'm fairly excited to get side-by-side comparisons for both new products. More variety is always a good thing.

Ether

19-10-2012, 19:02

Tom,

The beta test URL link in your sig appears to be broken. Or maybe it's just my DNS acting up again?

it works now, but the LabVIEW tutorial link doesn't

Tom Line

19-10-2012, 19:04

Mark McLeod

19-10-2012, 19:12

... so we're redoing 5 hours of Labview Installations.
That's so the rest of us don't have to.
Thanks for the effort and the warning:)

Jon Stratis

19-10-2012, 23:24

Nope, it was my link. We just finished converting the whole site over to using Server-Side-Includes, and I didn't update the page extension to .shtml.

All fixed. And All Fixed again. Silly website revisions.

On another note, we're horribly behind right now. Our Labview 2012/13 installtion backfired on us. We were running administrator accounts, but we didn't right click the setup file and 'run as administrator'. There appears to be a world of difference when it comes to Labview between those two instances, so we're redoing 5 hours of Labview Installations.

Bleah.

From my experience, this isn't just a Labview problem... this is a Windows 7 problem (I assume that's what you're using?). They've started switching us over at work, and a lot of guys I work with have had all sorts of trouble getting software to work correctly due to permission issues.

Still, it's good to find it now, so it can be called out in the instructions in January!

Tom Line

24-10-2012, 01:57

Updated: added linearity tests with load and the Victor looks much better. The Victor 888's should be here Thursday or Friday, so we hope to get results for them out this weekend.

Dad1279

24-10-2012, 12:02

.......
For an idea of just how bad the linearity is on a the Victor, look here:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/10-11-12_Day_3.shtml
........

How did you measure voltage? Output of speed controllers is pulsed:

http://www.chiefdelphi.com/forums/showpost.php?p=892464&postcount=9

Any chance of measuring loaded rpm for the speed controllers?

Jon Stratis

24-10-2012, 12:13

How did you measure voltage? Output of speed controllers is pulsed:

http://www.chiefdelphi.com/forums/showpost.php?p=892464&postcount=9

Any chance of measuring loaded rpm for the speed controllers?

That's a good question for the unloaded measurements that were initially made. However, once you hook the speed controllers up to a motor, the motor essentially averages out the pulses for you. Last year we went to show the team how the speed controllers work by hooking up the output to our oscilloscope. At the time, the motors were still connected, which caused no end of confusion for me... I was expecting to see a waveform, and got a solid line at what looked like the average voltage you would expect! After the big "aha!" moment (more of a forehead slap and calling myself an idiot a few times), we unplugged the motors and saw the expected pulsed waveform.

Ether

24-10-2012, 12:20

How did you measure voltage? Output of speed controllers is pulsed:

http://www.chiefdelphi.com/forums/showpost.php?p=892464&postcount=9

That's a good question for the unloaded measurements that were initially made.

Many DC voltmeters can read the RMS of a pulsed waveform.

Any chance of measuring loaded rpm for the speed controllers?

Measuring loaded RPM is in their test plan. (The test plan is linked in Tom's signature)

Read Tom's most recent post in this thread. They re-ran it loaded and measured motor voltage. Motor voltage data should be similar to motor speed data, but I agree it would still be useful to compare the two.

Al Skierkiewicz

24-10-2012, 13:10

Tom,
Just to be sure, your load in these tests is the window motor?

Ether

24-10-2012, 13:14

Tom,
Just to be sure, your load in these tests is the window motor?

The way I read it Al, the window motor was the powered motor, and the load was the friction of the belt trying to drive an immobilized device:

The tests were completed the same way as before, with exception to adding a load to the motor controller that was being tested. We connected the motor controllers to a window motor that was attached to a band that is supposed to spin a roller. We locked the roller in place so we had the highest amount of friction possible.

I believe the output would have been even more linear had they used a different motor with a heavier load.

Tom Line

24-10-2012, 13:43

Tom,
Just to be sure, your load in these tests is the window motor?

That is correct. The window motor is connected via a vacuum drive belt to a 3/8 inch steel roller. We locked the steel roller in place so that the vacuum belt was slipping. That provided a constant load on the window motor.

Ether

24-10-2012, 15:07

Tom,

For each motor controller, how long did it take to run the test and record the data?

Also, did you record the motor current (a measure of torque load) ?

Al Skierkiewicz

24-10-2012, 15:07

Ether

24-10-2012, 15:10

Al Skierkiewicz

24-10-2012, 15:11

Perhaps we can convince Rich to make that in his spare time.

Tom Line

24-10-2012, 16:16

Tom and Ether,
I was just trying to equalize our previous discussions with regard to motor inductance and controller type. The window motor having different inductance than that of the CIM or larger Banebot types.

Al, would using a motor with a larger inductance considerably change our results? We didn't have a ready-made clutch mechanism that would provide constant torque back to a CIM, which is why we went with the window motor setup (it was how our ball-magnet worked in 2010).

Ether - the tests were performed quickly, within a span of about 5 minutes - one person ramping the PWM value in labview, another measuring, and a third inputting into excel. We measured the battery voltage before and after and did not see significant change.

Ether

24-10-2012, 16:40

If you ran a CIM at 25% of stall torque I think you'd see a noticeably more linear curve.

I asked about the current not because of concern about battery voltage, but because current is an indication of motor load -- which affects linearity.

EricVanWyk

25-10-2012, 01:51

Al, would using a motor with a larger inductance considerably change our results?

Yes, significantly. The non-linearity is from when the current ripple exceeds the average current. Doubling the inductance cuts the ripple in half, which in turn cuts the critical average current number by half as well.

Tom Line

25-10-2012, 02:58

Yes, significantly. The non-linearity is from when the current ripple exceeds the average current. Doubling the inductance cuts the ripple in half, which in turn cuts the critical average current number by half as well.

I see. We may go back later and look at linearity when hooked to a cim. I think we want to move on and hit our other tests, then circle back around. One last question. Would holding the cim shaft completely stationary then applying different motor voltages result essentially the 'best case' for linearity from the victor? I supposed that's something we could do fairly easily. We'd just have to do it for very short periods of time to prevent breaker-popping.

Al Skierkiewicz

25-10-2012, 08:25

Tom,
I don't remember seeing inductance numbers on most of the motors. Just having a larger motor doesn't mean the inductance is higher. It is more a function of the number of turns of wire in the motor. In the case of the CIM motors, as in most motors, the brush assy actually contacts more than one of the many windings. In the case of the window motor, (trying to remember from several years ago), there are three windings and a three segment commutator. So while running, one of the windings is always shorted out by the brushes. My gut tells me that the window motor has a higher inductance.
Holding the motor shaft on the CIM should not affect linearity but will cause max current all the time. This would be bad for both the motor and the speed controller.
As an explanation, inductance tends to oppose a change in current. So there is a definite length of time for the current to reach maximum when voltage is applied. When the pulse length is short, the current does not have a chance to reach maximum. The designers of the Victor took that into account when they reduced the switching frequency to 150 Hz. The Jag designers on the other hand were looking for fine motor control/linearity and that was accomplished by increasing the switching frequency to 15 kHz. For most of the motor we use, the low throttle values are significantly shorted than the time needed to reach full current. As memory serves, Ether did a simulation a few years back to demonstrate this.

Tom Bottiglieri

25-10-2012, 10:48

For what it's worth, we usually linearize our motor controllers based on output velocity and not voltage. This seems to work well.

Tom Line

31-10-2012, 22:43

For what it's worth, we usually linearize our motor controllers based on output velocity and not voltage. This seems to work well.

Tom, can you elaborate more?

Do you use the encoders in your drivetrain to measure the rate at different PWM outputs, create a polynomial from the resulting values, then use function in between the user input and motor set command?

Do you do it free in the air, or under some type of load?

Al Skierkiewicz

01-11-2012, 07:40

Tom,
We use the rotary encoders attached to a shaft in the transmission usually. This helps with autonomous as well.

Gdeaver

01-11-2012, 08:03

Couple comments. The window motor problem seams to only be experienced with positional control under PID. There are 2 parts The locking pins locking and the unit becomes locked up. The other is the heating of the PTC. The window motor test should not experience these problems. We only had problems with the window motor in 2010 while using them for our swerve steering.
Over the years many teams have used a joystick to victor function to change the response. Many times when the drivers get involved the function does not linearize the response. It is set for a " feel" that the drivers like. We have done this with jags too. We Got our Talon last week and will install it tonight for this weekends' competition. Will probably put it on the shooter motor.

Pat Fairbank

01-11-2012, 13:51

Tom, can you elaborate more?

Do you use the encoders in your drivetrain to measure the rate at different PWM outputs, create a polynomial from the resulting values, then use function in between the user input and motor set command?

Do you do it free in the air, or under some type of load?
We did it in the air using the encoders. Basically, we wrote an autonomous routine that sets the output PWM from 0 to 1 in steps of 0.01, pausing for a second on each value to achieve steady-state and recording only the last speed measurement.

We then normalized the speeds to [0,1] and plotted the results in Excel (PWM on the Y-axis, measured speed on the X). Playing around with Excel's trendline tool gave us the polynomial that looked the best, and we just took the coefficients and plugged them right back into our code.

Afterwards, we ran through the entire exercise again with the linearization function in place to verify that PWM was now linear with speed.

mikets

01-11-2012, 14:12

Pat Fairbank

01-11-2012, 14:17

Doesn't linearity depend on the load? Running the wheels in the air doesn't give you a realistic scenario. This is a long thread and I did not follow it very closely so I may be missing the point but if the goal is to make joystick drive of the robot more smoothly and more linear with respect to the joystick movement, shouldn't PID control on speed automatically does that? (i.e. the joystick reading specifies the "speed" instead of "power" of the robot).
To some extent, sure, but the frictional load of the gearboxes and wheels was close enough for our purposes, plus we were too lazy to figure out a way to apply a constant load while keeping the robot stationary. If we needed perfect linearity with the joysticks we would have implemented closed-loop control (as we did with the shooter after first linearizing with this method).

Tom Line

01-11-2012, 17:04

We did it in the air using the encoders. Basically, we wrote an autonomous routine that sets the output PWM from 0 to 1 in steps of 0.01, pausing for a second on each value to achieve steady-state and recording only the last speed measurement.

We then normalized the speeds to [0,1] and plotted the results in Excel (PWM on the Y-axis, measured speed on the X). Playing around with Excel's trendline tool gave us the polynomial that looked the best, and we just took the coefficients and plugged them right back into our code.

Afterwards, we ran through the entire exercise again with the linearization function in place to verify that PWM was now linear with speed.

Neat. Add a file-write to your auton routine, then a file-read on your actual linearization routine and you could do this in a minute or two in the pits and have it load the coefficients automatically when your robot boots up. Labview has a built in polynomial fitting VI that could be used to generate the coefficients.

Did you also attempt to correct for inequalities between the left and right sides of your drivetrain when you did this?

Thanks! I think we'll give that try for Beta.

Ether

01-11-2012, 18:18

We then normalized the speeds to [0,1] and plotted the results in Excel (PWM on the Y-axis, measured speed on the X). Playing around with Excel's trendline tool gave us the polynomial that looked the best, and we just took the coefficients and plugged them right back into our code.

This might be of interest:

http://www.chiefdelphi.com/forums/showpost.php?p=1169523&postcount=10

Pat Fairbank

01-11-2012, 19:57

Did you also attempt to correct for inequalities between the left and right sides of your drivetrain when you did this?
We didn't try; I don't recall that we noticed any significant difference between the sides or the directions of motor rotation, but that would have been a good place to fix it. We just took one set of data and used it for all four side/direction combinations (Tom and I are lazy and like to stop at "good enough", unlike some of the other mentors :)).

Something else I forgot to mention before -- we also tweaked the constant term in the polynomial such that the output is saturated slightly before the input reaches 1, to guarantee that the Victors receive a full-power signal at the extents of the joystick travel even if there's something slightly off mechanically or if there's rounding/precision error in the code.

inkspell4

01-11-2012, 21:23

Did u guys hear that the same people now are making jaguars and victors

IndySam

02-11-2012, 07:47

Did u guys hear that the same people now are making jaguars and victors

Yes and you would have known that if you had read this thread :)

Ether

02-11-2012, 14:23

Talon, Victor888, Victor884, and Black Jaguar speed vs torque tests at various PWM command levels. (http://www.chiefdelphi.com/media/papers/2720)

Richard Wallace

02-11-2012, 15:14

Talon, Victor888, Victor884, and Black Jaguar speed vs torque tests at various PWM command levels. (http://www.chiefdelphi.com/media/papers/2720)

Nice job on the testing and presenting the data!

Based on these results, the Talon is looking pretty good. Nice linearity, both speed vs. torque for constant demand, and speed vs. demand for constant torque. Like a Jag. Should produce a nice intuitive feel for drivers.

theprgramerdude

05-11-2012, 21:51

Mike Copioli

06-11-2012, 12:46

It seems like the Talon is essentially just a different version of the same thing that the new 888 and Jaguar provide. There's really no appreciable difference between them, except that the Talon provides passive cooling. As a side note, based on the dynamometer tests, it seems like the new models (not the 884) have a much better high-side driver for full power and lower resistance than the older 884.

There are some other differences:

- Smaller footprint
- Lower mass
- Improved ingress protection
- Secure PWM connection
- Brake is maintained during disable
- PWM input can be split (2 Talons on one PWM channel)
- Higher switching frequency
- Lower on-state resistance
- Locked anti-phase rectification
- Clear polarity indicators
- Smart LED

Ether

06-11-2012, 12:59

As a side note, based on the dynamometer tests, it seems like the new models (not the 884) have a much better high-side driver for full power and lower resistance than the older 884.

What test data are you looking at as a basis for that conclusion?

Ether

06-11-2012, 13:09

There are some other differences:
...
- PWM input can be split (2 Talons on one PWM channel)
...

Mike, can you please tell us what is the rated maximum forward current the LED in the Talon's optocoupler can sustain without damage? Also, what is the minimum current required to guarantee pulse detection? One more: what is the rated maximum reverse voltage it can sustain? I ask because I want to make sure I use a properly designed cable with the custom PWM signal generator I use for testing.

Tom Bottiglieri

06-11-2012, 13:51

The Talon looks great, but it is going to have to compete on price with the 888 to make it on to our robot for 2013. We will probably wait until January to purchase speed controllers.

billbo911

06-11-2012, 14:00

The Talon looks great, but it is going to have to compete on price with the 888 to make it on to our robot for 2013. We will probably wait until January to purchase speed controllers.

Maybe I missed something, which is highly possible, but from what I've read, the 888 is approved for 2013, but I haven't seen the same for the Talon.
I HOPE I'M WRONG!!

Jon Stratis

06-11-2012, 14:07

Maybe I missed something, which is highly possible, but from what I've read, the 888 is approved for 2013, but I haven't seen the same for the Talon.
I HOPE I'M WRONG!!

Yes, you are wrong... There has been NO official communication that the Victor 888 is legal this year. Personally, I believe we'll be told which speed controllers are legal prior to FIRST Choice going live, as that could directly influence how we spend our PDV's.

billbo911

06-11-2012, 14:16

Yes, you are wrong... There has been NO official communication that the Victor 888 is legal this year. Personally, I believe we'll be told which speed controllers are legal prior to FIRST Choice going live, as that could directly influence how we spend our PDV's.

This is one time when I don't mind being wrong.

The reason I believed, and still do, that the 888 will be legal is based on the announcement of the price they will be available for during Dec. 5th -April 20th.
I know I'm reading the tea leaves here, but this reading seems fairly clear, IMHO.
Now, if the Talons go for a similar price, the decision might be a bit more difficult, but for now, the 888's seem to be an "obvious" choice......once officially approved.

Bob Steele

06-11-2012, 14:43

While I think it is certainly great that IFI is putting the new 888 controller on sale at $50 I find the timing interesting... pretty much pushing the Talon speed controller sales right down the toilet.

i have some and I think they are really nice in form factor and performance but how can a team reasonably want to use them if they are twice as much as the new 888?

maddoctor90

06-11-2012, 14:52

Personally, I believe we'll be told which speed controllers are legal prior to FIRST Choice going live, as that could directly influence how we spend our PDV's.

From the FRCBlog post, the only motor controllers that can be bought with the PDVs are the Jaguar or Victor (not sure which one) from IFI. The AndyMark PDV excludes items that AndyMark carries from other suppliers (Talon - Cross The Road Electronics).

Because of this, it is a real possibility that FIRST won't officially tell us if the Talon or Victor 888 (if the 884 is the only one offered with the IFI voucher) will be legal till kickoff. I would really like FIRST to come out and clear up some of this confusion though as soon as possible. If IFI is selling the Victor 888 on December 5th at $50 for FIRST Teams then I think we are all going to assume that they are legal. I don't think it is fair for the Talon by Cross the Road Electronics if we don't know it's legality by then. I would doubt many teams will plan on using the Talon when they already assume the $50 Victor 888 will be legal.

The Talon does offer some advantages over the Victor 888. It does have a lower R_DSN or "on resistance" then the Victor 888 and this would equate to power savings and allow more power delivered to the motor when near stall or highly loaded. Ether's tests support this showing the spike current to be near 130 amps for the Talon and only 120 amps for the Victor 888. It also has a few handy features already mentioned. Whether these differences will be worth and extra $50 per controller and the wait to know if they are legal is going to be decision teams will have to evaluate for themselves.

Ether

06-11-2012, 16:03

[The Talon has] a lower R_DSN or "on resistance" then the Victor 888

May I ask: how do you know this?

... this would equate to power savings and allow more power delivered to the motor when near stall or highly loaded. Ether's tests support this showing the spike current to be near 130 amps for the Talon and only 120 amps for the Victor 888.

I wouldn't recommend using the transient inrush current test to draw that conclusion.

Look at the curves in the speed vs torque report. The Victor888 and the Talon create virtually identical power output from the CIM at max PWM. See attached graph showing the max PWM traces from the report overlaid for Talon and Vic888.

Mike Copioli

06-11-2012, 17:07

Mike, can you please tell us what is the rated maximum forward current the LED in the Talon's optocoupler can sustain without damage?

I forward MAX continuous = 60mA
I forward Peak = 3 amps

Also, what is the minimum current required to guarantee pulse detection?

I turn-on MAX= 1.6mA

what is the rated maximum reverse voltage it can sustain?

Vrev MAX = 6 volts.

Ether

06-11-2012, 17:10

I forward MAX continuous = 60mA

I forward Peak = 3 amps

I turn-on MAX= 1.6mA

Vrev MAX = 6 volts.

OK great. My existing cables will work fine. Thanks.

maddoctor90

06-11-2012, 17:35

Look at the curves in the speed vs torque report. The Victor888 and the Talon create virtually identical power output from the CIM at max PWM. See attached graph showing the max PWM traces from the report overlaid for Talon and Vic888.

I was looking at Mike's post which states "lower on resistance" as difference between the Victor 888 and the Talon. Thanks for plotting both the Victor 888 and Talon together. I would agree, if the Talon does have a lower on resistance, it does not show when plotting the test data together.

theprgramerdude

07-11-2012, 18:24

There are some other differences:

- Smaller footprint
- Lower mass
- Improved ingress protection
- Secure PWM connection
- Brake is maintained during disable
- PWM input can be split (2 Talons on one PWM channel)
- Higher switching frequency
- Lower on-state resistance
- Locked anti-phase rectification
- Clear polarity indicators
- Smart LED
What are these differences in respect to? The Jaguar? The Victor?
Also, what is locked anti-phase rectification? I've never heard that used before. Most of the other features are already available in some form on either the Jaguar or Victor, with the exception that they don't occur on both at the same time.

theprgramerdude

07-11-2012, 18:30

What test data are you looking at as a basis for that conclusion?

I take back what I said about the driver, as it could also quite easily be the increased switching speed and better MOSFET's, but for maximum power output, the newer controllers can achieve a much higher speed at a given torque than the old Victor 884. This might just be due to the switching issues though that 120 Hz present.

theprgramerdude

07-11-2012, 18:34

Additionally, question about the test: Was there time allowed between runs for the motor to cool down to ambient before starting up again? If not, which runs were done "hotter" than others?

AlexH

08-11-2012, 19:06

so does anyone know why the heatsink on a talon only touches the cap and not the board?

mikets

08-11-2012, 19:08

I've never seen a Talon controller, but are you sure that's a cap not a MOSFET?

Mike Copioli

08-11-2012, 20:12

so does anyone know why the heatsink on a talon only touches the cap and not the board?

It touches both.

Ether

08-11-2012, 21:38

the newer controllers can achieve a much higher speed at a given torque than the old Victor 884

Nothing I've seen supports the above statement.

What data are you using to draw this conclusion?

scottandme

12-11-2012, 15:27

F22Rapture

12-11-2012, 15:42

Talons are FRC legal as per the AndyMark email blast.

Seems that they're responding to market pressure ($50 pricing for IFI 888's), and dropped the price to $59.00. Hard to pass up at that price.

http://www.andymark.com/Talon-p/am-2195.htm

Wow. That basically makes them an automatic buy for us, unless the price of the Jaguars is also reduced.

Gary Dillard

12-11-2012, 15:47

Talons are FRC legal as per the AndyMark email blast.

As I pointed out in another thread, an email from AndyMark doesn't make something FIRST legal; that ruling can only come from an official communication from FIRST. However, the fact that it is in FIRSTChoice appears to make it legal according the the FIRST Blog.

In this case it appears that the net effect is the same, just be careful on jumping to conclusions.

Tom Line

13-11-2012, 12:14

They are legal. A couple of phone calls confirmed that. No word confirming it on the 888 yet.

In addition, I just got confirmation that the 888 is legal as well.

Data for the failure amperage has been retracted: it appears we made have had some measurement errors. We'll reupdate after we fry a couple more.

Ether

13-11-2012, 13:18

Tom, I think the relevant metric that's missing here is: "how much torque can each motor controller generate (driving a locked-rotor CIM) without popping the breaker".

If we had a locked-rotor-CIM torque vs battery rms current for each controller, I think that would answer the question.

Jon Stratis

13-11-2012, 13:47

Looking through everything that's been generated about the different speed controllers, I think we have enough information to come to some general conclusions for each (please note these are my own conclusions, yours may vary):

Victor 884 - It's been the go-to speed controller for many, many years. However, it's failings in linearity and the introduction of the Victor 888 have relegated it to a back shelf. It's still great for applications where fine-tuned speed control (especially slow speed) isn't necessary, if you have some laying around collecting dust.

Victor 888 - A step up from the Victor 884 in linearity. In fact, Ether's graph's put it on par with the other speed controllers, although those from 1718 show that they "over corrected", which could cause a loss in definition at high speeds. More work may need to be done to show which graph is more accurate for FRC uses.

Jaguar - No real surprises here. The Jaguar has maintained its linear response nicely for years. The addition of CAN (and the associated limit/encoder/potentiometer feedback) may make this the ideal speed controller for many teams. The most obvious downside, however, is the larger footprint the Jaguar has, which may also make it less than ideal for many teams. Also note that the Jaguar has a slightly larger deadband than the other controllers.

Talon - The Talon seems to be a great mix of all the others. It provides the small deadband and small size we got from the Victor, and the linear response we got from the Jaguar. The fact that it can be used only with passive cooling and no fan is a great bonus (although I would still put a fan on any used for the drive train or other strenuous applications).

With this combination of speed controllers, it seems that we have one for every situation. I think the difficult part for most teams is going to be finding a noticeable difference between the Victor 888 and the Talon, aside from the passive cooling in the Talon.

Ether

13-11-2012, 14:12

...although those from 1718 show that they "over corrected", which could cause a loss in definition at high speeds

Hi Jon, could you please elaborate on the following:

1) what specifically are you referring to: "those from 1718"

2) what do you mean by "over corrected"

3) what do you mean by "a loss of definition"

Thanks.

Jared Russell

13-11-2012, 14:34

The AndyMark product page for the Talon (http://www.andymark.com/Talon-p/am-2195.htm) says something interesting:

"Do you want your motor to hold it's position after power is cut?"

How does the Talon provide this? Does it stay in brake mode even after power is removed?

Jon Stratis

13-11-2012, 14:36

I'm referring to these images:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Pictures/victor888_output_no_load.png
http://www.fightingpi.org/Resources/Controls/Beta/2013_Pictures/pwm_vs_velocity_1_cim.png
from 1718's beta testing: http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/11-3-12_Day_9.shtml

Basically, the Victor 884 curved away from being linear in one direction, while the 888 seems to curve a little bit away in the other (thus over corrected when adjusting the 888 to be more linear than the 884).

The result would be the exact opposite of the 884 - you would be able to finely tune the speed of your motor at the low end, as each step change in input would be a smaller change in output, but would have worse control at the high end, as the same step size would result in a much larger change in output.

Of note, the data you gathered didn't seem to show this same result, which leads to a question of which data set more accurately reflects real-world usage on a FIRST robot. Only having two data points makes it tough to reach a conclusion on this.

Ether

13-11-2012, 15:04

Of note, the data you gathered didn't seem to show this same result, which leads to a question of which data set more accurately reflects real-world usage on a FIRST robot.

The first graph you linked was using a Window motor, not a CIM, with unknown torque load.

The second graph you linked was using a CIM with unknown (and possibly changing) torque.

All the testing I did was with a CIM motor on a dynamometer with measured torque load.

So it's difficult to compare the data.

Tom Line

13-11-2012, 15:19

AdamHeard

13-11-2012, 15:21

That is correct, and we're verified it.

It stays in brake after power is removed.

Is there still a jumper to enable/disable brake mode?

Tom Line

13-11-2012, 15:24

Is there still a jumper to enable/disable brake mode?

Yes there is.

However, one thing we didn't verify is what happens if the jumper is set to coast and the pwm signal is killed.

Mike C. can probably answer that without us doing another test.

Jon Stratis

13-11-2012, 15:35

So it's difficult to compare the data.

Agreed!

Ultimately, graphs can only tell you so much... the real "proof" is what the drivers think when you stick some of these onto a drive train. I know when we switched from Victors 884's to Jaguars, there was a noticeable improvement in our ability to control the robot. Would there be a noticeable difference switching between Victor 888's, Jaguar's, and Talon's? Personally, I wish I had about $400 to spare so we could buy 4 Talons and 4 Victor 888's and swap them out on last year's robot!

Ether

13-11-2012, 16:28

So it's difficult to compare the data.

When you're trying to do closed-loop control of speed, you might want to see what the torque response vs command looks like at various speeds.

So I just wrote an awk script to re-arrange the raw RPM vs Nm data to provide a family of curves of Nm vs IPW1 at various RPM levels.

Here's the result:
http://ether.comeze.com/FRC/WMCT801/

1 input pulse width in ms

flameout

13-11-2012, 16:50

It stays in brake after power is removed.

The way I'm interpreting this is that, after the main breaker is switched off, dynamic braking still occurs (i.e. the output is still shorted). This is very different from saying that the behavior at a neutral command is to dynamically brake the motor.

Could you confirm that brake mode persists after the main breaker is switched off? This could become a serious issue when teams need to push the robot around by hand.

Also, if this really is the case (I'm skeptical), could someone answer how this (feature apparently?) was implemented.

s1900ahon

13-11-2012, 18:09

The way I'm interpreting this is that, after the main breaker is switched off, dynamic braking still occurs.

I would not have interpreted it they way you have. I would have interpreted it as that when the PWM signal is disabled (flatlined) the Talon continues to apply brake mode if the brake/coast jumper is set to brake.

When the main breaker is switched off, power is cut to everything, including all Talons, Victors, and Jaguars. At that point, the MOSFETs in the H-Bridge turn off and the only conduction possible is through the reverse body diodes.

flameout

13-11-2012, 18:14

I would not have interpreted it they way you have. I would have interpreted it as that when the PWM signal is disabled (flatlined) the Talon continues to apply brake mode if the brake/coast jumper is set to brake.
That makes sense, and matches the behavior of every other FRC-legal motor controller.

When the main breaker is switched off, power is cut to everything, including all Talons, Victors, and Jaguars. At that point, the MOSFETs in the H-Bridge turn off and the only conduction possible is through the reverse body diodes.
This is why I'm skeptical -- and why I was curious to know how my interpretation is possible.

I'll assume your interpretation is correct, then, unless someone comes in and confirms that mine was correct.

Thanks for clearing that up.

Mike Copioli

13-11-2012, 19:51

Mike Copioli

13-11-2012, 19:55

I would not have interpreted it they way you have. I would have interpreted it as that when the PWM signal is disabled (flatlined) the Talon continues to apply brake mode if the brake/coast jumper is set to brake.

When the main breaker is switched off, power is cut to everything, including all Talons, Victors, and Jaguars. At that point, the MOSFETs in the H-Bridge turn off and the only conduction possible is through the reverse body diodes.

Scott, you are correct.

Tom Bottiglieri

15-11-2012, 14:42

Has anyone with a Talon trying to control it with a cRIO/WPILib found a set of PWM signal timings that work well? The source for the Victor notes that signal acceptance between units was a bit off and I was wondering if this can be attributed to the signal generator or consumer side. I have a feeling this can be chalked up to poor calibration on the Victor as the cRIO generating sloppy signals seems less likely.

If no one responds we will run a test across 4 Talons to find timings that work, then post the results here and to WPILib.

From Victor.cpp:

/*
* Note that the Victor uses the following bounds for PWM values. These values were determined
* empirically through experimentation during the 2008 beta testing of the new control system.
* Testing during the beta period revealed a significant amount of variation between Victors.
* The values below are chosen to ensure that teams using the default values should be able to
* get "full power" with the maximum and minimum values. For better performance, teams may wish
* to measure these values on their own Victors and set the bounds to the particular values
* measured for the actual Victors they were be using.
* - 210 = full "forward"
* - 138 = the "high end" of the deadband range
* - 132 = center of the deadband range (off)
* - 126 = the "low end" of the deadband range
* - 56 = full "reverse"
*/

Ether

15-11-2012, 15:06

Joe Ross

15-11-2012, 16:06

Using a custom PWM signal generator, I have run the Vic888 with periods from 5ms to 20ms, and with pulse widths from .5ms to 2.5ms with no problems. I believe I did the same with the Talon, also with no problems.

Just calibrated an 888 driving a 500 ohm resistive load. Calibrated to 2.000 ms max, 1.000 ms min, and 1.500 ms neutral. Then measured, and got 1.990 ms max, 1.021 ms min, and deadband from 1.482 ms to 1.523 ms

The problem that the comment that Tom is referring to was finding what values work best with factory default calibration, and with the Victor 884, it varied unit to unit.

Ether

15-11-2012, 16:54

FWIW. Vic888 calibration using 500 ohm resistive load.

Ether

15-11-2012, 20:54

Here's another calibration chart for the 888, this time with reduced range and asymmetric calibrations. The 1.625 is not a typo.

Jon Stratis

15-11-2012, 23:38

Ether - In practical terms (aka what a team would see from the Victor on the field), what all do those charts tell us about how we should be calibrating the Victors? I understand what the values mean, I'm just not sure how to best apply them.

Ether

16-11-2012, 00:14

The primary intent of the charts was to give a peek under the hood of what actually happens when a motor controller is calibrated.

A practical application is that the charts suggest that the 888 seems to have an adequately large range of calibration to handle expected min/max/neutral variations in joysticks and other UI devices, and provides some overtravel at each end to prevent any throttle clipping.

IndySam

16-11-2012, 14:32

FRC Blogged (http://www.usfirst.org/roboticsprograms/frc/blog-11-16-12)

It's official

2013 Control System

First, the list of approved motor controllers will be expanded. Specifically, Cross the Road Electronics’ Talon and Innovation First’s Victor 888 motor controllers will be legal.

nuggetsyl

18-11-2012, 12:57

We drove 2 side comps with no fans on our drives. Temp never went above 83 degrees and only took 10 mins to drop back to room temp. Our team is sold and we just bought 12 more for this upcoming season.

sanddrag

18-11-2012, 13:20

Richard Wallace

18-11-2012, 14:33

This is a lengthy thread I haven't been able to keep up with. I know Ether has done a lot of testing. Can someone give me the cliffs notes of the motor performance differences between the Victor 888, Talon, and Black Jaguar ?

Short version:

Talon linearity is nearly as good as a Jaguar. Talon is less susceptibile to shorting due to swarf.

Victor 888 linearity is much better than Victor 884, but not as good as Talon or Jag.

Jags have CAN now. Talons will have it later.

Competition has provided customers with better performance and prices.

nuggetsyl

18-11-2012, 20:26

Number one reason to buy the talons. Not jumping back 4 feet when you brush you finger against a fan and you think you just lost your knuckle lol.::ouch:: I think i did more injury to myself jumping from fans then everything else combinded.

sanddrag

18-11-2012, 20:42

Maybe I missed it somewhere, but how does the width of the terminal space compare to the Victors? On the Victors (at least the 884s) I've found some terminals to be too wide to fit.

Richard Wallace

18-11-2012, 20:52

Maybe I missed it somewhere, but how does the width of the terminal space compare to the Victors? On the Victors (at least the 884s) I've found some terminals to be too wide to fit.Yeah, I've seen that problem also. When I found the right terminals, I bought a big bag of them. That was about six years ago, and now my supply is running low -- time to figure it out again.

Based on the day we spent testing Victors, Talons, and Jaguars in my lab, I recall that our terminals fit Talons and Victors the same way. I think Victor and Talon footprints are the same, and their terminal layouts also match. Mike and Paul should be able to confirm or counter.

Tom Line

19-11-2012, 23:47

I wanted to follow up on our promise to toast the Talon. We didn't really accomplish it the way we meant to. First, we ran the Talon without a fan. We connected 2 cims to the output, and 4 inputs from the PD board. We locked the drivetrain in place, and then started ramping up the voltage.

Initially, we thought we had an infant mortality when the Talon dropped out at around 60 amps. The truth of the matter (after disassembly and testing back at the manufacturer) was that the Talon got SO hot that it desoldered components from the board. That's what happens when you run 60 amps through an uncooled speed controller for an extended period. It still didn't actually smoke for us, though I understand it did when it had cooled and resoldered some of the joints at the manufacturer.

Today we retested the Talon with a fan on it. We hooked it up to 1 cim, 2 inputs, and ramped the amperage up. In this case, we had a borrowed Cross The Road engineer with a datalogger in-line with the input to the Talon, so we know exactly how much amperage we were running. We couldn't kill it. We ramped up to 74 amps continous (for an extended period). The silly thing just wouldn't die.

The Victor provided equally good results in both cases. The bottom line is that there is NO way an FRC team should be able to fry either one of these with a fan on.

We have one more 'test' we'd like to try: we're going to bolt a talon to an aluminum bar (simulating a chassis bar) and see if it sinks enough heat to keep the Talon happy over extended periods at high amperage. I think that will wrap up our Beta season this year.

sanddrag

20-11-2012, 00:01

Today we retested the Talon with a fan on it. We hooked it up to 1 cim, 2 inputs, and ramped the amperage up. In this case, we had a borrowed Cross The Road engineer with a datalogger in-line with the input to the Talon, so we know exactly how much amperage we were running. We couldn't kill it. We ramped up to 74 amps continous (for an extended period). The silly thing just wouldn't die.I'd be curious about this same test but with no fan. Did you happen to perform that at any point?

Tom Line

20-11-2012, 03:37

I'd be curious about this same test but with no fan. Did you happen to perform that at any point?

No, we didn't. I'm not sure how much additional practical data we'd get from that. Here's my take on it. We found that a Talon without a fan can be killed by a very high (by FIRST standards) amount of current for an extended time period. In fact, you can't generate that much in FIRST because of the 40 amp breakers.

I think the data in the user manual really covers the rest of the questions with regards to FIRST applications. For instance, look at the 30 amp data in the user manual. Keep in mind that a single cim pulling 30 amps through an entire match is fairly unlikely.

The graphs show data for a 3 minute match and a 7 minute cool down. Using that data you'll be wandering into a temperature zone you probably don't want to stay in after four consecutive back-to-back matches. So, it appears that unless you find a novel way to keep them cool without a fan, you may want a fan on a drive train application.

Of course, we could attempt to quantify this further with more scientific tests, but I think it would be a waste of time. If teams choose to go without fans in high-current applications, they should grab an infrared thermometer and check the Talon after practice matches to see how much your temps are changing. Or measure the current you're drawing, and extrapolate from there using the User Manual charts. Or get really fancy and wire a thermistor back to the cRio and log the data.

If only we had endless time to play :D

Gary Dillard

20-11-2012, 07:46

The bottom line is that there is NO way an FRC team should be able to fry either one of these with a fan on.

Key word in this quote is "should". So I don't need to cover my speed controllers when I'm grinding aluminum now? Excellent.

Gdeaver

20-11-2012, 08:10

Tom,
That is a static resistive test. You are most likely testing the current carrying capacity of the FET bond wire. The thin wire that connects the FET leads to the chip die. Most recent heavy duty FETs are current limited by the bond wire. The die can carry more current than the bond wire. It's a one shot thermal fuse. Hook a FET up to a direct short and watch the case pop. The bond wire vaporizes and blows the case. To really test the Talon you need a dynamic test to stress the die. You need to have the H-bridge coping with switching transients. A good test would be to but a cim into a gear box with a fly wheel attached. Say like a AM pneumatic wheel or a little heavier. Test by applying full power till it is up to speed and then reverse the direction. Wait till it gets up to speed reverse direction. This will stress the FET die in addition to the bond wire. Again with modern power FETs This repetitive avalanche condition affects the FET thermally. It's more like a real world FRC condition. My robot goes forward my robot goes backwards. Especially in this years game. If a Fet is allowed to heat beyond Tj max they fail fast. However if they are subjected to high temps close to Tj max they will have a shortened life. High energy switching transients tend to damage the structures around the gate. For these reasons teams should monitor the talons heat sink temp and a small fan would be a good idea in most drive train applications. Drive teams tend to go hard on the robot way beyond the 2 minute match time. Andy Mark has a IR thermometer on First Choice. A wise purchase for Talon running teams.

JesseK

20-11-2012, 09:38

Given that a hot Talon gets de-soldered vice totally melting down I wonder if the reliability of the Talon goes down with age, particularly if a team decides to NOT use a fan along the way.

sanddrag

20-11-2012, 10:15

When designing robots, we also factor into the design offseason use such as parades and demos. With our most recent robot, we did a week-long demo doing light running continuously every day without pause except for battery changes (which were approximately once every hour). Victor 884s never gave a hiccup. I want to make sure we have the same success with whatever future controller we went with. It would be nice to not have fans, but but I suppose we could add them if needed.

Ether

20-11-2012, 15:16

The Victor provided equally good results in both cases.

Tom, just to be clear what "both cases" means. Are you saying the Victor survived this test:

First, we ran without a fan. We connected 2 cims to the output, and 4 inputs from the PD board. We locked the drivetrain in place, and then started ramping up the voltage.

Tom Line

20-11-2012, 15:55

Tom, just to be clear what "both cases" means. Are you saying the Victor survived this test:

I can see why that was a little confusing. I suppose I should have been more concise and listed it out in table form.

Test 1:
Talon with no fan.
Driving 2 stalled cims with 4 inputs from the PD board.
Fluke ammeter reporting amperage on the positive battery lead.
Died at 60 amps.
Root Cause: Temps were above 100 C, and the board desoldered.

Test 2:
Victor with fan.
Driving 2 stalled cims with 4 inputs from the PD board.
Fluke ammeter reporting amperage on the positive battery lead.
Ramped up to 80+ amps and the robot began turning off and on.
Ramped back to 80 amps and ran for about 30 seconds without a problem.

Test 3:
Talon with fan driving 2 stalled cims with 4 inputs from PD board.
Fluke ammeter reporting amperage.
Ramped to 80 amps without a problem, held at that point for 30 seconds without a problem.

Test 4: (verification of our fluke ammeter readings)
Talon with 1 stalled cim and 2 inputs from PD board
Inline datalogger ammeter plugged via USB to laptop.
Datalogger was placed on the positive lead from the PD board and fastened to the speed controller.
Ramped to 74 amps without a problem: above this the 40 amp breakers began resetting.

In each case with the fluke, we zeroed it when the robot was enabled with no pwm signal sent to the motor. The robot ran between 3-5 amps on the positive battery lead when enabled with all motors at rest.

JB987

21-11-2012, 17:13

Anybody out there comfortable with using a fan-less Talon for competition?

Richard Wallace

21-11-2012, 17:22

Anybody out there comfortable with using a fan-less Talon for competition?
Not me. Not when fans (http://www.andymark.com/product-p/am-2335.htm) are so cheap.

I want my drive team free to push their robot to its limits.

sanddrag

21-11-2012, 17:34

Not me. Not when fans (http://www.andymark.com/product-p/am-2335.htm) are so cheap.

I want my drive team free to push their robot to its limits.So then what's the benefit over a Victor 888, which can be purchased for less cost? Just the fact that it isn't open for debris to fall inside?

Richard Wallace

21-11-2012, 17:39

So then what's the benefit over a Victor 888, which can be purchased for less cost? Just the fact that it isn't open for debris to fall inside?That, and better linearity (http://www.chiefdelphi.com/media/papers/2720). Talon linearity is almost like a Jaguar, Victor is not.

cgmv123

22-11-2012, 09:19

Anybody out there comfortable with using a fan-less Talon for competition?

Based on what I've seen, I'd feel comfortable using it sans fan on anything that's not a CIM or Fisher-Price motor and/or isn't on a 40-amp circuit. I'd use a fan or Victor or Jaguar for everything else.

Camren

22-11-2012, 09:23

So at a recent off season competition our team had tested out the Talons and so I thought I would post a few notes.

- Friday we were practicing with Jags still attached, Saturday with Talons on we noticed a slight speed difference

- The Talons didn't heat up though its debatable to account this since the schedule was light weight

CalTran

22-11-2012, 09:32

Camren

23-11-2012, 11:43

For better or worse speed difference?

For the better

Ether

23-11-2012, 12:07

For the better

Could you please clarify what you mean by a "better speed difference"?

For example:

- faster speed for a given open-loop throttle setting

- more linear response to open-loop throttle commands

- more stable closed-loop speed control

- something else?

Also, did you measure it or is this a subjective judgement of the driver?

Camren

24-11-2012, 11:45

Could you please clarify what you mean by a "better speed difference"?

For example:

- faster speed for a given open-loop throttle setting

- more linear response to open-loop throttle commands

- more stable closed-loop speed control

- something else?

Also, did you measure it or is this a subjective judgement of the driver?

This is a subjective judgement of the driver

- The stability of closed loop control is debatable due to the recent drive train change though open loop control was tested with both the Jags and Talons with the new drive train.

- The speed and agility on carpet with the Talons equaled the speed and agility off carpet with the Jaguars.

- Difference of response time between the two motor controllers were either subtle or not there.

ehfeinberg

05-12-2012, 19:05

Jags have CAN now. Talons will have it later.

When exactly is later? And if we buy Talons now, will they be compatible with CAN once Talons support CAN?

Richard Wallace

05-12-2012, 19:09

When exactly is later?
Mike, do you want to jump in here? You have both the Talon and the 2CAN. When will they start talking to each other?

Ether

05-12-2012, 19:35

if we buy Talons now, will they be compatible with CAN once Talons support CAN?

The present model Talons have only a PWM input. I'm trying to picture how they could "be compatible with" CAN. What did you have in mind? Some sort of CAN-to-PWM interface?

Mike Copioli

06-12-2012, 21:29

Mike, do you want to jump in here? You have both the Talon and the 2CAN. When will they start talking to each other?

The short answer is never. PWM and CAN are two completely different interfaces. PWM is unidirectional(one way) CAN is bidirectional(twoway). PWM is time based measurement, CAN is serialized data over a differential BUS.

The Talon was designed to meet the needs of the majority of users. Since only about 10% of users prefer CAN, it did not make sense for our first release to include the additional features and cost associated with CAN.

Additionally, CAN would increase the footprint of the TALON to accommodate the additional connectors used for the various forms of feed back. In short the decision to withhold CAN functionality from the Talon was mostly business and partly design.

The situation with CAN is a bit paradoxical, we would like to release a CAN enabled version of the TALON, we feel that if we were to correct some of the issues with CAN in FIRST teams would see the benefit and slowly migrate away from PWM and into CAN thus increasing the demand. However, There needs to be a demand in order for us to justify the additional cost and increase in footprint.

This becomes even more challenging with the new reduced pricing. I truly believe that a properly implemented CAN interface is a better solution for FIRST than PWM.

The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon? Second would the increase in footprint make the Talon less desirable for PWM users?

After all it is your support that would make all of this possible. We appreciate your patronage and feedback.

Jon Stratis

06-12-2012, 22:19

Mike, this feels like an area that would require a much longer conversation than I'm willing to type out. I will make a few points, though:

- CAN is a great system, but the current implementation is a little lacking. For example, you can't have a single encoder help control two Jaguars, when the bidirectional communication would seem to allow for that.
- In order for CAN to really become popular, we have to get more than just our speed controllers on it. It's incredibly useful in automotive applications simply because so much stuff is on it and able to talk back and forth.
- In the tradeoff between size and capabilities, I'll always choose capabilities. We've used Jaguars on the drive train since they came out specifically for that reason - the linear response was worth the increased size. Now that the Talon offers a near-identical response at a similar price point, the decreased size is the key differentiator (assuming the capabilities of CAN aren't required).
- To add CAN to the Talon, how big would the footprint get? If it's the size of the Jaguar (for example), then we would need to see some additional capabilities to make it worth purchasing over using our current stock of Jaguars.

I, for one, would absolutely love to see what you could do with CAN!

DonRotolo

07-12-2012, 23:05

I, personally, favor a LIN bus. The ~10kb/s data flow should be enough (but maybe it isn't?), and it is dirt cheap to implement.

Oh, and another data point: If you connect 12 VDC to the output side, and the motor to the input side, the Talon doesn't work properly anymore.:ahh:

Excuse me, I have some students to harass counsel.:rolleyes:

flameout

07-12-2012, 23:13

I, personally, favor a LIN bus. The ~10kb/s data flow should be enough (but maybe it isn't?), and it is dirt cheap to implement.

Not knowing anything about LIN... I'll assume an essentially perfect bit packing for minimal operation.

4 motor controllers * 8 bits/controller/cycle = 312 Hz control

Note that that number goes down if individual addressing is supported, more than 4 controllers are on the bus, more than 8 bits are transmitted (i.e. you're actually using it to gain capabilities not available through PWM -- also, the Talon has 10 bits of output resolution).

I'm not so optimistic that this will be fast enough -- I highly doubt that it would be nearly this efficient.

For running just 1 controller (not the drivetrain), this might be more suitable. I'll look more into the LIN bus.

Edit: It appears the minimum packet size is 5 bytes (there might also be other delays -- I'm just looking at the extreme basics here). That puts the control rate for 1 controller at under 300 Hz... for 2, that's under 150 Hz (and under PWM).

DonRotolo

07-12-2012, 23:26

OK, nevermind. CAN it is....:o

apalrd

07-12-2012, 23:26

Not knowing anything about LIN... I'll assume an essentially perfect bit packing for minimal operation.

4 motor controllers * 8 bits/controller/cycle = 312 Hz control

You don't send 8-bit LIN commands.

http://en.wikipedia.org/wiki/Local_Interconnect_Network (http://en.wikipedia.org/wiki/Local_Interconnect_Network)

LIN, like CAN, is a message based protocol, with generally lower bus speeds than CAN and significantly simpler implementation. Unlike CAN, LIN has a bus master which is in charge of bus arbitration and scheduling. Vehicles generally use it to connect slave IO modules to a central ECU, for example to connect buttons on a steering wheel to a body control module, where the button modules act as LIN slaves. The smarter LIN bus masters are then connected to the full CAN busses, CAN being a faster and master-less bus which is often used for sending many messages very fast.

But, you communicate by sending message frames. Frames consist of various header information fields (including an ID) and 2,4 or 8 bytes of data.

It would be just fine for 50hz motor updates. It's really easy to wire, as it dosen't care about splits or segments and can run at rather long wire lengths (for FRC use) with no issues, it uses a single wire with 12v signal voltage, and is implemented using UART hardware, meaning a simple level shifter is all you need to use the RS-232 port to speak LIN.

Ether

08-12-2012, 10:06

...a simple level shifter is all you need to use the RS-232 port to speak LIN.

An RS-232 port can speak PWM servo signal, too.

http://www.chiefdelphi.com/media/papers/2702

dbarg1

08-12-2012, 13:21

What is the verdict on talon and encoder integration? Do you have to manage the encoders through the cRIO as before? If so, is it impossible to do the kind of speed control that was used with the Jaguars (for large speeds, i.e. fly wheel)?

Phalanx

08-12-2012, 14:20

The situation with CAN is a bit paradoxical, we would like to release a CAN enabled version of the TALON, we feel that if we were to correct some of the issues with CAN in FIRST teams would see the benefit and slowly migrate away from PWM and into CAN thus increasing the demand.

I've been slowly trying to do that over the last few seasons. However, with some of the issues with CAN for FRC as well as the Jaguars(ie.. brownout & forget closed loop configuration) I haven't been able to do that. If those issues could be corrected, I'm in 100%. As I understood it, not many if any teams do BETA testing with CAN, so that alone would help.

This becomes even more challenging with the new reduced pricing. I truly believe that a properly implemented CAN interface is a better solution for FIRST than PWM.

Agreed, CAN is a much more elegant and neater(no more rats nest of pwm wires) solution than PWM. The ability to do asynchronous co-operative processing with controllers over the CAN bus is really awesome. We did some of that this season.

The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon?

I would be willing to pay more for a CAN enabled Talon with a slightly larger footprint. Of course, how big a price difference matters, as well as how much bigger it is. For example, 1.25 - 1.50 times as much, and smaller than a Jaguar I'd be sold on. Again it's something that needs to be thought about as it's a Price/Performance/Value question which is hard to answer right now.

Second would the increase in footprint make the Talon less desirable for PWM users?

We've used the larger Jaguars on our drive system with PWM because we wanted the better linearity of the Jaguar. So for some teams perhaps size matters, it all depends on what their objectives are. Of course now that the Talons have that great linearity too, we'll most likely switch to Talons.

I don't know if this would be viable, but what about 2 different Talon models? A PWM only as is today that has the small footprint and low price point, and a CAN only as an optional model? I don't know if there's enough market for the CAN only model, but it's a thought.

Ether

08-12-2012, 14:41

The ability to do asynchronous co-operative processing with controllers over the CAN bus is really awesome.

Could you please elaborate what is your intended meaning of the phrase "asynchronous co-operative processing with controllers over the CAN bus" ?

Phalanx

08-12-2012, 16:51

What I mean, is exploiting the closed loop functions in the Jaguar which at this time is only available via CAN.

Such that I can send a command(s) on the CAN bus to one or multiple Jaguars running in closed loop mode to perform some function(s) while other code and processing is performed on the CRIO all simultaneously.

For example, if I have 8 Jaguars on the CAN bus, that perform 8 distinct functions that are not tied to one another, I can have 8 different operations happening concurrently, along with what ever other processing I might need on the CRIO.

So, now we've offloaded processing from the CRIO to the Jaguar to achieve a joint task that's (co-operative) processing.

Since these processes can now happen simultaneously and no one process need wait for another they are said to be asynchronous. You could call it parallel processing if you wanted.

You could in theory have the CRIO be relegated a message handling agent, sending messages, reading status, and sending other messages based on status received.

I do stuff like this in my day job.

Gary Dillard

10-12-2012, 10:31

Oh, and another data point: If you connect 12 VDC to the output side, and the motor to the input side, the Talon doesn't work properly anymore.

That doesn't appear to be a discriminator for us; we have performed the same test on a Jaguar before with equivalent results. It was an unsupervised experiment and not in a lab environment but I'm pretty sure it's repeatable. :o

nixiebunny

10-12-2012, 23:24

Thanks for all the fine testing and analysis, folks. I snagged half a dozen Talons through First Choice today. I hope they provide joy. I intend to use them for CIMs, with fan. You'd be crazy to not use a fan if you can use one, as the lifetime of electronics is exponentially increased by cooling it a few degrees.

Having designed a smaller motor controller for underwater stuff, I have long been mystified at the behavior of the Victor 884. I'm under the impression (from reading the CD archives) that it doesn't short the motor winding in the off phase of the PWM cycle. Is this the case, or does it do something else to make it so nonlinear?

Ether

10-12-2012, 23:30

does it do something else to make it so nonlinear?

The nonlinearity of the 884 is largely due to the 150Hz output PWM switching frequency.

Gdeaver

12-12-2012, 08:06

If there is ever a redesign of the Talon board and case, it would be nice if there was a separate plug in for the fan. Stacking the 2 power connectors is irritating.
Not a big deal but would be nice. As to fans, teams just put one on. If there is a problem with the Talon it will probably be thermally related. The cooler the heat sink the better the heat will flow out of the chips. Veteran teams should have a box of 40 20 mm fans from previous years. Just need 2 screws and 2 terminals. Easy.

CalTran

12-12-2012, 08:29

You're going to need to stand the fan off too. The idea is to keep the air circulating, not necessarily draw the heat straight out

Gregor

12-12-2012, 08:32

Looking forward to getting my hands on some Talons. They are being shipped now.

Brian Selle

12-12-2012, 09:47

The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon? Second would the increase in footprint make the Talon less desirable for PWM users?

I'd be wiling to pay $75-100 for a CAN enabled controller but footprint is super important. Something slightly larger than the Victor would be acceptable, the Jag is too big.

kaliken

12-12-2012, 13:05

The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon? Second would the increase in footprint make the Talon less desirable for PWM users?

After all it is your support that would make all of this possible. We appreciate your patronage and feedback.

Seeing this part of the thread made my eyes light up...

As one of the few 10% who use CAN and have been using CAN since our championship year in 2010, I would be all for this.

However its not the interface in which we are looking a rather it is the data and the bidirectional functionality that makes us use Jags. Even though Jags are 'big and fat' compared to the Talon/Victor, the fact that we can pull a ton of telemetry off the Jag plus do a simple PID (a nice addition.) is what separates it from the Victor/Talon. In 2010 we were using current feedback from the Jag to identify if we had a ball or not. Essentially we got a lot more versatility off the Jag/CAN bus other than just commanding motors.

In addition, one interesting thought would be a redundant control path. Since most teams stay away from CAN due to potential reliability problems(only year we had an issue was traced to a 775 case short) What would the prospects be to putting a redundant PWM/CAN interface ie. if CAN messages die, the motor controller can still be controlled via PWM. (disclaimer.. I work in the space industry so redundant paths are usually a must)

Bottom line, if you could put a talon with CAN + similar telemetry data in a better form factor, (even with a larger footprint) I would jumping and singing for joy. Oh yeah also make the hole spacing a nice number!

dcarr

12-12-2012, 13:13

In addition, one interesting thought would be a redundant control path. Since most teams stay away from CAN due to potential reliability problems(only year we had an issue was traced to a 775 case short) What would the prospects be to putting a redundant PWM/CAN interface ie. if CAN messages die, the motor controller can still be controlled via PWM. (disclaimer.. I work in the space industry so redundant paths are usually a must)

That would be really something. The reliability problems are what is prompting our switch away from CAN/Jaguars to Victor 888's for 2013. The amount of time we spent pulling up the 2Can webpage and troubleshooting intermittent connectivity problems was far too great (it's really difficult to know the true source of the issues - it could have been anything from a bad connector, as some of our Jaguars shipped with bent connectors, or something more complex). That's not to diminish the benefits of CAN, but our experience with it was less than ideal.

kenavt

12-12-2012, 16:12

slijin

12-12-2012, 18:16

The short answer is never. PWM and CAN are two completely different interfaces. PWM is unidirectional(one way) CAN is bidirectional(twoway). PWM is time based measurement, CAN is serialized data over a differential BUS.

The Talon was designed to meet the needs of the majority of users. Since only about 10% of users prefer CAN, it did not make sense for our first release to include the additional features and cost associated with CAN.

Additionally, CAN would increase the footprint of the TALON to accommodate the additional connectors used for the various forms of feed back. In short the decision to withhold CAN functionality from the Talon was mostly business and partly design.

The situation with CAN is a bit paradoxical, we would like to release a CAN enabled version of the TALON, we feel that if we were to correct some of the issues with CAN in FIRST teams would see the benefit and slowly migrate away from PWM and into CAN thus increasing the demand. However, There needs to be a demand in order for us to justify the additional cost and increase in footprint.

This becomes even more challenging with the new reduced pricing. I truly believe that a properly implemented CAN interface is a better solution for FIRST than PWM.

The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon? Second would the increase in footprint make the Talon less desirable for PWM users?

After all it is your support that would make all of this possible. We appreciate your patronage and feedback.

We'd probably pay up to $90 for CAN Talons, although we'd buy less of them (4-6), and supplant that with an order for PWM Talons unless CAN Talons were marked down so much that their price was on par with their PWM counterparts.

Some features that I know I'd like to see on the CAN Talon:
- Keep the analog & encoder inputs.
- Redo the limit switch inputs to make them more intuitive and easier to understand for people that aren't on the electrical team.
- Allow controllers to communicate with each other more in-depth; namely, allow sensor input (specifically encoders) to be duplicated (in the CAN) between controllers. This has been a problem whenever teams have Jags on motors that feed into a gearbox that only has one encoder, since the encoder has to be read through the DSC, and then passed to the cRIO and then back to the Jags.
- Allow controllers to double as sensor interfaces - the closed-loop feature of the Jags was nice, but it would've been nicer if we could've read the sensors feeding into the Jags in our code.

Tom Line

12-12-2012, 18:21

Even more so, I agree with this. I don't think it would be very hard to implement in software - correct me if I'm wrong. I know a feature like this would cause us to take a second, very long look at running CAN.

Last time I checked, having dual controls hooked to a speed controller was Illegal, so the rules may need to change as well.

However, I agree 100%. The reason we have never switched to CAN is because of the reliability issues some teams have had. We've Beta tested CAN on our robots with no problem, but right or wrong, I see PWM as a more robust option.

Is there a quick way to troubleshoot CAN, short of plugging in a computer and polling the devices? I.e. - is there a LabVIEW VI for the dashboard that shows each device and it's communication status?

kaliken

12-12-2012, 19:03

Last time I checked, having dual controls hooked to a speed controller was Illegal, so the rules may need to change as well.

However, I agree 100%. The reason we have never switched to CAN is because of the reliability issues some teams have had. We've Beta tested CAN on our robots with no problem, but right or wrong, I see PWM as a more robust option.

Is there a quick way to troubleshoot CAN, short of plugging in a computer and polling the devices? I.e. - is there a LabVIEW VI for the dashboard that shows each device and it's communication status?

Tom,

You are correct with the rules. I agree though that it would be a tweak in the rules. Just as long as they can show good compliance to the robot safety side.

As for the CAN reliability, we have some issues with the CAN bus but not tons. The biggest issues include some of the Jags losing ID's, some 2CAN boot issues. But it is obvious that others have had many more issues. Our Debugging usually consists of rebooting the 2CAN then checking the 2CAN page to verify all the Jags. In my mind CAN is a widely used Bus standard why FIRST cannot make it reliable is beyond me.

- Allow controllers to double as sensor interfaces - the closed-loop feature of the Jags was nice, but it would've been nicer if we could've read the sensors feeding into the Jags in our code.
I really like this idea. It can allow for more seamless data transfer between Jags and or data to the cRio! I am a big proponent of utilizing CAN for sensor/Telemetry data!

kenavt

12-12-2012, 19:36

In my mind CAN is a widely used Bus standard why FIRST cannot make it reliable is beyond me.

Myself and another team programmer were talking to a NI representative at MSC last year - he was going around, doing an informal feedback survey on the control system. We remarked about the reliability of CAN to him. He told us that there was a CAN module for the cRIO (a Google search finds this (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209540), although it doesn't have the same 6p6c connectors on the Jaguars). He said that the way FIRST/WPILib implementation of CAN is done, in terms of hardware, was not well done - whether using 2CAN or the RS232 interface. This seemed to be a standard routine he was giving to people.

apalrd

12-12-2012, 20:16

All my opinions on how CAN should be implemented:

-Speed controller should have a pair of connectors which are easier to wire properly than. I'm not a fan of RJ11's. Some positive locking connector would be nice, but the 3-pin header style would work as well. You could choose to connect through the two connectors, or make your own splice inline (this would help with reliability if a single connection comes out, assuming your splices are well done). The bus really doesn't care about 6" splits.

-Speed controllers should require enable signal to operate, it should be a different and reserved message ID. This should only affect the status of the output and reset the integrals, nothing else (you should still be able to send commands, read sensors, command gains, etc.)

-Software on controller side should be architected to pass CAN messages between the application and the CAN bus, restricting the reserved enable message and sending it itself, but otherwise doing nothing. Also, it seems reasonable for each speed controller to get it's own group of CAN ID's.

-The user software on the controller side should never block-wait for anything, ever.

-Basically, if there are any errors, or a speed controller is disconnected, then you loose only that controller and go on, and it's no worse than where we are when a PWM cable comes out. The CAN cable coming disconnected from the 2can would be like the DC37 connector coming loose, it's a single point of failure that we already have, but it's just one point and not a point at every speed controller that can kill the entire bus.

I really do like CAN, just not the way it's implemented now.

I read over the LV implementation and I was really really really really horrified by some of the things they did. It block-waits for an Ack every time it sets a motor speed! For every motor! *gasp* Why should it care if the motor got it if it's going to send the motor something else in 10ms? If it times out at 10ms, and you have two motor controllers off-bus, then you will use up all of the 20ms loop interval waiting for two controllers to Ack when they will never Ack, and when you loose 5, then you've already missed two loops just waiting for controllers to never send you stuff! This is why blocking waits are bad!

Joe Ross

12-12-2012, 20:38

I read over the LV implementation and I was really really really really horrified by some of the things they did. It block-waits for an Ack every time it sets a motor speed! For every motor! *gasp* Why should it care if the motor got it if it's going to send the motor something else in 10ms? If it times out at 10ms, and you have two motor controllers off-bus, then you will use up all of the 20ms loop interval waiting for two controllers to Ack when they will never Ack, and when you loose 5, then you've already missed two loops just waiting for controllers to never send you stuff! This is why blocking waits are bad!

The 2012 LabVIEW CAN Library implemented an isochronous mode. It does not block, but also doesn't look for the Ack. It's designed for sending periodic updates where you don't care if a particular message is received. There's a boolean input for whether you want isochronous or blocking.

apalrd

12-12-2012, 20:43

Did you mean busy-wait ?

Block wait.

The Netcomm library (black box compiled code) includes a Read and Read Async function.

Read is fed a message ID and timeout, and returns either 8 data bytes or failure after no more than timeout. So, the function is blocking.

Read Async is fed a message ID and Occurrence. The VI then does a Wait On Occurrence with timeout specified, if the Occurrence is triggered then it calls another function to retrieve the data. This function is not blocking at a Netcomm level, but is blocking at a system library level (Lower than the exposed CAN message interface is the Netcomm interface which is used by the CAN message interface).

Since WPIlib generally pushes teams to put all of their code in Teleop or Timed Tasks, putting a blocking read command in Teleop and having it fail is very bad for deterministic Teleop timing (which is already really jittery because it's timed by Ethernet packets). It gets even worse with multiple jags, or multiple commands per jag (e.g. Set Speed and Get Current would both block-wait, if that jag goes offline then there's 20ms of timeouts just for that one jag to be waited through by the user code).

Basically, all of the CAN send-response interactions are all synchronous, which is a huge time penalty over an asynchronous architecture if it ever has to wait for a response and dosen't get it.

apalrd

12-12-2012, 20:55

The 2012 LabVIEW CAN Library implemented an isochronous mode. It does not block, but also doesn't look for the Ack. It's designed for sending periodic updates where you don't care if a particular message is received. There's a boolean input for whether you want isochronous or blocking.

I see the isochronous mode for the Motor Control Set, but nothing else.
I also see that Read Status sets a timeout of 0 for messages continually transmitted, but could also do a transaction (with 10ms timeout) if requesting something on-demand.

Everything else is still blocking (set parameters require Ack, read parameters are synchronous).

Really, CAN is designed to never care if a message is received, and to transmit everything continuously (with less important information at a slower rate). Having an Ack message makes no sense to me.

Edit: Motor Set defaults to synchronous mode, and the Isochronous input is not in the help. I'm guessing many teams still run in synchronous mode. It should default to isochronous mode, IMO.

Joe Ross

12-12-2012, 23:51

Is it possible to revert a Talon to factory calibration?

Mike Copioli

14-12-2012, 15:17

Is it possible to revert a Talon to factory calibration?

No it is not.

Ether

14-12-2012, 15:33

No it is not.

Mike, could it be done with a PWM signal generator which generates a known pulse width accurate to 0.001 ms ?

Tom Line

14-12-2012, 15:55

F22Rapture

15-12-2012, 00:33

Mike, our last Beta update included a new class for the Victor 888's. I haven't seen one for the Talon yet.

Is one going to be released? If not, what's the recommended class to use? We haven't had any problems using the victor class with it at all.

We're not in the beta, but I changed my plugin source to the beta channel to ensure compatibility with older code, and as per today's update:

http://i.imm.io/P9Qw.png

Tom Line

15-12-2012, 15:17

We're not in the beta, but I changed my plugin source to the beta channel to ensure compatibility with older code, and as per today's update:

http://i.imm.io/P9Qw.png

Figures. We're now one update behind because we had our seminar and didn't want to break our code by updating a day or two before the seminar. It's probably in there.

Mike Copioli

16-12-2012, 09:40

Mike, could it be done with a PWM signal generator which generates a known pulse width accurate to 0.001 ms ?

No. Joe's questions was regarding factory calibration. These settings are what the firmware saves to flash when the Talon is first programmed. These settings are over written once the user performs a successful calibration.

A user calibration could be performed to obtain values that are are close or even the same as what's saved during initial programming. But there would be no way for the user to confirm this.

We did not feel the ability to restore factory calibration was necessary since the procedure would not be much different than performing a user calibration. And a user calibration will yield the best performance.

nerdherdmember

18-12-2012, 12:10

FRC 422 just received the first 8 of our Talons! They are far smaller than we imagined them to be.

CalTran

18-12-2012, 14:40

Team 2410 put four on our mecanum demo robot and man do they drive like a beauty! Makes driving off of our app so much smoother and easier. Me gusta mucho.

Ether

18-12-2012, 15:20

Makes driving off of our app so much smoother and easier.

Compared to what? (also, what does "off of our app" mean?)

CalTran

18-12-2012, 15:29

Compared to what? (also, what does "off of our app" mean?)

Compared to previously having 4 victors. Off our app means we put one of the robot open shields on it and one of our programmers wrote an app too driver the demo bot off a phone with

Ether

18-12-2012, 15:34

Compared to previously having 4 victors. Off our app means we put one of the robot open shields on it and one of our programmers wrote an app too driver the demo bot off a phone with

Were you driving the Victors "off the app" too? ... so that you were comparing apples to apples?

CalTran

18-12-2012, 15:37

Yeah we were driving the Victors off the app as well. The Talons just seemed more responsive. I will admit it was not a blind study so maybe its just the hyper behind the Talons that makes it seem so

Ether

18-12-2012, 15:48

Yeah we were driving the Victors off the app as well. The Talons just seemed more responsive. I will admit it was not a blind study so maybe its just the hyper behind the Talons that makes it seem so

I'm thinking it's probably the linearity of the Talons which made the difference you noticed.

But as you said, it would be most interesting to conduct a blind study.

CalTran

18-12-2012, 16:07

I'm thinking it's probably the linearity of the Talons which made the difference you noticed.

But as you said, it would be most interesting to conduct a blind study.

That'd be what, set up a few identical drivebases and make it "impossible" to see into what controllers are on them, then have a drive drive the three and rank how well they handle?

Jon Stratis

18-12-2012, 16:23

That'd be what, set up a few identical drivebases and make it "impossible" to see into what controllers are on them, then have a drive drive the three and rank how well they handle?

To save parts and ensure there are no mechanical differences, I would use the same drive base. Build a simple electrical board for it, but leave off the speed controllers. Put the speed controllers into separate boxes (even cardboard boxes would do for this), with a wiring harness coming out of it (wired up the same way for each case, so controlling the motors is identical). Close the boxes. Strap each one onto the robot sequentially, and hook up the wiring harness. Drive it around, and do an evaluation. Take the next box, and repeat.

For best results, use 3 identical boxes. After it's built, have someone randomly shuffle the boxes, then number them as you use them. That way, you won't know which is which until after your evaluation, when you open them up and compare the number to whats inside!