RoboRio Losing WPILib Preferences

[kylelanman]

Team 2481 is trying to use the Preferences class in WPILib this year to store persisted settings rather than using our own similar solution from previous years. The smart dashboard widget is primarily what made it appealing. We are storing things like encoder offsets and PID values for our closed loop controllers.

Modifying code and redeploying works as we would expect. The settings we put into the preferences are persisted to flash and they load back up when we relaunch our program. For what it is worth we are calling save when we change settings.

When the robot is rebooted or power cycled it is hit or miss whether or not our settings get completely blown away or if they load up. About 1 in 3 reboots we loose our settings. The settings all still show up in the SmartDashboard but in order for the robot to actually use them we have to change them slightly then change them back to the actual value that should have been persisted.

Has anyone else experienced similar results or is this problem unique to us.

Thanks in Advance!!

Kyle

[bob.wolff68]

That sounds a bit strange. I'm sure it's frustrating! I wonder if the preferences mechanisms under the hood are not yet ready when you're trying to access them programatically. Maybe doing a few experiements...

- Assign a button on a joystick to load the values and print them out or display them. When you see they are not loaded, wait a minute and then use the joystick button to load them. If this works, then it's a bug in the preferences allowing the load to happen too soon. Just a hunch.

- Another thought - if you store a preference item ... call it MAGICCOOKIE and set it equal to something you know - like your team number - or a string like "FRC"... then when you load preferences, you could immediately check for your MAGICCOOKIE value being correct. If it's not correct, you could Wait() and try again - and again - for some period of time. If this solves/heals it in a few trys / seconds upon initialization, this could work for you.

My team did use preferences a few years back but found only strings to be functional and so we used strings and sscanf() to scan those formatted strings into variables. I doubt the same issue is here but thought I'd throw it out there just in case it rings a bell for you.

bob

[kylelanman]

Good Call.

We are currently using Preferences::GetInstance().Gettype("key", default) in the constructor of static instances of Subsystems.

We confirmed with printf that the values being returned are the defaults.

Looking at the source for Preferences we found a potential race condition such that the .Gettype() call gets the lock on m_tableLock before the ReadTask is fully spun up. If this occurs then the values are retrieved prior to being loaded from the file.

One solution would be serializing this process and not forking another thread/task to read the file.

The other solution would be to use the Contains("[i]key[I/]") and Wait() as you proposed in a loop.

Thanks Again!

Kyle

[bob.wolff68]

Excellent to hear a confirmation there. We had a problem with network tables a few years ago which was a race condition too. We actually had to play around with how we started up and initiated things in order to "tease" it into not winding up in the race condition.

[MrRoboSteve]

Kyle -- I don't see a bug report for this -- could you enter one?

https://usfirst.collab.net/sf/tracke...cker.4_defects

[Ken Streeter]

Originally Posted by kylelanman

We are currently using Preferences::GetInstance().Gettype("key", default) in the constructor of static instances of Subsystems.

We addressed this issue in our code by moving the calls to Preferences.getInstance().GetFoo() to not be in the constructors of our subsystems, but instead in an "init()" method for the subsystem. The "init()" method is called out of robotInit(), which is quite later in the startup sequence.

Below is our current robotInit() which shows the calls to init() in our subsystems that have some "late initialization" needs.

    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
    public void robotInit() {
    	
      System.out.println("robotInit");
      SmartDashboard.putString("Auto Prog",  "Initializing...");
      
      DriverStation.reportError("About to construct Autonomous Subsystem... \n", false);      
	  autonomous = new Autonomous();
      DriverStation.reportError("Done constructing Autonomous Subsystem.\n", false);
      
      DriverStation.reportError("About to construct OI... \n", false);      
	  oi = new OI();
      DriverStation.reportError("Done constructing OI.\n", false);
      
      // initialize the subsystems that need it
      drive.init();
      elevator.init();
      
      // instantiate the command used for the autonomous period
      autonomousCommand = new RunAutonomous();
      DriverStation.reportError("Constructed auto command.\n", false);
      SmartDashboard.putString("Auto Prog",  "Done.");
      Autonomous.updateDashboard();
    }

[kylelanman]

I didn't realize this thread picked back up....As we were doing additional testing we ran into instances where calling save was not actually saving the file. We verified this with 'watch -n1 cat filename' in an ssh session. At that point we ripped out Preferences and used our own implementation from last year because we knew it was reliable. I will try to submit a bug report in the next couple of days with the details.