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.

[SuperS_5]

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.

[mesamb1]

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.

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