Programming team infrastructure
 

Hello programmers of Chief Delphi. I am a returning programmer from TaRDIS 5416, a second year team. With that being said I would like to ask a few questions about some team infrastructure so we don't have quite such a hectic kickoff we did in our rookie year.

1: How does one go about creating libraries in Labview for Labview? I know there are some tutorials in this but the seem to be either outdated or for porting a .dll from another language such as C.

2: What are some possible pluses and minuses of using an Arduino board on the robot? Would it be more beneficial utilizing the C++ functionality of the RoboRIO?

3: How do you train new programmers? We have started a video series explaining the basics of Labview and Arduino coding (soon to be available to the public) and I was wondering if there was anything you do that we could incorporate into our videos.

4: We already have a cloud based (Google Drive) version control system in the works. Is this an acceptable alternative to using software that somebody would have to download?

5: Are there any important questions I missed to possibly build a solid programming team?

Re: Programming team infrastructure
 

those are great questions, Brian. As a 3rd year team member, I have written code in both LabView and Java, and I personally prefer the latter. As your team progresses and builds a strong programming team, I would recommend switching to a text-based language. As for your questions:

1: I would suggest creating actual LV files, build them on a basic robot code base, and copy them to this year's code. Since NI has not released LV 2016 updates, there may be some changes that will cause major problems.

2: Arduinos are an excellent way to expand some of the features on a robot. Our team personally uses them for lights, but they can be used for a variety of situations. Like I mentioned before, I personally prefer Java over LV, but using cpp is very similar. If your programmers are willing to take up the challenge, it can be very beneficial in the long run.

3: Our team has a unique opportunity of having more than 60 active members. This also presents a challenge, because 20 programmers would be counter-productive. Initially, we have any prospective programmers learn the basics of java. Using standard, robot-free java, we teach a classroom-style programming basics for about a week. After that, some people decided to switch to other sub-teams. Next, we taught robot programming basics, using LabView, to show just how code interacts with robot. Finally, all the new members began to program Hands-on with older robots, to teach them how programming actually works. I would suggest using a style somewhat like this, adapted to your teams needs. No 2 teams are the same, but sharing ideas helps. I would also suggest looking at other videos just to get an idea of what others are doing as well.

4: Although google drive is great, I would suggest using github. In personal experience, once the code is set up, it is by far the most efficient system there is. Code can be branched, edited, and then merged into the master branch. Also, cloud code saving is far easier.

5: Productivity. Although programmers need laptops, they are the biggest detriment to a programmer as well. Our programming laptops have only 2 things installed, git and Eclipse. This does help, but you cant much stop the internet. I always try to give our programmers the friendly reminder that "Robots don't program themselves"

I hope that this response is not too lengthy, but will help your team a lot. Any more questions you think of, let me know.

Re: Programming team infrastructure
 

For #1, I think what you are asking is "How do I add VIs so that they show up in the palette, similar to WPILib?"

First, write your VIs. Test them and drag them from the project window to see that you are happy with how they work, both top-level, and as subVIs.

To add them to the palette, the simplest is to put the folder into the user.lib directory. The icon and name from the VI will be used to create the palette, hovering over will show the documentation for the subVI. For basic hierarchy of functions, put them into folders within user.lib. If you'd like to get fancier, you can edit the presentation within the palettes using the Palette Editor. The palette editor is accessible from the Tools menu>>Advanced>>Edit Palette Set. By the way, when you update the folder, it may not show up in the palettes right away. To update the palette cache, you can either restart LV or open the Palette Editor and Cancel.

The Palette Editor hides your document windows temporarily and pins up one or more palette windows. You can navigate the palettes more or less normally, but you can use right clicks to modify icons for folders, drag things around, etc. When you are finished, you commit or cancel the changes in the small modal dialog. If you leave the checkbox selected, it will them put up a detailed dialog telling you what it is about to modify.

Generally, the menu info is saved in a dir.mnu file stored in the directory it affects. LLBs are a pretty old zip-type of file that we invented mostly to get around the 8.3 DOS names when we first ported to Win3. But they can also contain the palette info and are still somewhat useful. If you dig around inside the vi.lib/Rock Robotics/WPILib, you'll see that it uses folders and dir.mnu options.

You may find that some edits will save your modifications off to your My Documents location. This is generally because the folder of VIs contains a readOnly.txt file, telling the editor that it should not save to this location. If you want to make edits to your stuff directly, rename the file temporarily.

Installing the library to other machines only involves copying the folder to their computer. You can also do this with Source Code Control tools so that the whole group has synchronized libraries.

By the way, user.lib is located within Program Files/National Instruments/LabVIEW xxxx/. Also, if you don't want to use user.lib, you can instead place the files into vi.lib/addon. It is also set to Synchronize with Directory, so adding and removing folders will work to modify the palettes. You can also create your own WPILib subPalette and add that. It will modify the dir.nu for WPILib, so you may need to redo that once the 2016 release happens, but again, it can be in SCC and easily shared with a team of programmers.

For #2, an Arduino has its own dev tools, which is either a plus or minus, depending on your perspective. I'm not sure whether you are asking about C++ on the roboRIO as adding functionality, or exposure to C++. There isn't really a functional reason you need to switch tools, but learning additional tools is one aspect of FRC,

For #3, there are some resources on ni.com/frc to the QuickStartGuide. Also, I like the LEGO engineering stuff from Tufts. If you don't have any Mindstorms kits, it may be somewhat less useful, but the challenges are still of value.

Greg McKaskle