Writing code as a team can be a challenge. Whether the team shares a single computer for writing programs or each team member uses his or her own computer for programming, there are challenges in keeping the code under control.
If your team is sharing a single computer for robot programming, then code management isn’t too great of a challenge as long as team members communicate. It’s good to have a program task master—someone who keeps track of the changes and tries to keep the code safe.
“Safe” means to create and maintain backup copies. Nothing is worse than having a working program that gets changed—and the program no longer works as expected. When this happens, it’s nice to have a copy of an older version of the program.
Maintaining backup copies are the program task master’s job. Other duties include managing which team member works on what programs, and playing the role of gatekeeper to avoid unnecessary changes to programs. It is not unusual for a team member to change a program because he thinks something is wrong, but doesn’t realize that he isn’t setting up the robot correctly or that he’s using the wrong robot attachment. A good program task master is familiar with all the proposed code changes and is able to discuss them with the team before any changes are made.
It’s a good idea to create backups after each meeting. By default, the programs are saved in the My Documents folder for the current user. For example, on my computer the path is:
C:Documents and SettingsjtrobaughMy DocumentsLEGO CreationsMINDSTORMS ProjectsProfilesDefault
All the My Blocks that I create are saved under that directory, in the following location:
C:Documents and SettingsjtrobaughMy DocumentsLEGO CreationsMINDSTORMS ProjectsProfilesDefaultBlocks
When backups are made of all the programs, both the Default folder and the Blocks folder should be backed up together. However, keep the programs in their original folder. Many teams keep a flash drive to which they can copy the Default folder at the end of each meeting. They then rename the copied folder using the current date, as seen in Figure 12-1.
Figure 12-1. Backups of NXT-G programs
If you need to restore a previous program, you simply copy the file from the backup flash drive back to the original location. Do not try to open the program directly from the flash drive. Always work with your program in the default location—otherwise, you will corrupt the backup copy.
Make backups of your files from outside the NXT-G program editor. Do not try to use the Save As method to copy a file to a different location. Doing so can cause problems with your My Blocks linking properly in your program.
If your team members are working on different programs on separate computers, it might be helpful to have all the computers on a single network/shared location in order to save the programs in a single location. To do this, you have to put in extra effort to be certain that everything stays in sync.
The biggest concern is the location of your My Blocks. Even if you save your program to a location other than the default, the My Blocks are still referenced from the system default location. For example, let’s say that team member Laura writes a program on her computer and it includes a reference to a My Block called AddToCounter. She then saves the program to the shared drive on the network. Team member Lee opens the program that Laura wrote, but Lee doesn’t have the AddToCounter My Block on his computer. His program will look like Figure 12-2. The My Block is displayed as “broken.”
Figure 12-2. A broken My Block
The reason for the broken My Block in Figure 12-2 is that the NXT-G program is looking at the data directory on the local C drive of Lee’s computer. The data directory is configured in the settings.ini file on each computer—in the My DocumentsLEGO CreationsMINDSTORMS ProjectsProfilesDefault folder. If you want all the machines to use the same shared path, then the data directory value on each machine must be changed.
Note I want to caution you about having all the files on a shared network location. At a competitive event, you most likely will not have any network access. In only very rare situations would you have access to your shared network drive back at your school or home. So if you need to access your programs at the competition, you need to move copies of the programs locally to the computer that you bring to the event. You will have to modify the settings.ini to point to the local location, rather than the network location.
Saving programs to an Internet-based central repository, or “the cloud,” is a popular way to share and keep program files synchronized. There are a few free services available on the Internet for just such uses. One of the more popular choices is Dropbox (www.dropbox.com). Figure 12-3 shows some NXT-G programs that are stored in a Dropbox repository.
Figure 12-3. A local Dropbox repository with NXT-G programs
The concept is that you will have a “team” account on such a service. Each machine that you use to program your robot will connect to the account via the Internet and synchronize the files in the account to a local location on the computer.
For example, I may have the following folder path on my computer:
C:UsersjamesDropBoxNXT Programs
My local Documents folder is as follows:
C:UsersJamesDocumentsLEGO CreationsMINDSTORMS ProjectsProfilesDefault
It will contain my settings.ini file, as seen in Figure 12-4.
Figure 12-4. Local instance of the settings.ini file
Inside the settings.ini file, I will specify the data directory path to that of my local Dropbox folder, as seen in Figure 12-5.
Figure 12-5. Data directory setting in the settings.ini file
Any time that I add or update a file in this folder, the same file is updated on my cloud storage system—Dropbox in this case—and the change is also pushed down to any other computers that are connected to this account. This allows all the other team computers to have my changes on their machines. In return, any changes they make will be pushed to my computer folder.
The nice thing about using a system like this is that you don’t have to change your settings.ini file when your computer is offline. As long as your folder has been recently updated, you will be dealing with the correct files.
Dropbox (and some of the other file synchronization systems) allow you revert to previous versions of a saved file. This is helpful if someone on your team makes a change, saves it, and then realizes that the previous version of the program was more desirable. By right-clicking the program in your Dropbox folder in Windows Explorer, you see there is a Dropbox menu item with a “View previous versions” submenu, as shown in Figure 12-6.
Figure 12-6. Viewing previous versions of a file in Dropbox
You are taken to the Dropbox web site, where you see all the different versions of the file you selected. Unfortunately, the site is not able to tell you the differences between the versions, but you do have the option to restore an older version and see who the last person to update the file was. Figure 12-7 shows a typical version list of a file.
Figure 12-7. The Dropbox web site showing different versions of a file
Before you go to an event, make sure that the computer you bring has been properly synchronized because many events have limited Internet connectivity. You don’t want to show up at the event with old code. Any changes to your code that you make at the event will be copied to your other computers as soon as your computer has Internet access, thus keeping everyone updated on any changes made at the event.
Team members also need to be aware of who is working on what programs. If two people are simultaneously working on the same program, the last person to save the program will override any changes made by the first person.
It is also commonly suggested that teams store their programs on flash drives. The idea is that each team member will have his or her own flash drive to save programs. Each flash drive is mapped to the same drive path on the computer, so no matter who plugs in their drive, the data path in the settings.ini file is the same. Changing the settings.ini file is very important; you can run into issues with the broken My Blocks, as we saw in Figure 12-2.
So for example, if my data path is configured for the “X” drive, then all my flash drives should also be mapped as the “X” drive on any computer they are connected to. This can be done via the Computer Management application in Windows, which allows you to specify the drive letter you wish to assign to your flash drive.
In addition to having a flash drive for each team member, it’s wise to have a master flash drive that your program task master uses to keep the latest version of all the programs stored. This master copy is the flash drive that you bring to your competitions. To learn more about this method of program management, I suggest visiting www.TechBrick.com, which has a very good write-up on how to use such a system.
Note Be careful that you don’t lose your flash drives. Keep them in a safe location when not in use. It is also recommended that you continue to make nightly backups of your programs.
When working with your NXT-G programs, it’s easy to want to give the programs silly names such as “Amy Grabber thingy” or encrypted acronyms such as “AGT.” These names may be meaningful to the original programmer, but other people on the team may not have any idea of what these names mean.
The team should come up with a set of standard naming conventions. Since the file name is what gets shown on the NXT brick screen, don’t make it too long or too confusing. The name should say what the program does. A noun and action can be helpful. Something like “GrabRings” is a good start, but if you have multiple rings on the table, it isn’t all that helpful. Changing the name to something like “GrabRedRings” may be more practical. Someone reading that file name will be able to quickly figure out what the program does, without having to dig into the code. Also, if you have combined multiple tasks into a single mission, then you can label the programs based on the mission names. For example, you could name your mission programs “ZoneOneMission” or “DeliverGoodsMission.”
Try not to include details such as the order in which the program is going to be run. Names such as “FirstProgram” or “ProgramTwo” are not helpful at all. The order in which you run the programs may change, and the ordering really doesn’t tell the operator what a program is designed to do.
Adding a version number is also helpful in keeping track of your programs. Figure 12-8 shows multiple versions of PushCarToBase. By looking at the file name, you can see there are two versions, PushCarToBase 1.0 and PushCarToBase 1.1. You immediately know what the program does and which file holds the newest version.
Figure 12-8. An NXT-G file dialog box
In the NXT-G software, there is a command called Pack and Go that allows you to save NXT-G programs along with other files. Backing up and sharing the MINDSTORMS NXT-G .rbt files is helpful, but extra files could also be required, such as sound, graphic, and My Block files. The Pack and Go command packages backup all the files in your program into one file. Pack and Go files use the .rbtx file type instead of the .rbt file type.
Note The Pack and Go feature is only available on NXT-G 2.0 software and newer. The Pack and Go .rbtx files are not readable by earlier versions of the software.
When you open an .rbtx file, the NXT software automatically places the My Blocks in the default My Block folder, the sounds in the Sounds folder, images in their own folders, and the program in the default program directory. Be careful: the NXT software will override any files with the same name.
To create a Pack and Go package, open your program and select Create Pack and Go in the Tools menu of the NXT-G software, as shown in Figure 12-9.
Figure 12-9. Create Pack and Go from the Tools menu
Give your new Create Pack and Go package a valid and useful name, and select the location on your computer where you want to save the package. A list of the objects that are included in the Pack and Go file is listed in the dialog box (see Figure 12-10). Click OK to save the Pack and Go file.
Figure 12-10. The Create Pack and Go dialog box with a list of items included in the package
Sharing program files among team members is helpful, but if the other team members don’t know what the code is supposed to be doing, they could spend a great amount of time trying to decipher the code, or even worse, they could misinterpret the functionality and make incorrect changes.
Detailed comments are very helpful in the long run. It’s difficult to get people to keep proper comments, but if everyone gets into the habit early, it makes life much easier in the long run. In Figure 12-11, you see a program that contains no comments. It is difficult to understand the flow of the logic.
Figure 12-11. Uncommented NXT-G code
In Figure 12-12, you see the same code with helpful comments. You can see how much easier it is to understand the logic flow of the program without having to spend a great deal of time evaluating each block.
Figure 12-12. Commented NXT-G code
Summary
Proper program management is critical to having a winning robot team. Even though the actual robot design and programs are important, without keeping your programs in order, your team can quickly become disorganized and fall behind. It’s important to practice good code management skills from the beginning: use proper file-naming conventions, keep programs backed up, and make certain that you use the latest versions of the code.