Parameters file for quick code updates

[ajlapp]

This year we're planning to add the ability to update our most frequently adjusted parameters via a file loaded onto the cRIO.

We're thinking that this will make code changes much faster since we spend a lot of time adjusting setpoints, limits and gains. We'll also be using this same technique to do a scripted auton.

Questions:

Are there teams out there that are using this extensively?

About how many variables are you managing this way?

Did you write any error checking to see if a value is being sent to the wrong place or is out of bounds?

Did you place this file read in "Disabled?"

Can this method actually create a global variable and assign it the appropriate value? I'm currently unpacking a file, reading the "name" and comparing this to the existing global variable name....then writing error info if things don't match.

Can any of this be done in real-time via the dashboard?

Thanks for your help.

[Greg McKaskle]

There are a number of variations that will make this work. It is possible to send the data from the dashboard at any point, and if this is your approach, I'd agree that disabled is a good time to have the data sent to the robot. To be field legal, be sure to use legal ports that will be open on a competition field.

If you want to read a file on the cRIO, I'd do it outside the main loop in RobotMain, perhaps in Begin. I'd read the values and update the globals there.

Greg Mckaskle

[WizenedEE]

One alternative that worked well for our team using labview was to simply have the gains/etc controls on the front panel. Then you just have to remember to set them as defaults (I've forgotten to this so many times...)

Of course, this only worked when we had our programming laptop attached and were "run"ing our code anyway.

[ajlapp]

Is Begin called only once at power up? Or each time you disable?

I'd like to read new values in immediately after updating the files via FTP....without powering down.

Is there any special process supported for what we'd like to do? We're currently unpacking a file one entry at a time and writing the values to global variables. My issue with this process is that it seems very tedious and easy to mess up.

I did devise a simple error check based on the label name, but adding a new variable means adding new code to read it and check ing it for errors.

It would be amazing to support a Parameter File protocol of some sort that generated global variables directly from the file....is it possible to actually create a variable without manually adding it to the front panel?

[JewishDan18]

My team (Team 20) did this. We read in variable to control multiple autonomous modes. We do it while the robot is disabled. Recently, we switched to using virtual switches on he dashboard. We don't use it for anything teleoperated, but I won't rule it out as a possibility.

One thing to do is make sure you have a backup plan if the read fails. Error checking is key here. Don't was some variable set to an undefined value because the file failed to read for whatever reason.

[ajlapp]

Currently the code writes the previous value if it detects an error...it then lights a feedback light on the robot to help diagnose the problem.

I hope to test it very soon.

Can the robot global data be exported to a list of names with values? Perhaps I can do things in reverse order to generate a text file.

[Greg McKaskle]

Begin is called once each time your app starts up. If you want to put the code in Begin, you only need to reboot the cRIO, not repower the robot.

If you wish to redo the globals more often, I'd recommend putting it in a subVI. Then you can call the subVI whenever you like, such as in disable.

If you want to simplify the code needed to update the globals, you may want to consider grouping globals together into larger groups, then look to using XML or another format to encode the values. Then you can use the Unflatten from XML to set all of the global cluster elements at once. The downside is that they are grouped and you'll need to use a named unbundle or similar to be able to access the elements of the global.

An alternate pattern for this is to use something like the refnum registry uses. You need to determine what the output types are and group globals by type, but then you can decide to use the runtime name and replace the globals entirely.

Greg McKaskle

[apalrd]

...I was actually writing code to do this not too long ago...

My plan was to save an array of constant/name pairs. I currently use something like this to lookup non-setpoint constants for the elevator (such as gains, limits, sensor calibrations, etc.) on a per-robot basis. What it basically does is stores an array of name/comp/pratice values, and finds the right one each time the variable is requested. I have no speed issues doing this, although I am only using it for about 20 constants.

I use a scripted autonomous system (Beescript) that allows me to write an auto script that looks something like this:

#Go To Score HI
ELEV_SET_STATE score_hi
# Drive Straight 167" 6ft/sec
DRIVE_STRAIGHT 167 6
#Score (no arguments)
ELEV_SCORE

But due to the modular design of the interpreter, the list of possible commands (and the functions for these commands) is separate from the interpreter itself (I actually debugged all of the Beescript code using a function that popped up with message boxes in a blocking way). And I was thinking of just adding a command to set constant, then running the same interpreter to read the file. Writing the files would be even simpler - Just print a new line for each constant in storage, plus a few comments here and there.

Realistically, the LV interface is good enough for fine-tuning work. It gives me a UI to change variables and I don't have to write any code at all (always a good thing). What the script gives you is the ability to change constants rapidly, without re-downloading. The benefits are HUGE - seriously. This is awesome.

@ajlapp, feel free to use Beescript (get it here).

[plnyyanks]

For storing parameters on the cRIO, I think it would be a good idea to use INI files, which LV can handle pretty well. It's a nice section/key/value system that seems pretty good for storing robot parameters. (DISCLAIMER: I've not actually used this, my team is just planning on doing so next season. Your individual mileage may vary)

Read up on using configuration files in LabVIEW:
http://zone.ni.com/reference/en-XX/h...tion_file_vis/

And maybe on INI Files themselves:
http://en.wikipedia.org/wiki/INI_file

[Greg McKaskle]

I agree that ini files are a good option. I believe they work on the cRIO, but you should test it. BeeScript sounds like a great approach.

I'm curious if anyone downloads just their autonomous code changes? They are dynamically loaded, but built into the startup. I suspect that a small change to the build script would allow the compiled auto to be deployed, leaving the other code unchanged. Has anyone experimented with this?

Greg McKaskle

[Joe Ross]

Originally Posted by Greg McKaskle

I agree that ini files are a good option. I believe they work on the cRIO, but you should test it.

They do work, we've used them.

[ajlapp]

Joe,

Care to expand on your usage?

My CSV file approach seems to be working fine right now, but INI might be more scalable.

Also, Beescript does look great. We however are using the HibnerScript system (I just made that name up) presented by Chris Hibner at last year's World's event.

HibnerScript

His approach is remarkably simply, has a built in simulator and follows a state machine approach that I really believe in....so far all of his material has been rock solid. I'm very excited to implement it.