NI Guest Blog - roboRIO 2.0

And here I was thinking it was a normal size SD card. Now I not only have to worry about an SD card becoming corrupt or damaged, I must also worry about loosing it in the depths of the robot while changing them. FANTASTIC!

Also, a follow up question. Will we be able to write to the roboRIO 2.0 (SD card installed of course) from our computers like we would on the 1.0? Or do we need to remove the SD card each time, find an adapter, and write to the SD card directly?

2 Likes

I’ll also confirm that this is what the updated device tree, defconfig, and comments from the various NI Linux github repos have indicated. Along with support for the ext4 filesystem.

11 Likes

Yes, you can completely image and do everything with USB or Ethernet just like before. There is no requirement to ever pull the SD card if you don’t want to.

8 Likes

We have an alpha unit we were provided for CAN testing - since a lot of this is being discussed on Discord by other folks already anyway I figured I’d summarize for clarity:

  • The SD slot is a microSD slot
  • The entire roboRIO image is contained on the SD card.
  • I don’t know if this will be the same on the final units, but the alpha unit came with a 4GB industrial SLC microSD card. (aside: I highly recommend that teams who want to buy additional SD cards get SLC cards for robustness reasons)
  • Imaging the SD card directly with your PC is great, but you can also image by putting the SD card in the RIO and then imaging over USB like with the RIO 1.0.
12 Likes

Thanks for the insight! Very glad we have the option to push to the robot like on the 1.0.

Definitely hesitant about these “improvements”, but excited to see where this new hardware takes us!

Just gonna leave this here from when I found out about the GitHub stuff…

8 Likes

not thrilled about the switch to running solely off a uSD card. Seems contrary to

Our key priority was resolving what we call ‘match-breakers’—anything that forces a team to miss a match, or be bypassed in a match, or have a sad robot sit there for a match.

But, I don’t have all the data NI/HQ does to know the frequency of a rio having bricked internal memory. Might be an odd year or two where the new electronics go on the practice robot and our old rios go on the comp bots, haha.

9 Likes

My guess is that it is a lot easier to swap out an SD card than to push code to a robot

I have stood next to many a teams on deck (ours included) trying to push a small change before the match.
Now that we switched to java. That takes all of 15 seconds to hardwire connect/push/disconnect.

But when we were on LabVIEW…


… … … …
… … … … …

more




… … … …

… … …
… …
… … … … … … … … … … … …
… …
… … … …




… … … … … … … … … …
… …
… … … … … … …

… … … … … … … … … …
… … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …
… … … … … … … … … … … … … … … …



… … … … … … … … …
… …
… … … … … …
… … … … …

… … … … … … …
… … …
… … … … … … … … … …
… … … …
… … … …



7 Likes

Forgive my naivety on the subject, but how is having to compile/write your code to an SD card any different than having to compile/push to the robot directly? Having the code stored on an SD card will not change the fact that teams will still wish to make last minute changes to code while in que.

1 Like

The blog post lays out this particular answer pretty clearly. Have an extra SD card with a “known good” version of code, so that if your last minute push or untested code is causing issues, you can just swap out the SD cards to the proven commodity.

2 Likes

Looks like I may have misinterpreted what @Fields was suggesting. You’re absolutely right that having an SD card ready to go with a known “good code” will be faster than having to boot the robot up, connect and push the code should the team determine the “new code” to not be ready for use yet.

The way I read their post though was they were suggesting that making their last minute changes and pushing them to the SD card for use that match, was faster than just pushing straight to the RIO.

After thinking about it though, that case could be made in favor of the SD card too. Instead of having to boot the robot, wait for connection and then push the code, you could write to an SD card (that would presumably connect to your programming computer faster than the robot could) and then just install it on the RIO without ever having to power on your robot…

3 Likes

I’m a little concerned this is just adding an extra (and largely unnecessary) failure point to the RIO during match play.

It will be possible to tape over the slot / 3d print a guard for it, but this seems contrary to the intent that they’ve explained for it, like Andrew said.

10 Likes

For the scenario outlined in the post, it seems to me the much more ideal solution is to have internal memory, but priority boot off the SD card. You can put your “new” code on an SD card, but if you chicken out or find an issue, you pull the SD card and it boots to the known good code on the Rio.

My concern may be unfounded, but I just don’t have a lot of confidence in the SD card interface for the environment they’ll be put in. Seems much less reliable than a memory chip soldered to the board. if the issue was RMAs with bricked internal memory than the teams can run off the SD card instead.

5 Likes

Everyone out here underselling the big change.

Look at that new logo! #branding

9 Likes

Now we have to make sure we don’t leave the micro SD cards at the shop. Another thing for the checklist.

2 Likes

one of these spray painted safety yellow with a bright orange label.

2 Likes

I hate bricked RIOs and the USB recovery file shenanigans. It put us at a significant delay last season given the issues with the imaging software (that we missed initially) and then the new NI support being forum based didnt help. I like this update since it helps that issue but time will tell on that SD card slot.

3 Likes

Corrupted internal memory isn’t the only use case, and probably a pretty minor one in my opinion. This is a big improvement for any team that doesn’t have a spare RoboRIO. Now you if you have to replace it, you get one from spare parts and insert your SD card and you’re ready to go. No reimaging required. I’ve definitely seen teams miss elimination matches when they were waiting for a roborio to reimage after replacement.

One of the most common things a CSA does is help teams reimage when they come to inspection with the wrong image version. Right now the process is to have the CSA install the update with the right image (5-10 minutes) and then reimagined the roboRIO (5-10 mins). I could see CSAs carrying around an already imaged SD card and swapping it with the team, cutting out the second half of the process. Or they could load the image from their own computer, rather then going through the USB imaging process, which is probably much faster.

13 Likes

I think the microSD thing is a fantastic change. Obviously there is a potential failure point there, but the benefits seem huge. Backup images of team code will be a lifesaver; every roboRIO becomes interchangeable quickly. I really like potentially being able to “load code” just using an SD card reader on a laptop; much easier to manage than fishing out the tether all the time and plugging / unplugging stuff. Image / firmware updates are potentially fast and easy instead of a networking ordeal that takes forever. There’s a lot of good that can come from this - particularly for the kind of teams that struggle with software and controls in the first place.

3 Likes

Thanks for providing a better use case than what was covered in the blog. I can certainly see the time saved when needing to get a spare Rio.

I think I’d still prefer a priority boot to SD card with a backup boot from internal memory, but time will let me know if my concerns with the interface to external memory or concerns about teams losing their SD cards are overblown. They very well may end up being non-issues.

2 Likes