What are you doing different from last year?

[JohnGilb]

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)

Anybody else planning on making some big changes?

[Greg McKaskle]

All of those sound like good enhancements.

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.

Greg McKaskle

[plnyyanks]

Originally Posted by JohnGilb

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)

Anybody else planning on making some big changes?

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...

[JohnGilb]

Could you elaborate a bit? I'd like to know how other people are approaching this problem.

[plnyyanks]

Originally Posted by JohnGilb

Could you elaborate a bit? I'd like to know how other people are approaching this problem.

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.

[JohnGilb]

It all sounds great!

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:
1) Robot reads constants from XML document on cRIO
2) Robot unflattens from XML, turning it into a typedef for use internally
3) 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
4) 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)
5) 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.

[plnyyanks]

Instead of XML data, can I suggest using an INI File for storing robot parameters? There's a good thread on using parameter files here.

[Jester]

Originally Posted by plnyyanks

Instead of XML data, can I suggest using an INI File for storing robot parameters? There's a good thread on using parameter files here.

Thanks for the link! I was actually unaware that .ini files could be used for value filling.

My changes as a 3rd year programmer:

• Utilizing autonomous functions within the teleop period (automated aiming+velocity control)
• Using more sub VIs to keep everything clean and tidy
• Customizing the dashboard to only display what we need
• Using more I/O, last year we used only the pressure switch :/

[JohnGilb]

Originally Posted by plnyyanks

Instead of XML data, can I suggest using an INI File for storing robot parameters? There's a good thread on using parameter files here.

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.

Are there similar benefits when using INI?

[Jester]

Originally Posted by JohnGilb

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.

Are there similar benefits when using INI?

It seems to me that ini would be an easier to read outside of labview, but the intellectual value of both seem similar.

[plnyyanks]

Originally Posted by Jester

It seems to me that ini would be an easier to read outside of labview, but the intellectual value of both seem similar.

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):

[pidConstants]
p=.1
i=0
d=.01

[drivePID]
p=.2
i=0
d=.02

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.

Originally Posted by JohnGilb

Are there similar benefits when using INI?

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.

[jhersh]

Also look in the LabVIEW for FRC 2012 examples. There is a new example to show how the Configuration File API can be used.

[Joe Ross]

Originally Posted by jhersh

Also look in the LabVIEW for FRC 2012 examples. There is a new example to show how the Configuration File API can be used.

What is the example called?

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.

[jhersh]

Originally Posted by Joe Ross

What is the example called?

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.

[plnyyanks]

Originally Posted by plnyyanks

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.

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.