CAN and Jaguars, any limits?

[topgun]

We seem to have run into an issue with CAN and Jaguars at the regional last weekend. We had the NI people and the FTA look at it. Basically we suspect that we are timing out on the CAN bus.

Last year we ran CAN with 9 Jaguars (all black). This year we are running CAN with 11 Jaguars (all black).

Our code has been sent to FIRST for further analysis.

I am wondering if other teams have run into a limit of the number of Jaguars when using CAN. Anything else we should be looking at specifically? Any java programs that test the CAN bus that people are willing to share?

Thanks.

[Andy A.]

Originally Posted by topgun

We seem to have run into an issue with CAN and Jaguars at the regional last weekend. We had the NI people and the FTA look at it. Basically we suspect that we are timing out on the CAN bus.

Last year we ran CAN with 9 Jaguars (all black). This year we are running CAN with 11 Jaguars (all black).

Our code has been sent to FIRST for further analysis.

I am wondering if other teams have run into a limit of the number of Jaguars when using CAN. Anything else we should be looking at specifically? Any java programs that test the CAN bus that people are willing to share?

Thanks.

What sort of CAN network topography are you using?

[gurellia53]

Originally Posted by topgun

we are timing out on the CAN bus.

We were having this issue during testing and it was due to a bad battery. We had 6 Jaguars and when we would drive with the shooter on the battery couldn't support the current and the battery voltage dropped. This caused a CAN timeout on some of the Jags. This occurred with a "fully charged" battery that was 4 years old.

[Alan Anderson]

If you're using a Jaguar as a serial-to-CAN gateway, you're probably pushing the limits of communication bandwidth with 11 devices to talk to. A 2CAN would not be as constraining.

[Mike9966]

Hi, I'm from the same team as Topgun. The configuration is cRio serial to black TI jag with 107 on it, and from there it chains from jag to jag, some tan with 101, some black TI with 107, and during our efforts to fix it, one new Vex Black unit with 107 is now also in the loop. It is terminated on the last jag.

At our regional, we with the help of Nick L (one of the NI guys) scoped it out both at the end of the chain, and in the middle and found little noise, and a basically nice looking signal. Of course, this doesn't capture all of it, but it was nice to know that there wasn't a bunch of noise on the line swamping everything.

The software somewhat randomly will claim that a jag isn't responding, usually one of the higher IDs.

If we restart the code, sometimes it works fine, but about 1 of 4 times, it won't go, and it may be timing out as indicated by jerkyness in the driving. This is really hard to tell though.

Any thoughts are much appreciated, we have 2 weeks to nail it down.

Thanks much,
Mike

[Jon Stratis]

If nothing else, get some code set up so you can move a few of the Jags over to PWM control instead of CAN... maybe that'll help!

[MikeE]

There are wiring limits - 16 Jaguars with a maximum of 20 ft of cabling, although I have seen communication problems increase as cabling gets to 14-15 feet.

Originally Posted by Alan Anderson

If you're using a Jaguar as a serial-to-CAN gateway, you're probably pushing the limits of communication bandwidth with 11 devices to talk to. A 2CAN would not be as constraining.

To put some numbers around Alan's comment, Q22 of the Jaguar FAQ gives the practical capacity using the RS232 interface of about 930 packet/s each way.
But with a 50Hz polling frequency that means under 19 messages each way per period, shared across 11 Jaguars.
Think about how many messages you pass in a typical teleop period.

[innoying]

We had some issues with 10 Jaguars and the 2CAN. We ended up increasing the delay in our main teleop loop and it eliminated the timeouts for us.

[Mike9966]

Well, we put 2 bots side by side to get enough Jags around, and tried communicating with them with 9,10,11, and 12 Jags.
Remember, this is going through the cRio, to a black Jag, and then to a mix of black and tan Jags via CAN.

The long and short of it is that we were able to get 9 and 10 to work fine, no timeouts that we could see, but 11 or up would fail in unpredictable ways.

