NI Week Athena Announcement and Q&A Panel

[otherguy]

Originally Posted by DonRotolo

The current Jaguar CAN has us daisy-chaining network nodes, so if one drops the network, everything beyond it becomes unreachable.

I'm pretty sure this isn't true.

I can't find the schematics or pictures of the PCB to support this, but if I remember correctly, the CAN traces are bridged ON THE PCB of each jaguar. That means a jag without power will passively relay CAN communications through itself. This is true for CAN communications on all the jaguars. It doesn't apply to a black jag which is being used as a serial bridge. If that one loses power/communications... then you lose your conduit through which to communicate to the CAN bus. There's no way around that besides using something like the 2CAN.

I believe the softrware side of the house (for Java at least) doesn't handle a controller going off line gracefully. There's a timeout period of something like 3 seconds which the CAN communication code will block on. So this will effectively take down all CAN communications for that period unless YOU set your program up to detect the missing CAN devices and stop trying to communicate to them. 3 seconds of no communications to motor controllers doesn't make for a very happy robot. This is what happened to us in 2012 @ NYC during eliminations (with your team BTW). We had a snap action breaker which would randomly failing open for no apparent reason. This would take one of our drive train motor controllers off line, and cause the remaining CAN controllers to not get any communications for long periods of time(we had all our drivetrain motor comm.s in a single try/catch block). We were trying to fix this between Semi finals matches but by the time I realized what was causing our problem there was just not enough time to make the changes and deploy the code. Of course we didn't have that issue UNTIL semi-finals.

[dyanoshak]

Originally Posted by DonRotolo

The current Jaguar CAN has us daisy-chaining network nodes, so if one drops the network, everything beyond it becomes unreachable.

This statement misleading.

The CAN signals are hard wired from connector to connector on the Jaguar PCB. Even if the Jaguar loses power, other Jags on the network will be unaffected.

However, if the CAN cabling is physically disconnected, then yes, every Jag after that will be unreachable.

Edit:
James beat me to it

He's also correct about the Black Jag when it is the serial bridge:

Originally Posted by otherguy

It doesn't apply to a black jag which is being used as a serial bridge. If that one loses power/communications... then you lose your conduit through which to communicate to the CAN bus. There's no way around that besides using something like the 2CAN.

[flameout]

I've seen references to RTLinux, and to Linux with "realtime extensions." Does anyone know what variant of realtime Linux will be on the RoboRIO? Have they revived RTLinux?

[Peter Johnson]

Originally Posted by flameout

I've seen references to RTLinux, and to Linux with "realtime extensions." Does anyone know what variant of realtime Linux will be on the RoboRIO? Have they revived RTLinux?

It's a custom NI version. Per https://decibel.ni.com/content/message/56764 and http://www.ni.com/white-paper/14626/, it sounds like it's 2.6 with the PREEMPT_RT patchset (rt.wiki.kernel.org).

[flameout]

Thank you -- I saw the whitepaper, but that didn't mention anything specific about the kernel itself. The NI community post is much more informative.

I'm glad to hear it's PREEMPT_RT -- in my experience with RTAI, Xenomai, and PREEMPT_RT, it has (by far) the best driver selection, being the only one able to use standard Linux drivers in realtime.

[Thad House]

I'm really happy about this. Having full linux onboard would be great. Access to the shell means we can write other programs, and have the main program call those programs, and it should allow us to get more modular. Also adding new languages should be possible just by wrapping the libraries, so C# and python will both be easily doable because both are available on Arm Linux.

[Joe Ross]

Originally Posted by Peter Johnson

It's a custom NI version. Per https://decibel.ni.com/content/message/56764 and http://www.ni.com/white-paper/14626/, it sounds like it's 2.6 with the PREEMPT_RT patchset (rt.wiki.kernel.org).

I'm guessing 3.2. http://article.gmane.org/gmane.linux.rt.user/10332

[DonRotolo]

Thanks otherguy and dyanoshak for the corrcetion. I was just plain wrong. Learn something new every day and all...

Yes, of course if you physically disconnect it, or if the 'Serial-to-CAN converter' (that first black Jag) goes down, all bets are off.

[Meshbeard]

If I recall correctly, the issue that some teams were having with CANbus was when one jag had some sort of error and flooded the CAN network with error messages so commands from the controller couldn't get through. I think it was just an issue with the jags.

[RufflesRidge]

Originally Posted by Meshbeard

If I recall correctly, the issue that some teams were having with CANbus was when one jag had some sort of error and flooded the CAN network with error messages so commands from the controller couldn't get through. I think it was just an issue with the jags.

It's an issue with how WPILib deals, or doesn't deal rather, with a jag erroring out. If you keep trying to talk to the jag with messages that require an ACK you will have to keep waiting for the full timeout to not get one. Which will cause your code to slow down and throw motor safety errors which slow the code down further and...well you can see where this is going.

You can use the No-Ack versions of messages to help and/or add some intelligence in a class that wraps CAN Jag to prevent spamming messages to a jag that's not responding and to detect and re-initialize a jag that browns out if you are using anything other than the default mode.

[jhersh]

Originally Posted by RufflesRidge

It's an issue with how WPILib deals, or doesn't deal rather, with a jag erroring out. If you keep trying to talk to the jag with messages that require an ACK you will have to keep waiting for the full timeout to not get one. Which will cause your code to slow down and throw motor safety errors which slow the code down further and...well you can see where this is going.

You can use the No-Ack versions of messages to help and/or add some intelligence in a class that wraps CAN Jag to prevent spamming messages to a jag that's not responding and to detect and re-initialize a jag that browns out if you are using anything other than the default mode.

The delays and motor safety you see could be one of 2 things...

1) The errors causing slowdown in LabVIEW WPILib due to the Auto-error handler feature which has to synchronize with the main thread. This is instigated when the errors from a Jaguar access call has its error wire coming out of the VI not connected. Just wire it up to the side of a structure like a loop, case structure, or sequence structure, and the auto error handler will not get invoked.

2) You have no threading in your robot program that allows other motors to be accessed while the one controller fails to respond. This of course causes the rest of them to not get the control update in time either. You will then see the motor safety messages. This applies to any language.

[jhersh]

Originally Posted by Joe Ross

I'm guessing 3.2. http://article.gmane.org/gmane.linux.rt.user/10332

Very nice sleuthing.

[nuggetsyl]

I would like to make a request for GEN 2 of our new 2014 controller.


Mounting Holes.

[AllenGregoryIV]

Originally Posted by nuggetsyl

I would like to make a request for GEN 2 of our new 2014 controller.


Mounting Holes.

I didn't really notice that. It does say mounting features. Anyone want to explain how they are designed to work? We won't have to resort to velcro and zip ties like we currently do for the radio.

Also where are the other shared PWM pins? The pinout on the site only lists 3 of the 10 pins that should have PWM.

[Steven Donow]

Originally Posted by AllenGregoryIV

I didn't really notice that. It does say mounting features. Anyone want to explain how they are designed to work? We won't have to resort to velcro and zip ties like we currently do for the radio.

Also where are the other shared PWM pins? The pinout on the site only lists 3 of the 10 pins that should have PWM.

IIRC from the stream they said that there are holes in the corners of it intended for zipties(ie. it's more reliable that just ziptieing a radio now). But I think they also said there are other holes that you could use to mount it to, though I think you have to mount it to something else, not just the frame of your robot(they mentioned this as a way of encouraging the approaching 3D printing boom)