What is CAN?...

[NyCityKId]

So I've been hearing a lot about CAN lately but I'm not sure what it is. I know it has something to do with the jaguars but I dont know exactly what it does. If anyone is willing to give me a full or semi-full description of CAN I would greatly appreciate it. I'm going to spend my summer learning LabVIEW and a a little C++ (since my team mostly programs in LabVIEW as of now), so it would be very helpful if i actually understood the basics of CAN.

Thanks in advance to all the responders,
Andre Dunkley

[Zholl]

I asked one of our programmers the same thing. basically, he described it as an output bus that allows you to daisy chain your speed controllers to one output port with phone cables. then it just sends signals which get forwarded on to the next controller in line until it reaches the desired controller.

other than that, the best I can do is to point you in the direction of wikipedia

[David Brinza]

CAN is a low-speed (<1 Mbps) serial bus that is used primarily in newer automobiles, but also in other imbedded applications (including FRC robots). CAN provides a simple, standardized communications interface between the cRIO and Jaguar speed controllers.

The advantage of using CAN in FRC robots is not just the simplified (daisy-chain) wiring, rather it is access to the intelligence provided within the Jaguar controllers. The FRC controls architecture allows PID control to be distributed to individual motor controllers. Speed, position, current (torque) control can be off-loaded from the cRIO to Jaguars with feedback sensors (encoders, potentiometers, etc.) directly connected to the Jaguars. I suspect this advantage will be more widely recognized and utilized by FRC teams next year.

[biojae]

What I can tell you about CAN from experience is, the Wizard (My team's robot) wouldn't be the same without CAN.

The current sensing abilities of the jaguar are invaluable.

- Before ship we used it to determine how much current was used going over the bump (70 amps per side! and that was in low gear!). Because we were able to see that we were pulling way too much current, we ordered new sprockets to increase the torque output, and thus lower the current needed.

- In autonomous, we use the current sensing ability to good use in our ball magnet. The ball slows down the roller, thus increasing the current draw, which signals the bot to go into its next state in its FSM

- Our kicker's quadrature encoder is sometimes finicky after kicking (loses counts, or something). The current draw is checked to look for a stall, if it is then abort the kick and return. This has saved us from some penalties for extending past the frame for more then 2 seconds.

Then there is the PID control feature for encoders.
Using the position control mode, in auto the FSM just tells each side how far to go, then the Jags go there (unless preempted by the roller state).

Using the Speed control mode, in tele mode the driver's stick is no longer a % voltage, instead it is a % of full speed. So, what that means is if you get into a pushing match, for example, the driver doesn't have to move the stick any further then it already is. The bot will automagically start to apply more power until the obstacle is cleared.

Could all of this been done without CAN? Sure, but it would have required more electrical hardware (4 current sensors and a better encoder) and more software robot side ( PID controllers for speed, and distance)

[NyCityKId]

Okay, I think I'm starting to see how this works. But tell me more about the physical aspects of how this system works. How does it connect to the cRIO? How does it connect to other jags? And lastly, where do the sensors connect to? (I think David sort-of explained how it's done, but I just want to be sure...).

By the way. I'm sure some of this information that I'm asking about can be found out by working with the robot, but the season is over for my team so i really wont get a lot of hands on time with the robot.

Once again thanks to all, this has been really helpful.

[Zholl]

I don't recognize the cRIO module it's hooked up to, but here's a picture of a demo setup. it looks like it has to use a serial adapter to connect to the module as well. Digital sensor inputs are plugged into the digital sidecar, and analog sensors are plugged into the analog breakouts on the cRIO (assuming I'm reading this diagram correctly).

[Vikesrock]

Originally Posted by Zholl

I don't recognize the cRIO module it's hooked up to, but here's a picture of a demo setup. it looks like it has to use a serial adapter to connect to the module as well. Digital sensor inputs are plugged into the digital sidecar, and analog sensors are plugged into the analog breakouts on the cRIO (assuming I'm reading this diagram correctly).

There were two legal ways to use the CAN bus in FRC this year. One is by connecting from the serial port on the cRIO to a Black Jaguar which acts as a serial-to-CAN bridge. From the Black Jaguar you then daisy chain each successive jaguar (black or tan) together.

The other way is to use the 2CAN Ethernet-to-CAN adapter plugged into Ethernet port 2 of the cRIO. Then the 2Can is the start of the chain instead of a Black Jaguar and you daisy chain from it to either black or tan Jaguars.

If you want to take advantage of the onboard PID functionality of the Jaguars, you connect the sensors to the sensor inputs on the Jaguars themselves.

[NyCityKId]

ok i think i understand the basics if can. the pic was really helpful, not to mention the thread that went along with it. (i am officially all CAN-ed out for the day after readiung that thread -_-...)

thanks for the info guys

[biojae]

The only thing to look out for when running CAN, is to handle your exceptions VERY well.
If you lose a CAN Jaguar (Smoke, fuse, etc.), and don't handle its loss in the code then the library will throw an exception that will crash the main thread (ie. the one that communicates with the DS)

So, if you happen to lose a jag in auto for example, then you don't have a tele.
Where if the same thing happened on PWM, you would only be crippled for that motor the JAG controlled not the whole bot.

Handle Exceptions!

[NyCityKId]

Originally Posted by biojae

The only thing to look out for when running CAN, is to handle your exceptions VERY well.
If you lose a CAN Jaguar (Smoke, fuse, etc.), and don't handle its loss in the code then the library will throw an exception that will crash the main thread (ie. the one that communicates with the DS)

So, if you happen to lose a jag in auto for example, then you don't have a tele.
Where if the same thing happened on PWM, you would only be crippled for that motor the JAG controlled not the whole bot.

Handle Exceptions!

Is this concerning LabVIEW?

Either way I'm a little lost as to what an exception is. I currently don't have a copy of LabVIEW (due to miscommunication and lack of reading the manual, it was generally accepted that there was a limited number of licences per team...so i wasn't allowed to bring it home and play with it), so when i get back to school on Wednesday (NYC is on spring break ) I'll get the disc from my mentor. I'll probably be back around Friday to discuss these exceptions more.

[biojae]

This is mostly referring to C++ and Java.
I only know a little about Labview's error handling, but what would happen when an error occurs (Lose a jag, etc.) is an error condition other then "OK" would be returned from the VI.
If not handled, it may crash the program (Not quite sure how labview handles un-handled errors )

[NyCityKId]

Based on my meager, almost insignificant knowledge of LabVIEW I'm going to say that if LabVIEW encounters an error it will may stop the entire code. But as far as I know (and again I'm probably wrong) LabVIEW wont execute anything unless you tell it to.

[Radical Pi]

Originally Posted by biojae

This is mostly referring to C++ and Java.
I only know a little about Labview's error handling, but what would happen when an error occurs (Lose a jag, etc.) is an error condition other then "OK" would be returned from the VI.
If not handled, it may crash the program (Not quite sure how labview handles un-handled errors )

It's not actually a crash that happens (in C), just a flood of errors on the console. If enough die at the same time then the usual symptom is a very noticeable lag in the controls (had fun trying to figure out why the kicker took forever to respond when the drive breakers were pulled )

[biojae]

Well, then it's mostly a java issue then.

Java aborts the current thread if an unhandled exception propagates through all of the calling code to the top of the stack and is not caught.

The CAN error is a runtime exception (UncleanStatusException) and will kill the main class if not caught

[Radical Pi]

Yeah, the C++ code error handling is just an assert that prints to the console then returns from the function. As useful as the print to console is though, I'm almost ready to rip out every single printf from the WPILib