New Talon Speed Controller

[Ether]

Originally Posted by nixiebunny

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]

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]

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]

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

[Brian Selle]

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

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

Originally Posted by kaliken

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]

Originally Posted by kaliken

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)

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.

[slijin]

Originally Posted by Mike Copioli

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]

Originally Posted by kenavt

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]

Originally Posted by Tom Line

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.

Originally Posted by slijin

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

Originally Posted by kaliken

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

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]

Originally Posted by apalrd

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]

Originally Posted by Ether

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.