Go to Post That is the ultimate "dream match" that I long to see. If not during the season, maybe we will see it at IRI. :) . - dlavery [more]
Home
Go Back   Chief Delphi > Technical > Electrical > CAN
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 12-07-2010, 16:25
Radical Pi Radical Pi is offline
Putting the Jumper in the Bumper
AKA: Ian Thompson
FRC #0639 (Code Red Robotics)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2010
Location: New York
Posts: 655
Radical Pi has a spectacular aura aboutRadical Pi has a spectacular aura aboutRadical Pi has a spectacular aura about
Re: CAN reliability

Just a quick confirmation for your assumption about the serial-to-can bridge. Assuming FIRST didn't change too much from the default Jaguar firmware, I'm looking at the default source code right now and it looks like it directly resends the body of the serial message over the CAN bus if the message is intended for another jaguar or if it's meant for all the jaguars. It looks like the CAN headers are added on in the process, so the serial message is only containing the device ID and the message itself. If the message is intended for the bridging jaguar, it never reaches the CAN bus and is just directly processed.
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"

Last edited by Radical Pi : 12-07-2010 at 16:29.
Reply With Quote
  #17   Spotlight this post!  
Unread 12-07-2010, 16:44
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 Radical Pi View Post
Just a quick confirmation for your assumption about the serial-to-can bridge. Assuming FIRST didn't change too much from the default Jaguar firmware, I'm looking at the default source code right now and it looks like it directly resends the body of the serial message over the CAN bus if the message is intended for another jaguar or if it's meant for all the jaguars. It looks like the CAN headers are added on in the process, so the serial message is only containing the device ID and the message itself. If the message is intended for the bridging jaguar, it never reaches the CAN bus and is just directly processed.
Really? That's not what I expected, but I'm glad you looked it up.
I suppose this means there could be a small difference in communication speed between the bridging jaguar and the rest.

Bot190:
I understand your reasoning now, thank you.
From this new information, it appears that a 6-byte data field can be sent, but a 10 byte data field can be received. The maximum data field length in CAN is normally 8 bytes, so perhaps those last two bytes are used for something else.
__________________
-- Marshal Horn

Last edited by kamocat : 12-07-2010 at 20:43.
Reply With Quote
  #18   Spotlight this post!  
Unread 12-07-2010, 17:38
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

Okay, I tested how long it took to configure a Jaguar for Position mode.


Clearly, there is something here I'm not accounting for. My estimate was 16ms, and it's turning out to be 172ms.
The figure is very consistent, always 172 or 173 with this combination of actions.
There is no difference in time between the black or tan jags, nor between the bridging jag and the others.

(For some reason, the Device Query action was taking 500ms, and not returning anything, so took that out to make the "total time elapsed" a relevant figure.)

EDIT: Device Query now seems to be taking about 172ms, but still not returning anything.
Anyways, when I run this VI in a loop, with DS Comms running in parallel, it seems to take around 220ms disabled, 240ms enabled. (teleop vs autonomous doesn't make a difference) However, it has a LOT more jitter; the time varies by at least 10ms each way.
Attached Files
File Type: vi config Jag.vi (40.5 KB, 17 views)
__________________
-- Marshal Horn

Last edited by kamocat : 12-07-2010 at 20:31.
Reply With Quote
  #19   Spotlight this post!  
Unread 13-07-2010, 16:45
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

I looked up the baud rate of the Black Jaguars, and it matches the cRIO at 115,200 bits/s. (There is no min or max listed, just the typical, so I think it MUST go at this speed.)

Perhaps the VIs are sending a lot more messages than we thought.
I count two sends and two receives in the "Jag Open". Add one more to each if you're in speed mode, or several more in voltage mode.
It appears that data must be requested from the Black Jaguar; it doesn't automatically send the data back. (I don't know why else CAN Receive would require the arbitration field, referred to here as the message ID)
__________________
-- Marshal Horn
Reply With Quote
  #20   Spotlight this post!  
