CAN on the entire 2012 robot

[mjcoss]

Team 303 used all CAN as well. We had 8 motor controllers, 6 Black Jaguars, and 2 Tan ones. There are some real issues with using CAN, as others have mentioned. Lost configuration on brown out, not stellar PID controls, and timeouts of messages on the bus - as reported by the cRIO. In addition, you have a new single point of failure in either the 2CAN, or the serial cable. Lost of that device or cable will render your robot dead in the water.

We also had a case where one of the Jaguars on the bus went crazy and flooded the bus, causing us to loose comm with all of the Jaguars.

One failure case that we had (and is the reason for the 2 Tan ones) is on our shooter motor. If you rapidly changed the setpoint on our shooter motors, the Black Jaguars would eventual stop working completely, and required a reset, and reflash of the firmware. The Tan ones would reset and this triggered code which reloaded the configuration and start working again.

Lots of people don't like the high current shutdown of the Jaguars, and I'd like to have it be tunable but should you really be running the motors at such a high current? The victors would reboot as well but they rebooted quickly, and had no configuration, and would keep trying to do what you told them until they burned out either the motor or themselves. Seems better to save the equipment, and fix the high current issues.

[Alan Anderson]

Originally Posted by mjcoss

Lots of people don't like the high current shutdown of the Jaguars, and I'd like to have it be tunable but should you really be running the motors at such a high current?

There's already a circuit breaker to protect the wiring from overcurrent situations. The Jaguar's shutdown is there only to protect the Jaguar itself, and I think it's too aggressive.

[FrankJ]

We had 7 jags on our canbus without issues. 4 were on the mechanum drive cims, 2 on the fisherprice shooter motor, & one on a banebot 500 conveyor. Only the mechanum drives would be what I consider to be heavily loaded. We used the serial port on the Crio, Anal about the canbus wiring, and careful not to overload the canbus network with traffic. Had zero problems once other issues were sorted.

I did find out that there is an issue with the First implementation of canbus. If you write to an non existent node (Read resetting as well) You will crash the canbus. As I understand it the canbus "driver" on the Crio waits for an acknowledgement that never comes.

[mswalker]

We used CAN in 2011 for four motors without any problem. In 2012 we linked 9 Jaguars (about half each black/tan) with CAN. We had quite a few problems with loss of motor function and increased latency. I believe that the connections and wire integrity were the main issues. We spent several hours one night testing all the cables and connectors to make sure we had good wires and good connections. That worked for a while but then the latency came back. The latency showed up in a lack of responsiveness to the controls - e.g. stuttering instead of driving ahead smoothly. In each case it would take a lot of time to trace the entire daisy chain to try to figure out where we were having a problem. When we watched the network when we had problems we would see a large number of communications errors, e.g. can't find the address. We could usually fix the problems by replacing a cable or working on a jack but it all took time.

After our practice sessions at regionals we replaced the CAN connections with PWM. We didn't have any issues with control latency after that.

CAN seems to be the way to go but doesn't seem sturdy or reliable enough at this point.

[Brian Selle]

We had 13 motors on our 2012 robot, 9 were controlled with Jaguars/CAN using the 2CAN. The biggest issue we experienced early on was the connector pins not sprung out far enough to make good contact. After fixing that, everything worked flawlessly all the way through the championships. I suspect the latency issues mentioned earlier may have been due to using the serial bus instead of a 2CAN. We experienced none. We ran one closed loop PID loop with a high quality potentiometer and it was actually much less sensitive to the gains than running it through the cRio probably because the 1000hz update rate is more forgiving. Having some options to filter the sensor inputs would be very nice.

We had 2 alliance partners fail during our regional finals due to PWM cables coming loose (one was glued in place). I like hearing the RJ-11 "click" in place.

[JDNovak]

Team 16 has used CAN since 2010. We started with the 2CAN from the beginning and ran 10 Jaguars the first year and 11 Jaguars in 2011 and this year. The biggest issue the first two years was an initialization problem at boot up that was hard to detect but would render the robot motionless at the start of the match. This risk caused us to convert to PWMs at the end of last season.

This year we started again with CAN intent on finding the issue and solving it rather than avoiding it. We haven't had the problem with this year's firmware and CAN driver. We did have problems with the original 2CAN due to static but we were able to overcome that until we could get the redesigned 2CAN just before the start of the season.

