Rapidly editable Autonomous Mode

[Charlie]

Are there any teams out there that you know of that used a non-compiled file to feed their autonomous vi values?

If how did you get it onto the cRIO, and what directory on the cRIO did you store it in?

I plan on using a text file with the values

[RyanCahoon]

This forum thread at NI.com tells how to do file I/O using WindRiver, and how to get the files on to and off of the cRIO. If you want to use LabVIEW, you can similarly use the standard file I/O functions; documentation on them can be found here. For more information on the specifics of file paths, getting the files on and off the cRIO, etc, have a look around the existing thread on Chief Delphi, this topic has been discussed several times before.

--Ryan

[Ken Patton]

Originally Posted by Charlie

Are there any teams out there that you know of that used a non-compiled file to feed their autonomous vi values?

If how did you get it onto the cRIO, and what directory on the cRIO did you store it in?

I plan on using a text file with the values

We were unable to get ours working, due to not enough time to learn how to read the file (including not knowing where to put it on the cRio). Instead we used an array in disabled.vi. This worked very well, and we were able to have many autonomous choices to switch between (if you paid close attention in the last four runs at the MSC, we never used the same one twice).

The non-compiled solution is very high on our list of summer projects. we definitely want this to be ready for 2010. We liked using LabView and will most likely continue to do so, but we didn't like the long build times.

Ken

[nathanww]

What we found is that for our robot there were a fairly small number of "optimum" paths--go directly to our outpost, go directly to our fueling station, go the the middle of the field, etc., and a lot of "suboptimal" paths that we could use to get to the same position if the optimal path was blocked. SInce it would be hard to determine a suboptimal path ahead of time, we used a combination of a three-position switch(for our optimal) and a bug algorythm(for our suboptimal)

[Stuart]

I know that 1296 fed their Crio a text file of sorts via the FTP.

[Joe Ross]

The code that 1629 released as part of the beta test reads and writes to files. The thread about it is here: http://forums.usfirst.org/showthread.php?t=10274

Like Ryan said, it uses the standard file I/O VIs, so you can use any LabVIEW tutorial for file I/O to learn how you do it, and you can prototype it on your computer (very handy).

For the file path, use c:\ and it will put it on the root directory of the cRIO, which you can access by FTPing to the cRIO.

[Greg McKaskle]

The long build times will definitely be reduced. It was in work just before Atlanta, but too risky to release at that point.

The file solution has two flavors. Number one downloads a description file, could be XML or lines of text or binary. Choose your own location, /tmp is a reasonable location I think, and then ftp the file using an ftp client. You can write tools to put a nicer UI on the ftp operations if you like.

The second downloads code that is dynamically called. For LV that would mean downloading a VI and then changing either the framework or the autonomous VI to dynamically call the VI by reference. Again, you ftp the file to the cRIO to a known location, and the dynamic call code will use an Open VI Reference with a path to your VI, and will then invoke the run method on the VI.

For the C++ users, this is equivalent of downloading a different .out. I haven't done this yet, but it should be possible.

Greg McKaskle

[Charlie]

the code is done and waiting to be tested on the robot, will post as soon as i get out of school

[Greg McKaskle]

Originally Posted by Charlie

the code is done and waiting to be tested on the robot, will post as soon as i get out of school

On the LV team, we refer to code that has been written but not tested as "All but done". It could really be done, but since there is no proof, it is more likely that it is just beginning. When relying on other people's code, it is useful to be able to tell the difference.

Greg McKaskle

[kramarczyk]

Originally Posted by Greg McKaskle

The file solution has two flavors. Number one downloads a description file, could be XML or lines of text or binary. Choose your own location, /tmp is a reasonable location I think, and then ftp the file using an ftp client. You can write tools to put a nicer UI on the ftp operations if you like.

Greg McKaskle

I noticed that LV has a set of FTP tools on the menu under Addons -> Internet -> FTP, but when I try to drop them into the VI they cannot find all the requisite pieces to run. The missing location seems to be <vilib>:\addons\internet\utils

For the FTP-put vi the specific missing files are...
utils\tcputil.lib\TCP Write Stream.vi
utils\tcputil.lib\TCP Create Arbitary Listener.vi
utils\tcputil.lib\TCP Read xTP Reply.vi
utils\inifile.lib\Read Internet INI.vi

So, are these files supposed to be in the FRC version and I have somehow goofed my library? I don't think I screwed anything up, but this is software and I am a mechanical monkey. If they are not supposed to be there then why are the menus included?

[Greg McKaskle]

That is just what I was wondering the other day when I tried to use them. I think it was an oversight, and some of the dependencies were not shipped with the FRC version. I expect them to be there next year.

Greg McKaskle

[Luke Pike]

I learned a little while ago that LabVIEW can flatten any datatype (numbers, arrays, clusters) into an XML string based on the LabVIEW XML schema and unflatten the XML string back into the original datatype.

You could make a vi on your computer that creates your autonomous mode (a cluster typedef that your robot code can use in autonomous, values for drive motors and the like) based on user input and write it to an xml file on your computer.

Then, FTP the file onto the cRIO and have your robot code read in the file using the "Read XML File" vi and unflatten the resulting string with the "Unflatten XML String" vi, using your typedef to tell it what datatype to create. I'd make a picture demonstrating it, but I don't have our team laptop right now. Search ni.com and I'm sure you could find an example of what I'm talking about.

I haven't done this, but it could be an effective way to change the autonomous mode without having to recompile and download.

[Charlie]

ok here it is

if you notice any problems or errors let me know or any suggestions to improve it