Disadvantages to CAN?

[zbrozek]

I spent some time at this evening's meeting fiddling with the black Jaguar motor controllers. It didn't take long to get a handful of controllers operational on a bus, all running firmware 107. At first blush it seems too good to be true: current-control, locking connectors, daisy chaining, and telemetry.

With any luck I'll convince the team to use the black Jaguars to current-control the main drive motors.

I'm a new mentor and have limited experience with the various flavors of allowed hardware and their permitted configurations. Is there any reason why I should be cautious about CAN-connected black Jaguars?

[Levansic]

We've used CAN networked Jaguars for the last few years, and are planning the same this year. The biggest frustration we have had was the unreliability of the daisy-chain topology.

The locking RJ connectors will give you warm fuzzies on the bench, but they are devious devils on the field. We addressed this by changing the topology to a star, and using 6P6C pugs to minimize wiggling problems. Also, we keep a set of dental picks handy to "fix" the contact wires within the Jaguar jacks.

It is telling that the 2015 controller uses a two position wago-type wire clamping jack for the CAN-high and CAN-low wires. Hindsight being what it is, I wish the Jaguar was designed with the same arrangement.

One other thing to pay attention to, is the fact that Jaguars are little computers on their own. When the voltage drops too low, like when a few CIM's stall, they reboot. If you are using any closed loop control, this will be flushed, and the default voltage control will be what you will come back to. You have to devise your own recovery code to restore the mode and parameters, unless you are just using the default mode.

--Len

[Mr. Lim]

One other thing to pay attention to, is the fact that Jaguars are little computers on their own. When the voltage drops too low, like when a few CIM's stall, they reboot. If you are using any closed loop control, this will be flushed, and the default voltage control will be what you will come back to. You have to devise your own recovery code to restore the mode and parameters, unless you are just using the default mode.


This was the biggest challenge for us in using CAN Jaguars on our competition robot.

In normal match conditions, you WILL experience CANTimeoutExceptions due to voltage drop.

You need to handle these exceptions, but also be VERY careful about how you handle them. Trying to simultaneously recover multiple browned-out Jaguars by re-sending configuration commands too quickly can cause even more problems.

It is very possible to flood your CAN bandwidth, and cause the entire chain to become unresponsive / laggy. If you commit to the CAN Jags, I would recommend a 2CAN for your competition robot to give you the most CAN bandwidth. You won't end up using it all under normal conditions, but will thank me when some of your Jags reset, and you want to recover them while still sending updates to the remainder of your working Jags.

Here's code for our 2013 robot's drivetrain, which includes CAN error handling. It was a 4 Jaguar drive. We had 5 more Jaguars on the communications chain for various other mechanisms. This robot was driven off the Black Serial Adapter, but we definitely pushed the limits of it:

https://code.google.com/p/robotics610/source/browse/trunk/XIII%20-%20Competition/src/org/crescentschool/robotics/competition/subsystems/DriveTrain.java


We used to use CAN Jaguars where we wanted PID control. Our team has skilled-up significantly in our programming expertise over the past few years, and our student programmers now prefer to code their own software PID controllers. The Jag's Speed Control mode lacks Feed Forward, which is something our team feels is a requirement for effective speed control. Also, we have never been able get the expected/desired results from the Derivative term in either Position or Speed Control mode for some reason.

Honestly, I find the true strength of Jaguars to be during the prototyping phase. They are the best for getting a quick PID system running within a matter of minutes. A Jag, battery, encoder/pot, a laptop w/ black serial adapter and BDC-Comm. They were game changers for us in 2013 when we had several frisbee shooting prototypes, and were able to put very good closed loop control on each and every one.

[zbrozek]

Ah, the undervoltage is something I didn't consider. How good is the current-mode controller? Presumably it's cycle-by-cycle at the PWM rate...? I hope to run current control mode, so with any luck the motors won't draw more than 40A each even in stall.

I'll test the current-regulation quality tomorrow and report back. I have a couple of approaches to try, any input would be appreciated:


Programmable load (mine's rated to 50A, 500V, 600W) in constant-voltage mode in series with an appropriately-sized inductor to simulate a spinning motor at various speeds.
Run a motor and lock its shaft. This loses the ability to try and various "speeds" but will more accurately simulate the inductance of the motor.
Run two motors back to back, where one is controlled by me with a knob on a power supply (the one I plan to use is 0-80V, 1200W, linear post-regulator) and the other controlled by the Jaguar. My voltage knob is basically a speed setting. It's current setting is basically torque.


The third option is probably the most realistic and versatile, but also the most setup. I'm not well-equipped (mechanically) to do that at least for another week.

[Joe Ross]

Ah, the undervoltage is something I didn't consider. How good is the current-mode controller? Presumably it's cycle-by-cycle at the PWM rate...? I hope to run current control mode, so with any luck the motors won't draw more than 40A each even in stall.

The Jaguars closed loop modes (including current control) are performed at 1000hz. This is faster then possible when using PWM input (200hz), but slower then the h-bridge pulse rate (15,000hz).

[zbrozek]

The Jaguars closed loop modes (including current control) are performed at 1000hz. This is faster then possible when using PWM input (200hz), but slower then the h-bridge pulse rate (15,000hz).

That's unfortunate, but probably fast enough for avoiding major current-induced battery-sag. Bumpers don't squish in one millisecond, I guess. Back when I was building motor controllers for a living (~150-250 kilowatts, 450V systems) we would always do current-mode control at the PWM rate and then wrap other closed loop systems around that.

[Levansic]

The quality of closed loop current control really depends on your expectations. We find it OK for controlling torque, to a point. With the relatively small motors designed for low duty cycles (e.g. window motors), you have to be aware of the effects of coil heating, and the specific friction of each individual gearbox. Your mileage may vary greatly, especially the more you test.

Also, the measured current will be accurate to about an amp or so. If your parameters aren't set correctly and you try to command a load higher than 20A, you may induce a shutdown before anything even moves, due to firmware coded limits. The v. 107 firmware is better than the previous incarnations, but it is still very overprotective.

--Len

[nuttle]

If you use C++ or Java, you might want to consider issuing CAN Jag commands in a separate thread as these are synchronous and can take a while, particularly if there are a lot of them and they wind up timing out.

Check out this (http://www.chiefdelphi.com/forums/showpost.php?p=1317485&postcount=17) thread as well.

[FrankJ]

The standard for CanBus is the daisy chain. The reason you can get away with a star topology is the short runs typical on a FRC robot. With com lines in general, it is generally best to follow the spec as rigorously as possible.

[Levansic]

Daisy chain for physical mechanical interconnects in the typical FRC application, yes. But the nodes don't propagate the signal. It is a party-line with everybody hanging on. As you said, the short runs allow us to get away with the star, and the CANbus standard does not specify any physical layer. As long as every node is holding on to CAN-High and CAN-Low, and they are held apart by sufficient resistance, it doesn't matter.

This is like the old 10BASE2 networks being supplanted by 10BASE-T. The older co-ax 10-BASE2 could run the length of a building (with a max length around 550 ft.), but if it did, your speed would drop due to signal reflection. Also, the T-connectors that provided the daisy chain, were the weak link. Physical strain on one or some corrosion in a higher humidity environment, and you lost the entire network. Also, adding or removing a node required breaking the network for everyone. 10BASE-T had the same speed, but much higher reliability. Primarily because of the star topology.

--Len