There are tradeoffs with every system. Every time we build another robot we have cable issues until all marginal ones are found and replaced. After that we have had very little trouble. As several have alluded to, a cable problem usually takes the whole system down due to daisy chaning and failed termination. I intend to create a bus system that reduces this weakness similar to the ones referred to above. The 2CAN web page is invaluable in finding problems quickly. It can even be monitored through the router while driving to see motor loading and intermittant problems.

One side issue I would like point out is the Jaguar overcurrent protection vs Victors. I have had a few motors fail in the last year and a couple with very low resistance. The Jaguars shut down fast enough to keep the battery voltage above the reset point of the Crio and D-Link. I have heard of shorted motors on victors in at least a couple of cases that left robots dead while the system rebooted. Sometimes the quick overcurrent protection is worth something. We have had no problem with overcurrent shutdown on properly geared systems.

One of the reasons we continue to come back to CAN is the inherent current monitoring on every motor. One use is to protect motors in parallel. Our winch this year uses worm gearboxes in parallel to eliminate backdriving. if one motor doesn't drive the other is stalled and fails quickly. current monitoring allowed shutdown fast enough to avoid this problem.

As for PID control on board. the testing we have done has worked well but we always wind up back in the Crio because of lack of features in the Jaguar. Syncing two motors is a big issue. If there were some filtering options and the configuration was non-volitile I think we would be using it.

It will be interesting to see what transpires with TI backing out of manufacturing Jaguars but if we have to go back to PWM I'll be dissapointed.

My opinion is that a lot of the challenge of robot design is in finding how much technology you can incorporate into your design without making it the weak link. This about science and technology, isn't it?

[mikets]

Originally Posted by JDNovak

As several have alluded to, a cable problem usually takes the whole system down due to daisy chaning and failed termination. I intend to create a bus system that reduces this weakness similar to the ones referred to above.

Our team ran 7 Jags on a T-tap bus topology like the following:
http://www.chiefdelphi.com/forums/sh...t=99554&page=3
We never had any problem with it. We had a couple of bad CAN cables but they were quickly identified and replaced. Since they weren't daisy chained, only the bad ones showed up with problems, the others kept on working.

[enrique]

Hello all. This year team 1251 started off 100% CAN this year at the Orlando regional. Our robot worked in the pits, but would not work on the field. We switched to PWM, for the mean time and it started working. Later we found out our serial adapter was missing the resistor that it was supposed to have. My guess is that the missing resistor opened the CAN network to interference from the field. We then put the CAN network back on and half of the motors on it. 2 motors on the drive system where PWM and the other 2 where CAN. Our shooter motors where also 100% CAN. Everything worked fine, except we had 1 PWM pop out and one of the PWM drive motors stopped, even with glue on the connector. When we went to the regional in Fort Lauderdale, we switched 2CAN. I really was impressed with 2CAN. Plus overtheroad electronics provided good support. We did have some of the CAN network go out 1 time in Fort Lauderdale. I found it was a 12 pin connector we used from radio shack, built up corrosion and would cut power to a couple of the jaguars. The connector pins where black (Char). Removing this connector fixed the problem. I hear the current protection is being changed. I have to say, this year there where motors plugged in backwards (opposing). Each time this happened, the jaguars went to protect mode and we fixed it. In the past I have had victors blow, because of this. Of course, you should not wire the motor backwards, but its nice to know it will not cost you money if it happens. I have read some threads with people causing the jaguars to go into protect mode with correct wiring. I would venture to say the motor in some cases are working to hard and probably do not have a proper gearbox for the job. But as it stands, we now feel comfortable enough and experienced enough to go 100% CAN.

[Phalanx]

Hi everyone,

Team mercury 1089 has used CAN in a variety of different setups with varying results.

We used CAN over our entire robot in 2010, and while it worked well, it did suffer from "brown out" conditions which caused our robot drive to stop functioning. As long as we didn't brown out, it worked well.

This past year we used CAN and the PID built into the Jaguar to manage our shooter motor, but, we used PWM with JAG's to run the drive system. We did find a bug in the Labview Periodic Status Update VI that would throw an error, but once we knew the condition and the bug, we suppressed that error.

