Serial to CAN Gateway in new Black Jaguars?

It appears that the new Black Jaguar Motor Controllers are capable of interfacing with either a standard serial port at at bit rate of 115.2 kbps, or a Controller Area Network (CAN) interface. See the data sheet available at: (don’t bother to register, just select “OPTIONS”). It seems that the Black Jaguar can act as a Serial to CAN gateway to all of the motor controllers in the system. This implies that a single serial port on the cRIO will be able to control all of the motors on the robot, getting rid of the pesky requirement for a $1000 CAN interface module on the cRIO. It also implies that a single Black Jaguar in the system can act as a CAN gateway to all of the older Tan Jaguars that we already have. This will give us access to to motor current and voltage, and the built in quadrature encoders. In the data sheet it actually says that the Black Jaguar “Directly interfaces to a PC serial port or National Instruments cRIO”.

My question is to those cRIO people out there: Do we have access to the serial port on the cRIO, or is already being used for some other function (debugging or diagnostics) in the system?

If the serial port is available, I see no reason why everyone shouldn’t be using the CAN interface this year.


In following the beta forums(as a team that helped out as part of one of the teams that was part of the labview beta and not a hardware beta test team) it sounded like the cRIO serial port is the planned way of interfacing with the new Jags and then the new jag would act like a bridge to the old jags. as of right now the serial port is only being used for diagnostic data if i understand correctly.

Again the thing to always keep in mind is that just because it is being tested as part of the beta this year doesn’t mean that the GDC will actually allow the use of CAN for the competition this year.

Please anyone else please pipe up and correct me if i’m wrong on this.

The First forum has a couple threads discussing this. Note the comment about the can being run in untrusted mode requiring a PWM cable and can cable to each jag. Also of concern is that Digikey only has about 1000 black jags. With veteran teams only getting 2 in the kit, If every team ordered 2 jags then there would be a supply problem.

Could you give me a link to the posts on FIRST forums? I couldn’t get anywhere searching “CAN”, “Jaguar” or “untrusted”. Thanks! Also, keep in mind, only one Black Jaguar would be necessary per robot to act as a Gateway to last year’s CAN enabled TAN Jaguars. Digikey currently has 780 Black Jaguars (MDL-BDC24) in stock.

