In our short experience of working with CAN, we have seen many problems and solved them. However, this is a problem that we cannot overcome: jaguars not connecting to the BDC-COMM. We are able to open them and see the initial screen before you enumerate a jaguar. However, whenever we clicked enumerate, it did not respond. This laptop had worked previously in configuring 4 daisy-chained jaguars on our mock-up robot, but this one does not work. Some of the jaguars have different lights when it is on. Any ideas on how to fix this problem?
Note: All of these jaguars are black and have worked previously with the PWM system.
We’ve built 5-6 robots, prototypes, rigs using CAN, and to this day I still never expect to be able to communicate with all my CAN Jaguars on the first try.
Here’s my CAN shortlist, in order of frequency:
bad crimp on cable
bad crimp on termination resistor
resistor lead shorted inside crimp connector
resistor lead shorted inside CAN-Serial adapter
absence of termination resistor
accidentally crossed wires on cable
wrong pinout in CAN-Serial adapter
not 6 wire cable from CAN-Serial adapter to 1st Jag
bad conductor in cable
bent/broken contact in CAN Socket on Jaguar
connectors loose, tabs not opened up enough to “click”
Patience, and two students who knows their way around a digital multimeter are key.
It sounds like you have a lot of experience with CAN. In your opinion is it reliable enough for competition? Were the issues only after the initial wiring and test? Or are these the type of things that will plague you on the field?
Mr. Lim suggests some good things to check. Follow the list and you should find your problem.
We’ve used CAN for a couple of years now and despite some weird problems that we run into, it is pretty dependable. More often, the Jags are the limitation, not the CAN bus itself.
Some issues to consider (CAN only potential problems):
When using a Jaguar in a closed loop mode (speed, position, current), if the Jaguar shuts down for whatever reason (overheating, overloading, tripped circuit breaker) it will reboot in open loop voltage control mode. It will then ignore any closed loop command signals you send it because it is looking for voltage commands.
Jags in general seem to be more susceptible to FOD (foreign object damage) such as metal shavings and such. You must be VERY careful.
If cables are made poorly, you can get intermittent connections - however this is not limited to CAN.
One really NASTY one to consider is that you can’t really pull the breaker on a CAN jag, you must disconnect the motor instead. The reason for this is that the CAN bus is a large network. Each Jaguar has its own address (0-63). ALL the devices on the CAN network see the same data, but each device ignores any commands that aren’t meant for it. The code in the cRIO sends a packet(command) and expects to hear back from that Jaguar. If you pull the breaker on the Jag, the cRIO code will keep trying to contact the Jag and will send a bunch of errors to the NetConsole. Get enough of these errors and the whole robot will do some funny things (because the FRC program can’t execute fast enough). Also, the same issue applies with losing power to closed loop controlled Jags above.
That being said, if you don’t have any reason to use CAN other than it reduces wiring, I wouldn’t waste the effort. However, if you need to use closed loop modes, synchronous updates (updating all Jags simultaneously) or you just can’t get over how pretty the black Jags are then the effort may be worth it.
Bryce
P.S. I don’t mean to scare you away. :yikes: I just want to make you aware.
I would like to elaborate on this. You are correct that whenever the Jag reboots/resets (usually after a brown-out or a power cycle) all parameters and running modes are reset to default (voltage mode) except for the ID. However, overheating and over current won’t necessarily reset the Jaguar. The Jaguar will go into a fault mode and shut off the outputs for a few seconds (to attempt to alleviate the problem) and then pick up right where it left off.
That being said, it is definitely possible for an over current condition to happen so fast that the Jaguar can’t fault in time. The current spike can dip the supply voltage so much that the Jaguar browns out and therefore resets.
True dat. In 2010 we had a coupled four wheel swerve drive system, however our modules couldn’t continuously rotate, they were limited to about 270 degrees of rotation in each direction. So when the modules reached their rotational limit in one direction, they would quickly spin 180 degrees in the other direction and reverse the wheel rotation. Well, the current spike from hard switching the directions of five Jaguars simultaneously created a voltage dip that caused the Jags to reset (including the position Jag). The open loop Jags (one per wheel) would come back, but the position Jag was dead for the rest of the match (at that time you couldn’t change or reset control modes for a Jag).
So we painfully found the limits of the Jags that year (and it was daunting for the longest time). We corrected it by rate limiting the Jag outputs (now this can be done autoMAGICALLY in the current firmware).
NOW, THAT BEING SAID: Most people will not run into this situation. Normally, the Jags are driven by a joystick like input so that even though there is no software rate limiting, there is inherent rate limiting because you can’t move the joystick fast enough to go from full out forward to full out reverse.
If anyone DOES happen to run into a similar situation, enable rating limiting.
Glad you found a solution. Jaguar has had the ability to set an output ramp rate since the beginning.
The new feature you’re talking about, the Automatic Ramp Mode, allows teams to activate this output ramp rate without having to send CAN commands (by turning the limit switch jumpers 90 degrees). This is helpful for teams not using CAN or teams that need a quick fix without having to rewrite code (CAN or PWM). See the documentation at www.ti.com/jaguar for more info on this mode.
Note: The output ramp setting is only used by voltage control mode. In the closed-loop modes the output is dictated by the PID algorithm inside of Jaguar. Your solution (a good solution :)) limits the rate of change on the setpoint commands rather than the rate of change of the Jaguar output.
We are encountering a new problem. Now that all of Mr. Lim’s suggestions did not work for us, I decided to reinstall the Prolific driver for the USB to Serial port, and now the BDC-COMM says that there are no COMM ports detected. This is strange since in the Device Manager there is a COMM port. Any more ideas to solve this problem?
EDIT: Solved it, never mind. We still have the initial problems stated at the top.
Oh boy. I’ll just not mention this to our head coder since he was the one who had to deal with this :). I can’t believe I missed that one. I don’t remember seeing any function calls to set this up. Thanks for the info.
One thing to check is that the cable is made correctly. If you were to straighten the cable, the connector tabs would be on opposite sides. This is a minor detail that can go overlooked, but is VERY important.
We have had issues like this from last year and this one. We discovered that it is very easy to mess up a terminator and/or CAN cables. One way to check this (though you may have already) is to check each individual cable with a multimeter, along with the terminator. If that doesn’t work, open the jags and check inside for dust or metal shavings, those messed up ours a lot last year. Use a pneumatic hose to blow the gunk off. Lastly, are you connecting to the computer using jag–serial, or jag–serial–USB? Ours will not allow us to use USB because we were using a school desktop computer, which requires admin log-in to use, but works fine for serial. Anyways, good luck, and I hope you find the solution!