New Talon Speed Controller

[Richard Wallace]

Originally Posted by ehfeinberg

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]

Originally Posted by ehfeinberg

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]

Originally Posted by Richard Wallace

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]

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]

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.

Excuse me, I have some students to harass counsel.

[flameout]

Originally Posted by DonRotolo

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]

OK, nevermind. CAN it is....

[apalrd]

Originally Posted by flameout

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

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]

Originally Posted by apalrd

...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]

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]

Originally Posted by Mike Copioli

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.

Originally Posted by Mike Copioli

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.

Originally Posted by Mike Copioli

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.

Originally Posted by Mike Copioli

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]

Originally Posted by Phalanx

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]

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]

Originally Posted by DonRotolo

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.

[nixiebunny]

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?