One more quick observation - the Black Jaguar CAN gateway makes the 2CAN Ethernet to CAN converter a more expensive solution than just purchasing a DB-9 female to RJ-11 adapter ( and using the serial ports to run/monitor the motor controllers.

d et al,
Remember that although the jaguars had CAN last year, the rules did not yet allow it to be used. Please hold your ideas until kickoff when you will know for sure.
From a personal standpoint, a daisy chain loop of control signals does provide a single point failure for all/most/some robot function.

Also, remember that the Jaguar is a piece of TI’s advertising strategy. Professional Electrical Engineers can use the Jag as a “getting started” evaluation kit for ARM core that powers it. Therefore, it is in TI’s best interest to cram as much awesome as possible into it, even if the GDC doesn’t want to enable the awesome.

The 2CAN has a couple of cool features that a serial enabled black Jag doesn’t. It will be up to teams to decide whether or not they justify the cost.

We all have to wait to see what the rules allow, but I’m certainly excited.

*EDIT: Like bandwidth!

TI’s purchasing Luminary Micro never has made a whole lot of sense to me. It’s not like TI didn’t have the expertise to license the ARM core and program it themselves. I think that they are more focused on the power MOSFETs which is probably the largest part of the real cost of the Jaguar controller, rather than the microcontroller and associated programming.

That being said, they do make a big deal about the serial enabled nature of the Black Jag in the literature developed specifically for FIRST. I think that I’ll buy a couple and the DB-9 to RJ11’s and have one of my team members investigate the interface just on a hunch.

Thanks for everyone’s input.

It sounds like you think TI acquired LMI for the purposes of Jaguar. It didn’t. TI’s acquisition of LMI was for all of the microcontrollers (MCUs) that LMI developed and were selling (plus the eval kits plus the software that accompanied the eval kits, etc.). TI acquired a catalog MCU business that complements their existing MCU offerings (C2000 and MSP430).

The Jaguar speed controller is a design example of how to use one of the MCUs in a brushed DC motor control application.

Luminary doesn’t own the ARM processor. ARM does:

I could license the core and (with enough funding) become a fabless production house tomorrow. TI wants to sell silicon and the best way to do that is MOSFETs.

No sense in buying a processor that they will have to license through ARM anyway. imho.

Does the Jaguar RJ-11 port speak RS232? I thought those were CAN ports; CAN protocol is not compatible with RS232 on several levels without some intelligence in-between.

Am I misunderstanding something here (I frequently do)?

One of the two RJ11 ports has speaks RS232 on two of the previously-unused lines. Therefore, that port can either extend the CAN chain, or act as a bridge.

Looking at a new black plastic Jaguar from the front (connectors) the right connector is 6P4C and is for CAN only and the left connector is 6P6C and is for CAN and RS232. The inner four contacts on both connectors are the exact same. The outer two contacts on the left connector are RS232.

On a grey plastic Jaguar, both connectors are 6P4C and are CAN only.

You can find semi-full descriptions of the new CAN and how it is used on the First Beta Forums here:

This is one of the things the first teams have been beta testing: you will find forum posts, presentations, and descriptions on how they work.

Sounds like a done deal. I’ll bet that there is one of these in the KOP:

As well as some of these:

Communications protocol is here:

As far as CAN being a liability because of single point failure (as opposed to independent PWM line), I’m sure that no one has built in redundant motors so the net result on a cable failure would be the same between CAN and PWM.

Good thing about CAN is that you can monitor motor voltage and current and hence computing a running energy expenditure tally would be quite simple.

Energy = PowerTime = VoltageCurrent*Time

Suggesting that this year’s game may be about keeping track/minimizing energy resources in pursuit of a more general goal. This allows FIRST take a quantum leap in relevance.

This depends on what motor is connected to the controller with the failed cable. If a drive motor PWM fails, odds are it’s the same, but if a manipulator PWM fails then the robot could still drive with PWM, but with CAN you’re dead in the water.

Actually, there are some very significant differences between the failures. If you lose a PWM cable used in the traditional configuration (and honesty, there are probably very few teams that have NOT had a PWM that came loose or someone forgot to plug back in at one point or another), at most you lose one motor. In almost every case, the robot is still operable, although with reduced functionality. If you lose a CANbus cable, or have a single device at the head end of the bus catastrophically fail, you can lose access to every motor connected to the bus.

The risks associated with these two options are substantially different. Whether the risk profile is a reasonable trade given the benefits that come with the use of a CANbus configuration is something that each team will have to assess for themselves. Based on your tolerance for risk and your ability to take advantage of the added capabilities of CAN, this trade-off may or may not make sense (personally, I think that for most teams it certainly will make sense, and I would expect to see a lot of teams using the CANbus configurations this year - they just need to understand the risks of doing so).


You can also add fault tolerance in you code/wiring, and with the flip of a switch go from CAN to PWM as a fail safe mode.

I’m not sure it will be quite that easy - no one except the can-beta teams have played with the CAN code that has been written for this year.

In addition, remember that CAN will not be officially supported (even if it IS legal to use).

I believe that the serial-CAN implementation does not allow on the fly choice of Can or PWM. The PWM cable provides a heart beat since the jags are operating in untrusted mode. Also my understanding is that there is a different C-RIO FPGA image for can vs PWM control. There are some good threads on Chief Delphi and the First Beta forum on the CAN situation. Also, Luminary Micros have documentation that can be downloaded. 1 week to go until the kick off. Much should be reveled then. In the mean time if a team is considering using CAN, do some homework now. If the serial rate is 115k then there could be update rate concerns especially if there are many jags on the bus. It’s not the bit rate alone, Have to consider latency issues. I can remember Dave giving a warning about serialized communications last year when the new controller was being speculated on. I would definitely head his warnings. The serial and Ethernet Can solutions both allow experimentation with out the C-RIO and the driver station by directly communicating with a PC. This brings up safety concerns because there is no E-STOP button in the loop. BE SAFE.