Check Roborio Serial Number at Compile Time?

[Gandagorn]

We have a project we’re working on where we want to run two robots with similar subsystems (different constants) off of one codebase. We want to switch the constants based on which roborio we are running on (based on serial number), but we also want the deployment of the code to halt if the serial number that the code is deploying to doesn’t match the one we specify in code. This could happen if we have to swap a rio for some reason. Is it possible to check the roborio serial number at compile time?

Thanks!

[truher]

the compile step isn’t aware of any roboRIO connection at all, so there’s no way to do exactly what you’re imagining, but you can make the robot behavior depend on the roboRIO serial number.

we use a single code base for all of our robots, and use the serial number of the RoboRIO to select mechanism implementations, or, as you suggest, specific constants. for example, we have a gyro interface and a few implementations, and we select which implementation to choose using a “switch” statement in a factory. it’s not a compile-time thing, it’s a run-time thing. there’s only one set of code to deploy, it just does something different based on the serial number it’s running on.

[Gandagorn]

Yeah, there are a couple of thread on CD talking about runtime checks in the Rio serial number. We aren’t so sure because of the edge case where you have to replace your Rio and end up deploying the wrong code or getting a runtime error.

[truher]

we have a class called “Identity” that maps the serial number to an enum that the code actually uses, so if you have to replace the rio, it’s a one-line change to adjust the code to behave the same way with the new serial number.

IMHO it’s way better to just have one code base, so that the phrase “deploy the wrong code” no longer ever happens. we don’t even use branches. there is ONE code base.

[bovlb]

I’d recommend that you have one codebase and switch the constants based on a file you create on the roboRIO.

VH-109 Radio Hazard

Not exactly what you asked for, but for robots with LED strips attached, it would certainly be possible to change them without enabling the robot. You could even make them change automatically when DriverStation.isDSAttached() returns true. Another trick is to “name” the robot by creating a file (in a consistent location) on the roboRIO. This name can then be sent to the dashboard and displayed for the operator. The same trick can also be used to support two robots on the same code base, fo…

[truher]

i’ve seen this pattern too, and i’m puzzled by it, it seems like having two places to look is worse than one. what’s the argument for it?

[bovlb]

I’m not sure what you mean by having two places to look. The file simply identifies the robot, and then the codebase has different constants for each robot.

[truher]

oh, you mean the file just has a key in it, i see.

[Gandagorn]

Just to insert some context here: Our team is running a V1/V2 strategy this year, meaning that for early week events, we bring our V1 robot, and for later events we bring our (hopefully) better V2 robot. We are worried that at events, we will end up in a situation where we have to swap a rio for one reason or another, which results in a runtime error or constants and such being instantiated incorrectly to the other robot.

@truher

we have a class called “Identity” that maps the serial number to an enum that the code actually uses, so if you have to replace the rio, it’s a one-line change to adjust the code to behave the same way with the new serial number.

IMHO it’s way better to just have one code base, so that the phrase “deploy the wrong code” no longer ever happens. we don’t even use branches. there is ONE code base.

Yeah, we agree that one codebase is the way to go, but we have some reservations about deployment to the wrong robot when roborios get replaced. We may not have time to implement that one line adjustment before we have to be out on the field.

@bovlb

I’d recommend that you have one codebase and switch the constants based on a file you create on the roboRIO.

We had considered this too, but have the same reasons to doubt its robustness. If we have to swap a rio, the file needs to be added back to the new rio, which may be forgotten in the hustle and bustle of a busy pit.

We had also considered defining an empty DIO port on each robot’s rio as the port that tells the robot which code should be running, which may be the best option given our team’s robustness requirements. A dupont connector and some hotglue would do here I think.

Overall, the issues we are trying to solve are very niche and lie outside the realm of probable outcomes, but even so, if it is possible to check this at compile time that would be our preference.

[bovlb]

@Gandagorn

We may not have time to implement that one line adjustment before we have to be out on the field.

@Gandagorn

the file needs to be added back to the new rio, which may be forgotten in the hustle and bustle of a busy pit.

You get to choose what happens when you can’t identify the robot. Refusing to run is probably too hard-core for you, so you should pick one robot as default, and emit warnings (maybe a Persistent Alert). You’ll see in the thread I linked that I recommend putting the robot name at the top of the dashboard.

[Gandagorn]

@bovlb

You get to choose what happens when you can’t identify the robot. Refusing to run is probably too hard-core for you, so you should pick one robot as default, and emit warnings (maybe a Persistent Alert). You’ll see in the thread I linked that I recommend putting the robot name at the top of the dashboard.

That makes sense. We know which robot is going to compete before the event starts, so setting the default is a viable solution. A persistent alert and logging the robot on the dashboard would also help in debugging when we inevitably forget to fix the serial number after a rio swap or add the file to the new rio.

Thanks everyone!

[truher]

hm, yeah, I mean, you’re going to do a pit check anyway, you can make the code just fail the pit check if the serial number is wrong. the error message could just be the instructions to fix it.

[dan]

You could probably add something to the deploy Gradle task that will first check the serial number of the roboRIO, and then fail if it’s not the expected one.

[Gandagorn]

We tried SSHing into our rio2 and we found that the serial number was located at:

/sys/firmware/devicetree/base/serial-number

So we’ll try that in our gradle task.

The weird thing is that on a spare rio1 we had, we can’t find the serial number at the same path. Any ideas where it could be on a rio1?

[sokoloff]

I would recommend that you at least explore using the RoboRio web interface “comment” box, the contents of which get stored on the Rio in /etc/machine-info or is accessible from the getComments call.

That gives you a no-code-change way to replace a Rio.