When the JAG browns out it "forgets" your CAN configuration settings(it still remembers it's ID number) and resets to PWM operation mode by default. We really need to write some code to detect the brown out condition and reinitialize the JAG with our settings.

[connor.worley]

Maybe I can provide some insight as to why a team wouldn't use CAN. My team chooses not to use CAN for two big reasons:

• We've had multiple Jags fail in testing
• We haven't had a Victor fail in testing or in our past 10 competitions (not sure about before then- that was before I joined)

The features CAN offers are appealing, but the implementation is prone to failure, at least in my team's case.

[mikets]

Last season, our team tried CAN for the first time. We read about the brownout problem and decided to do something about it before it happens to us. Our team uses Wind River C++. We wrote a wrapper CANJag class inheriting the CANJaguar class for detecting brownouts and restoring all the configurations if necessary. We never had any problem with CAN during the entire season. So we never really know if the code worked. After the season ended, we had a public event that required demo'ing our robot the entire day. It went very smoothly but at some point, our driver reported to me that he saw yellow warnings flying by the debugger saying something about brown out detected. I took a look and was delighted to see that was a warning in the new module detecting brownouts and restoring configurations. The driver didn't even notice anything wrong with respect to the driving. It just kept going normally (may be a little sluggish). It turned out, the driving demo non-stop for a few hours ran down the battery to a voltage level that started to cause brownouts. So we replaced with a fresh battery and everything was good again. If you want to look at how we implemented that class, you can access it here in case you want to port it to LabView (http://proj.titanrobotics.net/hg/Frc...rclib/CanJag.h).
Ideally, this code should be integrated into WPILib. This module basically shadows all the important configuration data. It overrides the CANJaguar::Set method so that before setting the motor power, it checks for brownout condition. If there is no brownout, no extra work done. But if it does detect brownout, all the shadowed configurations will be programmed back to the Jaguar before programming the motor power. The module also has an optimization to minimize unnecessary CAN traffic by checking if the caller is setting the same motor power over and over again (which is very common in your iterative robot loop). It will only send a CAN message to set power if the power is different from the last value.
Actually even better, if the CAN implementation of Jaguar or Talon makes configuration data non-volatile, then we don't need this code at all! But of course, shadowing values is still beneficial for CAN traffic optimization.

[techhelpbb]

Originally Posted by mikets

Last season, our team tried CAN for the first time. We read about the brownout problem and decided to do something about it before it happens to us....

I think this is excellent work and very valuable to the whole community but I've said that before.

I do want to point out that there's another issue with a brown out that may not be considered.

If you use encoders and the Jaguars brown out the pulse counts will no longer be accurate. In a velocity control sense where the system can move freely all the way around that's not a big issue. However, in a system with limits and no limit except the encoder readings that could be an issue to consider.

[mikets]

Originally Posted by techhelpbb

If you use encoders and the Jaguars brown out the pulse counts will no longer be accurate. In a velocity control sense where the system can move freely all the way around that's not a big issue. However, in a system with limits and no limit except the encoder readings that could be an issue to consider.

That's a fair scenario. I will modify the code to also restore the position count. That should take care of that scenario.

[techhelpbb]

Originally Posted by mikets

That's a fair scenario. I will modify the code to also restore the position count. That should take care of that scenario.

A modification like that is a great idea but there's something to consider with it:

The problem with quadrature and even single channel encoders is that if you fail to track their outputs momentarily you loose your accurate fix on their direction of rotation during the missing interval and the amount of rotation during that interval as well.

Absolute encoders can help because they produce directional information that is absolute to the encoder rotation/position. To a point that helps till the encoder has enough time to fully revolve and then that information will be wrong. So it gives you a little more buffer but I can see how a fast moving input to the encoder could quickly entirely revolve before a Jaguar resets to full operation.

So if the Jaguar browns out or looses power it'll cease to service the encoder interrupt and that information will be lost. Restoring the last known good value is a good starting point, but if the mechanism was influenced by gravity or momentum while the Jaguar was 'out to lunch' the old data might not be any more valid than the most current reading.

Here's a scenario:

An arm with shoulder. The shoulder has a limited range of rotation. The arm is exposed to additional load as the end effector holds an object. During the course of driving the arm tries to move the shoulder back to one limit. As it approaches that limit the forces increase and the Jaguar browns out. The routine sees the brownout and resets the encoder position to a value approaching that limit. However due to momentum the encoder is now at or past that limit. So the arm tries to move back to that limit. It's choices are: move a complete rotation which it can't so that's an overload or hit the hard stop trying to move to a fictional target and that's an overload. Either case there could be mechanical issues induced and more brown outs causing more and more attempts to reach a fictional target.