Unread 13-07-2010, 23:37
Radical Pi Radical Pi is offline
Putting the Jumper in the Bumper
AKA: Ian Thompson
FRC #0639 (Code Red Robotics)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2010
Location: New York
Posts: 655
Radical Pi has a spectacular aura aboutRadical Pi has a spectacular aura aboutRadical Pi has a spectacular aura about
Re: CAN reliability

You're right about the baud, both the black jag code and the cRIO driver init at 115,200.

I'm not sure how the LabVIEW code runs, but I see it a bit different in the C++ version. 3 messages are sent for each Jag getting an init. First is a firmware version request. 2nd, if in Voltage mode, is a message to enter voltage mode (for the other modes, that message is sent when telling the jag to enable PID). The 3rd message is telling the jag that the data line for speed is the encoder (the comment says that the jag requires it for all modes).

Normally, each message, either sending data or requesting data, uses 2 packets. On a sending command (such as setting the speed reference), the command is sent and then the jag replies with an ACK packet. On a requesting command (such as firmware version), the ACK packet is replaced with the reply, and no ACKs are sent. For some reason, the Voltage mode enabler (but not the speed, current, or position enablers. bug?) doesn't check for an ACK packet, so only one packet is used in the code, but according to the Jag firmware an ACK is still sent, so that should still count for 2 packets.

So, I count 6 packets traveling over the serial connection for each jag during init. All other commands use 2 packets , either a single set or a single get (except for setting PID values and configuring the position limits, which use 3 send messages each, so 6 packets each).

One slight correction to my earlier post about what goes over the serial. The arbitration field IS included in the serial packets. It holds the command for the jaguar as well as the device id as a 32-bit unsigned int. Here's my count for the size of the serial packet: 1 byte start of packet, 1 byte for size of packet, 4 bytes for message ID, and then 0 to 4 bytes of data, for a total of 6-10 bytes per packet.

ACK messages contain no data, so 6 bytes large. The original sent message could be 6-10 bytes still, so a single send message totals to 12-16 bytes.

Requests for data from the jag also carry no data, so those again are 6 bytes. Responses always carry at least one byte of data, so those total to 13-16 bytes.

Assuming worst-case scenario (16 bytes for each command), 900 messages can pass through at 115,200 baud, or a little less than 1 full command (send and receive) every millisecond.

At 1 command per millisecond, I doubt the data transfer itself is the bottleneck in your tests.

woah, that post got a bit out of control. Time for bed
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"
Reply With Quote
  #21   Spotlight this post!  
Unread 14-07-2010, 00:40
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,103
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: CAN reliability

Quote:
Originally Posted by Radical Pi View Post
Assuming worst-case scenario (16 bytes for each command), 900 messages can pass through at 115,200 baud, or a little less than 1 full command (send and receive) every millisecond.
at 115200 baud 8N1 each data byte requires 10 bit-times, so max throughput is 115200/10=11520 data bytes per second, or 11.5 data bytes per millisecond (in each direction, xmit & recv).


~
Reply With Quote
  #22   Spotlight this post!  
Unread 14-07-2010, 01:13
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 Radical Pi View Post
You're right about the baud, both the black jag code and the cRIO driver init at 115,200.

I'm not sure how the LabVIEW code runs, but I see it a bit different in the C++ version. 3 messages are sent for each Jag getting an init. First is a firmware version request. 2nd, if in Voltage mode, is a message to enter voltage mode (for the other modes, that message is sent when telling the jag to enable PID). The 3rd message is telling the jag that the data line for speed is the encoder (the comment says that the jag requires it for all modes).

Normally, each message, either sending data or requesting data, uses 2 packets. On a sending command (such as setting the speed reference), the command is sent and then the jag replies with an ACK packet. On a requesting command (such as firmware version), the ACK packet is replaced with the reply, and no ACKs are sent. For some reason, the Voltage mode enabler (but not the speed, current, or position enablers. bug?) doesn't check for an ACK packet, so only one packet is used in the code, but according to the Jag firmware an ACK is still sent, so that should still count for 2 packets.