For now, we are going to put our pickup arm and roller on PWM and the other 8 Jags on Can. Hopefully that will lead to uneventful driving and playing.

Thanks for your thoughts everyone,

Mike

[Jefferson]

We had a similar issue around 7 Jaguars on our practice robot before we realized we had a "bad" termination resistor. We swapped it out, after much other troubleshooting, and it resolved the issue. I can't explain the failure, but I'm sure changing the termination resistor is what fixed it. Typically, no termination results in only 1 Jaguar showing up on the CAN.

I put "bad" in quotes above because we were able to use the "bad" termination resistor on a different CAN bus with 2 Jaguars without issue.

You might give it a try; it's easy enough.

[jvriezen]

Originally Posted by Mike9966

Hopefully that will lead to uneventful driving and playing.
Mike

I think you really want 'eventful' driving and playing... events like scoring discs, driving, turning, hanging..

[gbonehead]

TL;DR - If you're having trouble with a CAN bus with a lot of Jaguars ("a lot" probably means 5-6+), try rewriting your code to only send commands to the CANJaguar when you actually have a speed change. That will reduce CAN traffic significantly.

--

We had what I believe is an issue with the CAN bus as well. We are using a CAN bus with 7 Jaguars - 2 drive, 2 lift, and 3 to control Frisbee feed/push/shooter wheel.

Our competition 'bot (with a cRIO II) was working fine, but after we bagged it and went to use our practice 'bot (with a cRIO I) we started getting extremely erratic behavior ... the movement was horribly jerky, if it moved at all, and there were huge delays in responding to simple commands.

After some bisection debugging (remove half the code, see if it works ) we finally came to the conclusion that it wasn't related to the code at all, but instead to how many Jaguars we were trying to control.

As it had been written, our loop would simply send the motor speed commands to each Jaguar during each loop. I added some timing code in there and saw the man loop degenerate horribly to 4-8 iterations per second, if that.

We re-wrote the code to only send commands to the Jaguars upon change (though not the drive code; that still uses the standard RobotDrive calls every iteration) and I saw the main loop speed increase to something just under 1000 iterations/sec.

The same code works just fine on our cRIO II, and has *probably* increased performance there as well, but it made the cRIO I usable. It will probably help our image processing code as well, though we haven't done our final merge of the target recognition code yet.

All our code is in C++; if you have any questions feel free to email me at bonehead@acm.org - I'm very rarely on Chief Delphi (in fact, I only knew about this thread because one of the other mentors mentioned it to me).

Or you can poke around on SourceForge; all our code is published there at http://paragon571-2011.svn.sourceforge.net ... this year's code is in the robot-2013 directory, amazingly enough

[Todd]

In general you can start running into trouble trying to send lots of CAN commands in your teleop loop. We offload our CAN messages into other processing loops and run them with lesser periodicity. Many motors shouldn't really need to have their speed changed more rapidly than 10-20 hz, and if you had a motor that you wanted to control the speed of more frequently than that, you could have that motor alone operate faster.

You didn't actually say whether or not you're actually doing something like this already, but in case you're not.

The same basic issue is relevant and correctable regardless of what programming language you're using.

[Jefferson]

Originally Posted by Todd

We offload our CAN messages into other processing loops and run them with lesser periodicity.

Would you be willing to provide some sample code of how you accomplish this?

[Todd]

Originally Posted by Jefferson

Would you be willing to provide some sample code of how you accomplish this?

What programming language are you using?

As a trivial example, if in LabVIEW one were to determine in each robot mode (disabled, teleop, autonomous, etc) the command they wanted to send a motor and store it in a global variable, they could then read that global variable in timed tasks in a loop at whatever frequency they wished and call the set motor VI from there.

This can help free your Teleop loop to run as fast as ds packets are received.

Similar trivial examples can be constructed in C++ and Java.

There are a lot better ways that this could be handled, like using an action engine in LabVIEW, or a class in any other language rather than a global variable, but the general principle remains the same.