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.

Re: CAN reliability
 

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.

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.

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)

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. :ahh: Time for bed

Re: CAN reliability
 

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).


~

Re: CAN reliability
 

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.
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)

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

Re: CAN reliability
 

"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.

Re: CAN reliability
 

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.

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?

Re: CAN reliability
 

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?

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

Read EricVanWyk's message above your's. I just asked the same thing (It's referred to as trusted mode in the C++ code).

Re: CAN reliability
 

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.

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