Thread: CAN reliability
View Single Post
  #17   Spotlight this post!  
Unread 15-07-2010, 14:37
kamocat's Avatar
kamocat kamocat is offline
Test Engineer
AKA: Marshal Horn
FRC #3213 (Thunder Tech)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 2008
Location: Tacoma
Posts: 894
kamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nice
Send a message via AIM to kamocat Send a message via MSN to kamocat
Re: CAN reliability

Quote:
Originally Posted by Bot190 View Post
My team used CAN this year on our robot and found some issues with connection. We found that when polling for information while sending output information to fast the jaguars would lose connection briefly. The bandwidth afforded by a serial connection is a lot less than that of a CAN connection. This creates a big chokepoint on sending and receiving information from the jaguars.
Well, I tried to actually run a robot today. It works pretty well with the default project they provide, but that was just voltage mode.
I modified to to be in speed mode, with synchronous update, and linear control (instead of that weird squared thing they have in arcade drive). I was having trouble with some of my motors not running, so I used Periodic Tasks to poll all four motors on all status, PID, output, and encoder lines.
It turns out that they have exactly the same configuration as the others, but their output seemed to be disabled. It is repeatable, but inconsistent. The only pattern I noticed is that they usually work again if I stop the program and restart, and that it is only these two controllers. They are my rear motors (which are updated first), and in the middle of my CAN bus. Switching the front and reverse motors don't seem to help. Their Device IDs are 11 and 13; the other two are 10 and 12. 13 is my tan jaguar, but the issue usually occurs with 11.
Sometimes, the motors don't run initially, and then kick in when I get to higher speeds. However, I usually don't sit at low speeds, so this may be simply time-related. When their output is disabled, they also report speed as 0, regardless of the actual speed of the wheel. Under normal operations, if their encoder cable was unplugged, PID would cause them to speed up drastically, not cut power.

If you like, I can provide a video of the feedback I'm getting in the periodic tasks loop, or I can make a program to log it as it occurs.


For the record, I've made some significant changes to some CAN VIs. If any of these things create issues, please tell me now.
CAN Jag Open now enables control for ALL modes (not just voltage).
Enable and Disable control now work for ALL modes (including voltage).
The invert direction option now works for ALL modes (not just voltage).
I'm using a copy of "set output" which appends an unsigned byte to the end of the message (for synchronization group. It's actually a bit-mask.)
CAN Motors now uses this "set output with synchro", and also has a "CAN Send" with the system message "Sync Update" with the synchronization group mask as a message. (The value I chose is equivelant to decimal 128. It's the 8th synchronization group.)

In addition to this information, I have an explicit question:
What is a Token message? I noticed that the token messages (which seem to be the output set, enable, and disable for each mode) require two empty bytes at the beginning of each message. I can't find anything like this in Luminary Micro's CAN Specification. Is this where the "trusted mode" comes in? Does the FRC_BlackJagPlugin put some secret number in these two bytes, which the jaguars must have if they are to accept the message?
__________________
-- Marshal Horn
Reply With Quote