I was curious what architecture changes veteran LabVIEW teams are planning.
For us, here are the big items:
Increase encapsulation of robot systems (last year’s robot was a tangled mess of dependencies, we’d like a much cleaner way for the various parts of the robot to communicate)
Read/Write key robot parameters to disk, and modify them on the fly from the DS Dashboard (don’t want to recompile the code if we need to change a PID constant)
Read autonomous program from disk (again, want to limit recompilation)
User Events for communication between autonomous and the robot core (allowing for much easier request/response between the two, and decoupling them since the event acts as an interface)
I’d also add that the teleop does little beyond calculating and updating set points and updating state machine triggers. If you can build in a logging capability, it will likely pay for itself in understanding how the robot is running.
Related to logging, the framework code has a file called Elapsed Times in the Support Code folder. If you place it into your teleop, vision, and other control loops, it will give a very easy way to monitor rates of the robot system.
We were thinking of doing something very similar to this - our other programmer and I have spent hours talking about a better way to structure our code to allow for a lot of this. We have a pretty good structure mostly written now, and we’ll see how it goes from there…
Well, we’d like to first have autonomous (hybrid) code much more integrated with teleop code. Ideally, we’d have some sort of autonomous script on the robot, which would be put into a state machine to execute autonomous tasks. Now, these “auto states” could also be accessed in teleop for increased automation. Make sense?
As for other stuff we’d like to do, we’d also like to have a lot of parameters stored in (INI?) files on the robot for easier loop tuning. Last year, I actually wrote some FTP VIs to update PID constants on the fly, so we might use something to that extent again.
As for other stuff, a lot of it isn’t really that well fleshed out yet (we have a good idea in our heads, but we haven’t written too much code yet). If you have any questions about specific code parts, I’d be happy to answer them as best I can.
One thing I’ve been struggling with is along the lines of saving/updating “ini” files on the robot. Ideally you’d be able to modify key robot parameters from the Driver Station dashboard (so you don’t need any additional computers).
I’ve been trying to figure out the best way to do this. My general requirements have been as follows:
-No extra computers are needed to make on-the-fly changes
-Newer versions of Robot Code (that change the # or type of constants) should not require recompile/redeploy of DS Dashboard code
So far, here was what we had come up with:
Robot reads constants from XML document on cRIO
Robot unflattens from XML, turning it into a typedef for use internally
If robot gets a request from DS as to what the current constants are, it flattens the tyepdef to XML and sends it as a string
DS can modify the string (typedefs flattened to xml are quite human-readable), and send back a new one (after doing some quick verification to make sure it’s still valid)
Robot receives the data, saves it, and applies the new constants to the running program
Sending XML helps decouple the DS and the Robot, but at the cost of needing to do some kind of XML validation again somewhere. I’m wondering if there is a more elegant way to do this.
I’m still reading some of the links in the other thread, but what would you say is the comparative advantage of using INI over XML?
One of the things I like about the Flatten/Unflatten from XML is that all my variables are strongly typed in the robot, and I can reuse common names for things like PID gains since their parent typdef has a unique name. In addition, any changes I make to the typedefs themselves are transparent to the flattening process, so I don’t need to make additional code changes.
LabVIEW actually has a whole palate for reading and writing INI files. I personally like them because they’re organized into sections, and have an easy key/value system which can easily be parsed by LV.
A sample INI File is like this (with two sections, and associated key/value pairs):
In LV, you can work with different sections independently, and easily read/write to your files. Take a look through the Configuration Files Palate (Programming -> File IO -> Configuration File VIs). I also think there are some examples installed by default that highlight their use.
Now, you could also use XML files to the same result, and I certainly won’t stop you from doing that, but my personal opinion is that it’s best to use an INI file in this situation.
Actually, I’m not exactly sure the answer to that question. I know you can set the default value for data read from an INI file, but I’m not sure if/how to do it using a TypeDef. You might have to write a subVI. Hmmm, I’ll have to think about that one.
I prefer ini files more then xml files for settings. I find ini films easier to read in any text editor. This biggest advantage is the free openG ini toolkit. I use a single cluster with all my save data, and just write it into the toolkit VIs. As you cluster evolves, you don’t get file mismatch errors. The LabVIEW built in XML primitives will error out in this case. To me this is big, because software always grows and eventually will cause the saved data cluster to change.
Back to your original question:
All most all of our autonomous routine this year should calls to subvi’s. Anything that can possibly be used more then once will be in a subvi so that hopefully easing our debugging, and cutting down repeatedly writing the same task(something we did alot of last year).
We are also working with are electrical team to build a test bed with out of just motors and sensors. This way we have a way to make sure all of code works with out having to worry about the mechanical issues.
The technical change is to alter the vision code more to increase the speed. Our team has yet to be happy with the speed the vision system runs, but we think it can be slimmed down to run better in telop.
Here’s your stupid Phil moment of the day. I got an answer to this about 10 minutes after I last posted, but didn’t get the chance to sit down an do it.
To do this, all you have to do is flatten your data to a string and write that to the INI file, and then read it and unflatten it (just like you would with XML data). The only problem is that you can’t read/edit the INI file in a text editor, but that problem is there whenever you use “flatten to string”. Attached is some sample code to illustrate what I mean.
I didn’t see anything in the FRC section that seemed like it. Searching for Configuration found the Write Configuration Settings File and Read Configuration Settings File in Fundamentals\File Input and Output.
I’m not sure where it is in the example finder, but in the file system it’s under examples/frc/file/read and write preferences or something close to that.
