Re: NI Week Athena Announcement and Q&A Panel
 

That should probably be mentioned on this page. It's currently labeled as the roboRIO pinout.

https://decibel.ni.com/content/docs/DOC-30419

Re: NI Week Athena Announcement and Q&A Panel
 

That link doesn't work for me.

Re: NI Week Athena Announcement and Q&A Panel
 

Sorry, I managed to paste it twice in the link box. I fixed the original too.

https://decibel.ni.com/content/docs/DOC-30419

Re: NI Week Athena Announcement and Q&A Panel
 

This controller is really exciting. I can't wait to play around with linux on it!
The expansion port is seriously awesome. It's probably not too hard to make an arduino shield that plugs into it and communicates with serial. This pretty much means that you can get as much i/o as you need.

Re: NI Week Athena Announcement and Q&A Panel
 

I'm loving the footprint.

If I'm not mistaken, its considerably smaller than even the old IFI systems.

I've long thought that the cRIO was serious quantities of overkill for our application, and I can see that roboRIO is no different in that regard. The truth of the matter is that we simply don't need that much processing horsepower.

5 years ago, we were running robots, with vision, gyros, accelerometers, and other sensors, on simple 8 bit microcontrollers running at clock speeds of a few 10s of MHz, worth less than $10. 10 years ago, we were working with just 26 bytes of variable space.

I'm disappointed by the price point. To me, a FIRST controller should be priced such that each team can receive a free one each year, as we did with the IFI system. I know I'm not the only one that feels 1 free donated one, and then needing to buy one each subsequent year is NOT a good solution. This is partly an artifact of using so much excess processing power.

I have extensive experience with RT variants of Linux through my workplace. We use RTAI currently, after switching away from RTLinux several years ago when it stopped being updated. If that experience has taught me anything, its that roboRIO's boot times are unlikely to be dramatically different from cRIOs. I certainly hope my prediction is wrong on this front.

I'm really interested to see what they do in terms of radios. The existing solution using standard 5GHz wifi equipment (2.4GHz in Israel, due to 5GHz being a restricted military frequency) is a bit lacking (the biggest bottleneck in robot boot times is the radios).

All in all, I think roboRIO will be a dramatic improvement over cRIO as an FRC platform. I just think it falls a bit short in places it could have excelled.

We'll see though. Maybe I'll be surprised.

Re: NI Week Athena Announcement and Q&A Panel
 

I was thinking about expansion boards last night. Could we get a couple of mounting points by the expansion slot (one on each side maybe?) to facilitate direct connection? I'm thinking an expansion board would be fairly small, and it would be great to be able to plug it into the expansion slot and bolt it down so it sits just above the controller. If not bolted down, I would worry about such a design possibly coming loose during competition.

Re: NI Week Athena Announcement and Q&A Panel
 

Speaking of boot times, any official input on boot times? Download times? Compile times? Any times? Any time requirements/specs, if the development isn't finished yet?

