We’re using the CAN Bus this year (as well as last year), but we’re having some weird issues.
When we try to drive the robot, the drive train motors stutter a bit. Almost like a lag of sorts. We have a total of 7 Jags in a CAN bus and all have the latest firmware. We are NOT using the ClassMate, but rather a old Lenovo laptop (still low-end, but should be fine for driving)
We are getting errors codes -44061 and -44087 in the driver station. The driver station log file is attached (just running teleop).
We tried using both 5GHz and 2.4GHz connections, same problem either way. We DID notice that, on the dashboard, if we disabled the camera, the stuttering is lessened, but still not perfect (with the camera on it’s a bit worse).
This is pretty late in the build season, but hopefully we can figure this problem out
With 7 Jaguars, you might be getting close to having bandwidth trouble with the serial interface. You’re also at the point where you have a lot of cables in series, where one bad cable or terminator could cause issues.
So…are you suggesting making some of them PWM over CAN to save bandwidth? I thought I read somewhere that the limit was something like 16 or something like that.
It depends on how often you are sending data, and how often you are requesting status.
If you have Jaguars on CAN but aren’t really using any CAN features, I would definitely recommend moving them to PWM. You can also work to minimize the number of CAN messages going back and forth.
True. It’s silly, but the only reason we are using CAN over PWM is because they snap in versus sit in (like PWMs). Haha!
We are using the drive train jags (count 4) constantly, obviously. The other 3 are used not as much, so maybe those 3 can go to PWMs.
We would really not like to switch to PWMs since we’ve had problems with them popping out during a match. I guess we can bring out the hot glue or something
You are using the cable retention clips on the front edge of the jags, right? I’d be surprised if your pwm cables popped out while using the clips correctly.
We weren’t We were wondering what those little “slots” were for After running it a while, it’s running MUCH better. Not sure why to be honest…But after leaving it for a day and trying it the next day, it ran the whole day with 0 lag! It’s an anomaly!
We’ve also found that if you have a CAN Jaguar defined in the software that isn’t physically hooked up, you can get stutters, depending on how the code is written.
You can’t really remove it… It’s an exception in the underlying program (FRC_NetworkCommunications.out). If the connection is not made, then the program times out and it returns an error state. It behaves a lot like UDP in that it ignores packets that didn’t go through, difference being of course that it recognizes if a packet was lost. For example, if I try to drive my robot and all my Jaguar’s aren’t connected, it will stutter. But when I tell the Jaguars to stop, they will stop even though they are receiving errors from the CAN Bus. I’m not too familiar with the CAN Bus so a lot of what I could be saying is wrong.
I would make sure that your Jaguars are plugged in and if they’re not, at least make sure they aren’t instantiated in your code. I’m not sure how LabVIEW works so I don’t know if it’s that simple… I come from C/C++ and Java.
Also, I would look at either using PWM for your Jags (ones that don’t use any CAN features that the Jaguar offers) or getting a Cross the Road Electronics 2CAN from somewhere. That gives you a ton more bandwidth but they don’t sell them anymore unfortunately.
To be honest, the only reason we used ALL CAN (as opposed to some CAN and some PWMs) is because we like the locking phone-cable-connection that doesn’t come out :-/
It sounds like, after lots of research, that we can’t have too many Jags on CAN.
We were wondering what those little “slots” were for