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?
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.
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.
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…
… … … …
… … … … …
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.
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.
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…
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.
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.
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.
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.
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.