So, I count 6 packets traveling over the serial connection for each jag during init. All other commands use 2 packets , either a single set or a single get (except for setting PID values and configuring the position limits, which use 3 send messages each, so 6 packets each).

One slight correction to my earlier post about what goes over the serial. The arbitration field IS included in the serial packets. It holds the command for the jaguar as well as the device id as a 32-bit unsigned int. Here's my count for the size of the serial packet: 1 byte start of packet, 1 byte for size of packet, 4 bytes for message ID, and then 0 to 4 bytes of data, for a total of 6-10 bytes per packet.

ACK messages contain no data, so 6 bytes large. The original sent message could be 6-10 bytes still, so a single send message totals to 12-16 bytes.

Requests for data from the jag also carry no data, so those again are 6 bytes. Responses always carry at least one byte of data, so those total to 13-16 bytes.

Assuming worst-case scenario (16 bytes for each command), 900 messages can pass through at 115,200 baud, or a little less than 1 full command (send and receive) every millisecond.

At 1 command per millisecond, I doubt the data transfer itself is the bottleneck in your tests.

woah, that post got a bit out of control. Time for bed
Radical Pi, that's good to know.
The only thing about the messages that doesn't explain is how the limit switch settings are modified. I'll quote from Luminary Micro's Firmware Development Package User's Guide.
Quote:
Forward Soft Limit Switch
This setting takes two values. The first is 16.16 signed fixed-point value that is the position of the forward soft limit switch. The second is an 8-bit value that specifies if the motor position must be greater than or less than the position of the forward soft limit switch. Greater than is encoded as 0
and less than is encoded as 1. Less than should be used if positive voltage results in the position increasing and greater than if positive voltage results in the position decreasing.
If this command is sent with no data, the motor controller will respond by sending this same message to report the position of the forward soft limit switch.
This has not changed in the FRC firmware.


Also, I'm sure the Black Jaguar driver is the same for all languages; we use the same .out file, don't we?