My work projects (all on 180-240mhz MPC5600 PowerPC's) have a requirement to boot and be ready to synchronize in under 300ms from chip power on. The requirement was the same for the 56mhz MPC500's and older processors, and they also met it.

I don't know if there is any time requirement at all on the current system, and it seems like there just plain isn't (crazy!). VxWorks currently boots in a few seconds (which is very reasonable), the rest is all Netcomm and user code. There is a lot of inefficiency in the user code init libraries (at least in LV, for example the encoder open block reads/writes the same config register and converts units 4x times) too. But a lot of it is still in Netcomm, and I've been told it's because it has to load an FPGA image to read the ADC cals, then unload that image and load the real FPGA image. I would gladly sacrifice a bit of FPGA functionality (for example two counter channels, or the DIO PWM, or DMA) to fit the ADC cal reading in the main FPGA image.

The Vex guys can boot a Cortex and user code and establish radio link in ~15s. The PIC-based IFI would boot and establish radio link in 5s. Why are we sitting around a minute? And getting worse every year?

As for size, it's not too much smaller than an IFI RC. Very similar in size.

Re: NI Week Athena Announcement and Q&A Panel
 

As for the compile times, I think they'd be about the same. For Java, I know they are using the standard java se compiler, and the compiled code will be uploaded somehow (not FTP anymore).

For the boot times, I'm hoping they'll be faster.
Linux can boot really really fast. I've got a little device that runs an FTP server at my house that boots in < 10 seconds.
I know that it will take a little longer as it needs to load the FPGA image/network stuff/user code initialization, but there isn't a reason it needs to be slow.
Check this out http://www.youtube.com/watch?v=-l_DSZe8_F8

Re: NI Week Athena Announcement and Q&A Panel
 

This is not my experience at all. We typically have boot times of ~20 seconds.

Re: NI Week Athena Announcement and Q&A Panel
 

I know it's capable of booting fast, but the current cRio platform shows they did very little to optimize the process. The dual-FPGA-image makes it seem like that, at least.

LV compile/download is very different:
-LV does the compiling. There was a bug in LV 2012 (used for FRC 2013) which caused the compile times to be horribly slow. I'm very aware that this is not an FRC-specific bug, but the fact that it made it through FRC beta and LabVIEW general testing shows they have no metrics or tests for times, and don't regression test for time increases, further showing that they don't have timing requirements.
-LV also does the downloading, but requries that software on the target be fully initialized or the target will crash and reboot. I am not entirely sure why this is, but it's really annoying.
-There are some cases where LV requires the 'no-app' switch, this has gone down recently but it was really really bad for me in 2012 and 2011. I also managed to get the cRio in an indeterminate state while downloading code at a competition in 2012, and had to re-image the controller in the pit because of it (it should never be possible to lock it up so that you can't just download again and fix it)

My understanding is that both Ethernet and USB are supported on roboRio for downloading code. So it's reasonable that FTP could be used still.

Edit: My time estimates are for LV, include all user code init (fully ready to enable), and radio link.

Re: NI Week Athena Announcement and Q&A Panel
 

Actually by defaults if you look at the white paper on the RT Linux it says that by default it uses WebDAV instead of FTP, which should be faster.

Also I think if NI cannot get LabVIEW deployment sped up, they should teach the teams how to manually deploy the executable. We did this in both 2012 and 2013 and never had a problem, and it always took less then 5 seconds to download new code to the robot. I do not know why labview does not do this by default like the other 2 languages, but it should. Compiling was another story, but that should be fixed.

Re: NI Week Athena Announcement and Q&A Panel
 

Actually, since we switched from LV 8.6 to LV2011/LV2012, the actual downloading is quite fast. However, we have to wait for the robot to fully boot up (and netcomm/user code to fully initialize), and it takes a while to close everything on the target before downloading, and often fails there (requiring us to reboot and try again). In addition, we see a lot of 'Access Denied' errors when LV does funny things (like LV will disconnect but the cRio will still see it connected), and rebooting to get rid of them and download is also really annoying. So if they allowed it to download when VxWorks was up, and we didn't have to fail and reboot so often, it would be fine (for the actual download, not including the compile).

Re: NI Week Athena Announcement and Q&A Panel
 

Wasn't it Bill Gates who said something like 'we simply don't need more than 640k RAM'? How many CPU cycles is too many?The larger artifact was the agreement between IFI and FIRST, which was expensive and unsustainable.

Our 2015 controller? 2014 will look suspiciously like a cRio...:p

Re: NI Week Athena Announcement and Q&A Panel
 

He did not. Or at least, he says he didn't and there is no evidence to suggest otherwise.

Re: NI Week Athena Announcement and Q&A Panel
 

I suppose I can respond to a few of the questions and comments.

The RFP description of boot time is in section 6, point 8. Basically, booted and connected in less than 40 seconds, but requests that it be minimized.

Yes the performance is measured. Yes people care about it. But it is hard to have official times when major features are missing. It isn't like you can simply buy one of these are resell it.

As for ftp, it can be enabled, but by default more secure protocols are used instead.

I've already discussed the issues with deployment. A number of performance issues were corrected, tests improved, and now that 2013 SW from NI is officially released, we can verify numbers all over again.

I'd try to give you numbers for LV 2013, but the cRIO that I have in my possession resulted from a team swap and it apparently needs to be cleaned. Right now it looks like a XMas tree ornament when I plug it in. Swarftastic.

Greg McKaskle