Three or four (maybe five or six, they all run together anymore) years back we had the same code running on two different bots that unfortunately had a number of build differences such as wheel, sprocket and gear sizes. In an attempt to cover for this we found a way to write data the controller (can’t remember now if it was RR or cRio) that was persistent. The program would run and go look at the information on that controller, read it and run with it. It had to be some kind of key name for the data and the contents of the data. As I recall it was a pain in the butt to remove deprecated data as things changed. But it served our purpose. We’d like to do this again to use the same code on drivetrains from different years (obvious differences there) without having to update the code depending on what we download to. Does anyone know what I’m referring to? I’m looking for screensteps on it or something in wpilib maybe? Need a starting point to refresh from.
You are more than likely looking for some form of file I/O. I haven’t personally done it on a roboRIO but I would imagine it could be done with relative ease.
Here is a link on how to do it in Java
Here is a link on how to do it in C++
I would have to do some digging to find how to do it in LabVIEW.
My teams handle it by saving a file onto the filesystem, reading that file at startup, and then selecting which robot configuration to use based on the text file contents.
We used the instructions hereto SFTP into the roboRio and created config.txt at /home/lvuser/
I uploaded our configuration selection file and how it gets called in the main robot file here to a gist.
We are doing something similar using a hashing system to store calculated trajectories on the RoboRIO’s memory that can be called upon during autonomous to avoid calculating paths and wasting precious seconds.
The way I would recommend going about this would be to create a Constants class, and then Constants “Reader” and “Writer” methods that write and read data from a stored CSV file on the RoboRIO’s data storage, the same place where it stores its copy of Realtime Linux. Inside of the RoboRIO configuration tool that is opened through Internet Explorer, you can browse stored storage and even modify it. Have your “writer” method create a CSV file using a StringBuilder and appending that to a CSV file, and then writing it to a constant location, and then have your “reader” class use Java IO’s FileReader to set the values in code equal to the values on the RoboRIO. This way you can easily change your values, and quickly read from them and change your code based on the robot it’s running on.
If you’re looking for something standard, the Preferences class is what you’re looking for. This functionality is also built into NetworkTables. Any NetworkTables entry can be made “persistent” by calling setPersistent() on the entry–what this means is the entry’s value will be saved on the robot into a file called persistent.ini, and the value will be automatically loaded from that file when the robot code starts.
Yeah, Preferences is probably what OP was looking for. We moved away from them as we had issues during competitions where SmartDashboard wouldn’t load, the Preferences view wouldn’t load the pairs properly, or values would get erroneously set.
The recent rewrite of the NetworkTables may have resolved those issues, though.
If you’ve not tried since the 2016 rewrite, yeah, the rewrite completely changed the implementation so it should be a lot more robust and you might want to try it again.
Only sparingly for calibrating PIDs, and not at competitions. I’ll have our teams check it out this week!
We use gson on our robot to parse a JSON file of constants. It’s pretty easy to edit by hand over FTP or interface with other code to make changes.
PREFERENCES!!! that was it. Thanks a bunch. Only used it that one year and we never had issues with it. We’re game to try it again. If issues, we’ll use file read/write. Thanks again!
We take a slightly different approach to this problem. Whenever we have a contant that needs to be different on our practice bot vs. our competition bot, we simply create two constants. At startup, our code looks for a flag (really just a jumper on a DIO port) that’s only present on the practice bot’s rio. Whenever we reference a bot-specific constant, we use a helpr function to pick the right constant based on that flag.
This system means we can swap in a spare rio with very little fuss–which turned out to be a good thing this season as we fried our practice bot’s rio and had to borrow one from an obliging neighboring team!