So does this mean we HAVE to run our code off an SD card?
Looks like no additional CAN busses, but bumps to several specs, which will be nice. The next radio will be hopefully a big deal when it happens. Overall, looks to be pretty similar.
SD card integration is an interesting idea, but given how flimsy those cards can be I don’t think switching them out all the time would be a good idea. Love the idea of being able to use it as a hard copy of known good code though, it’ll be interesting to see how that goes over time.
Non ziptie mounting options would have been nice, or maybe some form of latching/shielded ports for some of the IO onboard. I know this is really only meant to be a power boosted version, but some mild acknowledgement of known issue points would have been appreciated.
My read on the situation without further context is a yes*. I think you could download code directly onto the roboRIO’s onboard storage, but this gives you a safety valve to contain a code failure and have known good code ready to swap to if you get stuck.
I love the idea in theory, but am absolutely terrified of the idea that our robot’s code will rely on, what are IMO, very delicate pieces of hardware. I have also had horrible experiences in the past (be it with cameras, or more recently, 3d printers) where they corrupt more often than you’d like them to…
Here’s my hopes:
- You can still download code directly to the roboRIO and not be forced to run entirely off the SD Card
- It’s easy to wipe bad code completely off the RIO, or an SD Card with Robot Code takes priority.
More info to come, hopefully.
Per Peter on the WPILib team, there is no internal memory for boot or Robot Code.
The RoboRIO OS and the Robot Code run from the SD card only.
Also, as equally totally unclear in the blog post, the SD is of the micro variant.
I’m concerned that teams may buy cheap or knockoff micro SD cards and run in to issues we’ve never seen before. Hopefully a high quality one is provided.
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?
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.
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.
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.
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…
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…
…
…
… … … …
… … … … …
more
…
…
…
… … … …
…
… … …
… …
… … … … … … … … … … … …
… …
… … … …
…
…
…
…
… … … … … … … … … …
… …
… … … … … … …
…
… … … … … … … … … …
… … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …
… … … … … … … … … … … … … … … …
…
…
…
… … … … … … … … …
… …
… … … … … …
… … … … …
…
… … … … … … …
… … …
… … … … … … … … … …
… … … …
… … … …
…
…
…
…
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…
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.