So, what's left to cause the commands to take so long?
Bogging down of the cRIO processor? (I don't think so; this is the only thing running on it)
Slow response time on the Jaguar? It has a 50 Mhz processor.

I don't know what the issue could be.

Is there anyone who has a robot available that can confirm my results? (I don't care if you use my code or create your own)
From another standpoint, it's remotely possible my code is at fault. I can test anyone's LabVIEW code for them. If you tell me how to deploy the compiled code over FTP, then I can test code written in C++ and Java as well. (If you didn't notice, I have lots of time)
__________________
-- Marshal Horn

Last edited by kamocat : 14-07-2010 at 01:46.
Reply With Quote
  #23   Spotlight this post!  
Unread 14-07-2010, 09:25
Radical Pi Radical Pi is offline
Putting the Jumper in the Bumper
AKA: Ian Thompson
FRC #0639 (Code Red Robotics)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2010
Location: New York
Posts: 655
Radical Pi has a spectacular aura aboutRadical Pi has a spectacular aura aboutRadical Pi has a spectacular aura about
Re: CAN reliability

My mistake on the serial bandwidth. The point still stands though that it's not an issue.

I see the 5 bytes too of data in the soft limits code for C++ as well.

Yes, both languages use the same .out file, but the driver only handles pulling the data off of the serial line and splitting messageID from data. The CAN protocol is still defined by user code.

I think I may have a reason for the slowdown and the jitter. In the C++ code, all requests to the CAN driver are routed through either FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge, or FRC_NetworkCommunication_JaguarCANDriver_receiveMe ssage. Also, when the driver is loaded by the OS, the init calls FRC_NetworkCommunication_JaguarCANDriver_registerI nterface with a pointer to the driver class. By the names, I'd assume that all messages are run through the NetworkCommunication library before they get to the driver itself, most likely so a disabled robot cannot continue to send CAN messages. NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.

As a test, could you put a timer around setTransaction, or even better around the receiveMessage inside setTransaction? receiveMessage directly calls the NetworkCommunication library, so it would be the best place to time the command

One quick question. I see a few "trusted" commands (Enable and Set for each of the control modes) which get an extra 2 bytes of 0s at the beginning of their data section. I don't have the source to the jag firmware that reads Trusted commands, so I'm wondering if you know what trusted means and why it should be used
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"
Reply With Quote
  #24   Spotlight this post!  
Unread 14-07-2010, 10:02
EricVanWyk EricVanWyk is offline
Registered User
no team
 
Join Date: Jan 2007
Rookie Year: 2000
Location: Boston
Posts: 1,597
EricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond repute
Send a message via AIM to EricVanWyk
Re: CAN reliability

Quote:
Originally Posted by Radical Pi View Post
One quick question. I see a few "trusted" commands (Enable and Set for each of the control modes) which get an extra 2 bytes of 0s at the beginning of their data section. I don't have the source to the jag firmware that reads Trusted commands, so I'm wondering if you know what trusted means and why it should be used
"Trusted" communication with the Jaguars is how we assert safety in a CAN enabled system. If you used CAN last year, you used trusted mode. In untrusted mode, an extra PWM cable is attached to each CAN jaguar just to tell that the system is still up and good - untrusted mode was not legal for 2010 FRC use.

There is a security layer that inserts some extra stuff between the commands you send and the data sent to the 2CAN/BlackJagBridge. I won't go in to details, it is what prevents someone from e.g. putting rogue firmware on a 2CAN and driving the robot while disabled.
Reply With Quote
  #25   Spotlight this post!  
Unread 14-07-2010, 14:06
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 Radical Pi View Post
I think I may have a reason for the slowdown and the jitter. In the C++ code, all requests to the CAN driver are routed through either FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge, or FRC_NetworkCommunication_JaguarCANDriver_receiveMe ssage. Also, when the driver is loaded by the OS, the init calls FRC_NetworkCommunication_JaguarCANDriver_registerI nterface with a pointer to the driver class. By the names, I'd assume that all messages are run through the NetworkCommunication library before they get to the driver itself, most likely so a disabled robot cannot continue to send CAN messages. NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.

As a test, could you put a timer around setTransaction, or even better around the receiveMessage inside setTransaction? receiveMessage directly calls the NetworkCommunication library, so it would be the best place to time the command.
Well, what if we changed that? We could open up CAN Send and CAN Receive and make them call the Jaguar plugin directly.

First, however, I'll try what you suggested. But I think I'll actually want it around the "send" and "receive" VIs, because the "set transaction" and "get transaction" use both. However, it might be a good idea to do all of the above: measure how long the transaction is taking as a total, measure the time Send and Receive take to execute, and measure the time in-between them as well.
__________________
-- Marshal Horn

Last edited by kamocat : 14-07-2010 at 16:17.
Reply With Quote
  #26   Spotlight this post!  
Unread 14-07-2010, 15:53
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

The "Clear Ack" VI seems to be taking 16 miliseconds, where as the "send" and "recieve" take 1 or 2.
I'm going to try out the Execution Trace toolkit, and see if I can dig in deeper.

EDIT:
Here's some data collected with the Execution Trace toolkit:
CAN Send takes around 600 microseconds with a message, 10 microseconds without.
CAN Receive takes around 2 miliseconds with a message, 20 microseconds without.
Clear Ack only takes about 15 microseconds.

I guess I'll try changing those DLL calls to directly reference "FRC_BlackJagBridgePlugin.out"

EDIT2: To be honest, it didn't make much difference. I think I'll change it back, however, because I think otherwise it won't let my motors be enabled.

Something that's not quite making sense about this execution trace toolkit is that subVIs are sometimes shown as executing for longer than their owning VI. Does it simply time how long the processor spends on each task, regardless of the VI hierarchy?
__________________
-- Marshal Horn

Last edited by kamocat : 14-07-2010 at 16:41.
Reply With Quote
  #27   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
  #28   Spotlight this post!  
Unread 15-07-2010, 15:56
Radical Pi Radical Pi is offline
Putting the Jumper in the Bumper
AKA: Ian Thompson
FRC #0639 (Code Red Robotics)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2010
Location: New York
Posts: 655
Radical Pi has a spectacular aura aboutRadical Pi has a spectacular aura aboutRadical Pi has a spectacular aura about
Re: CAN reliability

Is the problem following the Jag or the ID (as in try switching it so the code sends the rear commands to the front motors)

Are you sending trusted SET messages every 100 ms? If a jag doesn't receive one every 100ms it will disable itself

Quote:
Originally Posted by kamocat View Post
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?
Read EricVanWyk's message above your's. I just asked the same thing (It's referred to as trusted mode in the C++ code).
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"
Reply With Quote
  #29   Spotlight this post!  
Unread 15-07-2010, 23:22
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 Radical Pi View Post
Is the problem following the Jag or the ID (as in try switching it so the code sends the rear commands to the front motors)

Are you sending trusted SET messages every 100 ms? If a jag doesn't receive one every 100ms it will disable itself



Read EricVanWyk's message above your's. I just asked the same thing (It's referred to as trusted mode in the C++ code).
Trusted SET messages every 100ms? You mean these jaguars effectively have TWO heartbeats?
The problem follows the motor controllers around, regardless of whether they are front or rear.
However, i haven't tried rerouting the CAN bus in a different sequence.

UPDATE:
I'm connected to the robot directly over ethernet, and have the driver station running on my computer. I'm not having any issues.
This means it probably has something to do with timeouts; the delay of running live on a computer over wireless was apparently enough to disable one of the Jaguars?

UPDATE 2:
I happened to try unplugging one of the Jaguars, and then plugging it back in. It created some errors, caused some watchdog expirations, and would no longer run. I didn't realize that once a Jaguar is lost, it's gone until you restart the code. I'll see what I can do to fix that.
(It probably just has to do with the encoder and PID settings being replaced)
I'm also going to try to programmatically determine when the Jaguar is not doing what it should. (If the watchdog is alive and a nonzero output setpoint is being sent, and the output setpoint of the controllers is zero, then that motor is disabled and needs to be reenabled.)

NOTE: I've changed this message several times. Please reread if you have not since 9:33.
__________________
-- Marshal Horn

Last edited by kamocat : 16-07-2010 at 00:37.
Reply With Quote
  #30   Spotlight this post!  
Unread 16-07-2010, 00:34
Radical Pi Radical Pi is offline
Putting the Jumper in the Bumper
AKA: Ian Thompson
FRC #0639 (Code Red Robotics)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2010
Location: New York
Posts: 655
Radical Pi has a spectacular aura aboutRadical Pi has a spectacular aura aboutRadical Pi has a spectacular aura about
Re: CAN reliability

nvm about the trusted set thing. I just saw the trusted heartbeat message in the API. Not sure why if there is a trusted heartbeat the system would need EN and SET messages to be trusted as well. (Although it seems like the heartbeat doesn't work all the time, namely autonomous for us)

Oh and I didn't mean to change the CAN IDs of the jags, I meant to send commands that are meant for (example) 12 and 13 to 10 and 11 instead to see if it is your logic or the jag
__________________

"To have no errors would be life without meaning. No strugle, no joy"
"A network is only as strong as it's weakest linksys"
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Supershifter Encoder Reliability Problems? Qbranch General Forum 5 04-02-2008 12:55
2007 Radio link reliability problem Dave K. Control System 12 02-02-2007 22:26
Mechanical Reliability Andrew Blair Technical Discussion 20 26-10-2005 21:29
can anyone please tell mw where or with what can i lear programing in C techsage Programming 7 23-08-2005 00:25
team 67 reliability? mattshuert OCCRA 6 02-12-2002 15:53


All times are GMT -5. The time now is 19:41.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi