REV Sparks or Vex Victor 888?

[Jared Russell]

I wouldn't dismiss CAN outright in 2016. Many of the horror stories happened years ago, when the *rio CAN software stack was less mature, CAN speed controllers were less mature, termination resistors were not built into the control system, high quality FRC-oriented reference material was not available, and a trustworthy vendor like CTRE was not yet staking its reputation on a working CAN solution.

All those things have changed since 2012, and many teams ran CAN-only control systems successfully in 2015. As a result, this is the first season that CAN is a viable option for 254.

[Richard Wallace]

Originally Posted by Jared Russell

I wouldn't dismiss CAN outright in 2016.

..., this is the first season that CAN is a viable option for 254.

This speaks volumes.

[wireties]

We stayed away from CAN for a long time because of the reliability stories on CD. But last year we went all in with 9 Talon SRX controllers. They work as advertised, we were quite pleased.

[Abrakadabra]

In 2015, 3467 also went whole hog with the Talon SRX - we used one running the built-in Speed Control mode for each of our four mecanum wheels, and two (1 master, one slave) for driving our elevator with Positional PID. One of our mentors insisted that the built-in PID algorithm could be faster (he was looking more for a motion-control mode), but it all worked well enough with a minimum of muss or fuss.

Plus - One of the often overlooked advantages of CAN control is built-in current sensing on each motor - granted it wasn't really that useful last year (unless maybe when we were building a twelve stack , but in a defense-heavy game, or a game where climbing might be required, being able to monitor current at the individual motor level might help to intelligently avoid those brown-out conditions that we were all worrying about around this time last year.

[Ari423]

Originally Posted by Abrakadabra

Plus - One of the often overlooked advantages of CAN control is built-in current sensing on each motor - granted it wasn't really that useful last year (unless maybe when we were building a twelve stack , but in a defense-heavy game, or a game where climbing might be required, being able to monitor current at the individual motor level might help to intelligently avoid those brown-out conditions that we were all worrying about around this time last year.

Can't you do the same thing with one CAN run from the RoboRIO to the PDP? The CAN line would even have built-in termination at the PDP. No need for fancy CAN motor controllers if all you need is simple voltage control, and you can still have your current monitoring.

[Abrakadabra]

Originally Posted by Ari423

Can't you do the same thing with one CAN run from the RoboRIO to the PDP? The CAN line would even have built-in termination at the PDP. No need for fancy CAN motor controllers if all you need is simple voltage control, and you can still have your current monitoring.

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

[Ben Wolsieffer]

Originally Posted by Abrakadabra

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

The PDP allows you to monitor the current draw on each output (not just the total), so you can still achieve current control with PWM.

[Ari423]

Originally Posted by Abrakadabra

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

Actually with the new PDP you can get current draws for each power output. So as long as each motor controller is wired 1:1 with a power output on the PDP (which it should be according to 2015 rules), you can get the current draw from each motor.

See documentation here: http://www.ctr-electronics.com/contr...ription_tabbed

The Power Distribution Panel (PDP) is the latest DC power interface for competition robotics. The PDP uses CAN to connect directly to the roboRIO and allows for individual current monitoring on each channel.

EDIT: sniped

[Abrakadabra]

Originally Posted by Ari423

Actually with the new PDP you can get current draws for each power output. So as long as each motor controller is wired 1:1 with a power output on the PDP (which it should be according to 2015 rules), you can get the current draw from each motor.

See documentation here: http://www.ctr-electronics.com/contr...ription_tabbed


EDIT: sniped

OK - thanks. I forgot about that feature. But in my defense, it's still CAN that makes it all possible.

As a mentor whose teams have used CAN beginning way back in 2009 when the Jags first came on the scene, I guess I had gotten used to promoting the current sensing feature of the CAN controllers a little too much. In 2012, when the bugs in the CAN stack and the unreliability of the RJ-11 connectors became too much to handle, I was sorry to see that particular feature go. So when CAN looked like it was going to be viable once again last year, I was ready and willing to give it another go, and I, for one, am glad we did.