This document explains how to setup software for this project

Download 29.22 Kb.
Size29.22 Kb.
Software Setup

This document explains how to setup software for this project.


Ubuntu 10.10 (Run updates, but not an OS upgrade.)

ROS (Electric version, for Ubuntu.)

Kinect ROS Package





  1. Install Ubuntu 10.10 (you need to download the iso from, then burn it to cd, or to usb using the linux usb creater software. On some machines only the usb method will work, and you must have an empty usb stick. See, and for Windows use

To use it in a virtual machine, first, go download VMWare Player (Windows or Linux only). Download Ubuntu 10.10, and install it as a VM. The usual way to install vmware tools doesn't seem to work (so, if you want to be able to full screen, you have to do the following, but I've been told if you install an older version of VMWare Player that it may work fine). Go to the Synaptic Package Manager, install open-vm-tools and open-vm-dkms (not sure yet if you need that one), and after installing, go to a terminal, and type "sudo vmware-toolbox &", which just starts the tools, and runs it in the background. (Actually it seems to me that you can immediately close it and it still works, but I read to do this. Upon restarting the vm I still was able to full screen my vm, without restarting vmware-toolbox.

  1. Apply System updates with the update manager (but don't upgrade the os).

  1. Go Get ROS (electric), use the installation instructions on the ROS webpage, setup the ROS environment with your own ROS packages folder, and go through the tutorials.

  1. Go get the ros kinect stuff. Use Synaptic Package Manager to get ros-electric-openni-kinect.

  1. Use the Synaptic Package Manager or apt-get to install KDevelop. Run it using 'kdevelop'. When you close it, it has an error. I'm assuming that if you build from source that error probably will go away, but I haven't tried yet. (Whenever you install something from the package manager you are likely not getting the most current version.)

  1. You will now have opencv. Use this command to find out where it is:

find / -iname "*opencv*" -type f 2>/dev/null

The main things you need to know are where the libs, the headers, and the reference docs are.

Libs are in /usr/lib/, such as /usr/lib/

The headers are in /usr/include/opencv-2.3.1/.

The reference document is in /usr/share/OpenCV-2.3.1/doc/opencv2refman.pdf.

  1. To test opencv we will build with cmake. You can make this a little less transparent by using the package manager to install cmake-curses-gui (ccmake).

  1. Get the OpenCVExample.tar.gz code. Unpack it somewhere. cd into the Example folder. When we build the code, we should not create the build files in the source folder, to keep the build hierarchy clean. So, create a folder inside called 'build'. cd into the new build folder. Type 'ccmake ..', note the space between ccmake and '..'. This runs a cmake 'gui', which will allow you to see some of the configuration settings. Hit the 'c' key. This will read the config files and setup the build parameters. It then gives you a chance to see and edit everything. Hit 'c' again, at this point there is nothing else to check or modify, so the configuration is finished. Now press 'g', and this will finally build the actual linux build files, makefiles in this case. Note that all the build files are being created in the build folder you are currently in. The gui should exit, so you can check that the folder is no longer empty using ls. At this point everything is ready for you to build. Type 'make', which will build everything, and then type 'make install', which will copy the binaries to an install folder. The install location is set in the cmake files, and for this example the install folder is in the main OpenCVExample folder, cd to it. You'll see that there is both a bin and lib folder, check inside each. For this project there is a simple object for doing the image processing, and it is compiled into a library (CVTool), and there is also the application's main.cpp file, which uses the library, compiled into an executable (CVTest). Go download any image file off the net and place it in the binary folder, let's assume your file is a color file called 'robot.jpeg'. Type './CVTest robot.jpeg newrobot.jpeg', and the program will run, loading the first file, modifying it, and saving out the result in the second file. Find an image program that will let you convert the image to gray (gimp is popular). Try running the same command with the gray image file, and it will do something different.

  1. Now, let's look at the code. Launch KDevelop. Click on Project->Open Project... Navigate to the Example folder, click on the CMakeLists.txt file, click Next, then Finish. Open the Projects tab on the left, you can browse the files that are in the project. You can see all the source files (.h and .cpp files) and the cmake files (the 3 CMakeLists.txt files). Look over them and try to grasp what's happening. Try modifying the source code (and if you add new files or folders, the cmake files) and test it out. See if you can figure out how to build and install the code from within kdevelop. KDevelop is powerful, so if you learn anything useful about it let everyone know. This is about all I've specifically used it for, just for its cmake integration, and it's usability as an ide.

  1. SSH

See ssh tutorials and help online, here’s one quick page: You’ll probably want to use an ssh config, this page has more details: You may also want to setup pass keys, good help is at and

Our vip server is available for you to log into, and you will have a home account there to store data, or run whatever you like remotely (though, I don’t know what type of machine it is, so be nice). You can ssh into it using:


Once there you will start in your home folder at /mnt/home/user/.

  1. Using SVN.

Our svn repo is on the vip server. The address to our repo for this class is

You can get a list of the current files/folders in that directly by using

svn ls svn+ssh://

Replace ‘user’ with your GT user name. It’ll ask for your password (unless you setup pass keys), and then show you the list. I like to use RabbitVCS instead of directly using svn. Run

sudo apt-get install rabbitvcs-nautilus

to get rabbitvcs and an integrated environment with the nautilus file browser. You may have to log out/in to get everything working. From here, you need to checkout some code. Go into your home folder, or somewhere else, and right click in the nautilus browser, click on Checkout. Next, put the full address of our repo in the location bar, plus a sub project folder


Remember, if you used ssh config for this host/username, then use that instead of, but you still need the remaining path to our repo and folder. Before you click ok, you may modify the actual name of the local folder if you want. In this case, you probably don’t want your local folder called trunk, so just set it to MobileSensing. Once you click ok it will checkout all of the files in that folder. Feel free to poke around. Of course, if you are working on a different project, checkout that folder too, in some other location than this one (you can manually delete everything you just checked out, if you don’t need it).

The current full folder structure of our repo is:

|-- ClassDocuments

Class presentations, assignments, literature references, etc.
|-- HelpfulStuff

Software examples and tutorials, computer setup, and other helpful stuff.
|-- Common

Tool1 General Code to do X, with a good build setup and api, not project specific.

Tool2 Same for doing Y, etc.
`-- Projects Top folder for all application based projects for this class.
|-- MobileSensing Top folder for this project.

| |-- branches svn branches

| |-- tags svn tags

| `-- trunk Main Software for this projects (svn trunk)

| |-- Common Software tools/libraries used throughout this project.

Stuff like general image analysis or robot control tools. When the tools are general enough, they should actually be stored in GTRIRobotics/Common/ and simply be checked out into this folder using the svn:externals property.

| |-- Documents Documents specific to this project, help file, task lists, etc.

| |-- LeafDetection Other modules/libraries specifically for this project.

BugDetection, etc

| `-- MobileSensing Main executable for the project, the top level application.

There can be different versions of this if needed.

CMakeLists.txt The top level build file should exist here.

It should setup all high level libraries (CV, ROS, etc), and then point to all needed subdirectories, including tools in common.
`-- SmartArm Same as Above.

|-- branches

|-- tags

`-- trunk

|-- ChickenDetection

|-- Common

|-- Documents

`-- SmartArm

You need to lookup tutorials on how to use svn. The main steps to adding files into svn are:

svn update

Do this first to make sure your local files are up to date with the repo, and you have merged any changes anyone else has already made into your own local files. You will not be able to do a commit until your local files are up to date with the head revision. If you have made local changes to your own files, this will not modify those changes (though, it may modify files you have changed while attempting to auto merge other/newer changes from others).

svn add

Add any new files or folders that you have added to your local working copy. If you add a folder, it will automatically add any files/folders inside of it. (Be careful with this, and be sure you don’t have local or temporary files in there that shouldn’t be in the repo, such as log files, or temporary images, etc.)

svn commit

This will commit all your changes to the repo. You should write in a log message about what changes you made. This is very important, so that in the future if you need to look at the log history of the project, to determine when some critical change was made, etc, you will be able to easily locate what you are looking for, and so when others update their code with your changes, they can quickly be aware of what changes you made, in case it impacts work they are doing.

The major rules for using svn are:

Never add in temporary build files, or binaries. Only the CMakeLists.txt files should be added, since everything else (including build or install folders) will be produced by the user during the build process. Any makefiles produced during the build process should not be added, however, if you create your own make files to aid in the build process or other things, these would be ok.

Do not commit changes which will break the project’s code, cause it to not build or run, etc. Remember that other people are using your code, so be very considerate of that. There is no magical way to be sure that nothing you do will affect other people’s work, and improved code will often change things parallel to your efforts. This is ok, and you must talk to your teammates often about what changes are occurring, and how to best handle the new development. However, do not wait too long before committing your work, because this is a backup system as much as anything else. If takes you two weeks to finally get back to a buildable working set of code, and in that time you’ve never committed, then we could potentially lose all that work. If you want to make large changes to the code, then you need to make use of svn branches, this way you can have a place in the repo for only your work, and it will not affect others when you check in temporary progress, and you will be able to merge it back in with the main trunk when you are ready.

Use tags when appropriate. When you get to a key milestone in the software, such a good demo, or a new revision of the software with a whole new API or architecture, you need to mark that point in time/code. This is done using svn tags. This is exactly the same as branches, but conceptually just allows you a place to save progress at key points. This is most useful for demo code. Consider an example. You get word that a key sponsor is coming by the lab, and your boss wants you to show off your robot. Unfortunately, you have been making major code changes for weeks, with many modifications and commits along the way, and you are weeks from finishing. If you’ve been using proper version control, then you should be able to go pull down the code you used the last time you gave a demo, but that could take a while to remember when that was or what the commit log was for that point in development. Instead, if you tagged the code at that time, then you would immediately be able to checkout the tagged code, build it, which should succeed because it was tagged as working demo code, and you’re ready to go.

SVN File Locks

The convention for parallel editing and committing files in subversion is to edit the file, attempt a commit, and if you find that your version is out of date, update to the new version, and merge the new version with your local modified version, and finally commit. Usually, specifically with source code, the files can be automatically merged together, and the user does not have to be directly involved. This user can trust that their changes and the changes to the same file that were in the repo, committed by someone else, will be correctly merged together. There are some file types, however, where merging is very difficult or impossible, such as edits to image files, or spreadsheets. In these cases, when a user modifies a file and then attempts to commit/update/merge, they will find that another user already modified the file, and now only one of the files can be kept (this user manually merges by accepting the new revision, or by accepting their own), and the next commit will keep only the accepted file. To deal with this is the concept of file locking.

If you need to edit an unmergable file, you should first get a lock on that file. You can do this with ‘svn lock’. This tells the repo that you have the file locked for editing, and the result is that no one else can commit a new version of the file until you have released the lock. This prevents any out of order commits. So, the idea is that you will lock the file, edit it, and commit. The commit will commit your changes and automatically release the lock. (Commits will release all your held locks by default, to encourage that no one holds locks for very lock, improperly.) At this point anyone else can commit their own, new changes.

Unfortunately, unless someone else makes sure to always get the lock before editing the file, they may spend hours editing it, and then go to commit, and only then will they realize that someone else already has a file locked. The result is that they will have to wait until that user has committed or released the lock, then they will have to do a manual merge with their changed file, which may be impossible, and they will still likely lose their changes. (You can use ‘svn status –show-updates’ to see if files have been locked by others, or ‘svn info’ to find out by who, but this doesn’t help, it just gives you info, you should get the lock first.) Fortunately, there is a file property that can be set, ‘svn:needs-lock’ which basically acts like a flag, such that whenever a user does an ‘svn update’ any file which has this property set will be set to read only by the user’s file system. This acts as a warning to someone that is about to modify a file. If they attempt to edit a file that needs a lock, it should be shown as read-only, prompting them to go and get the lock first. Once the user gets the lock, the lock flag is set in the repo, and the local file is set to read-write, allowing edits. It is always possible for a user to reset the read-only file property, and modify it locally, even when someone else has it locked, but this is not following the convention, and shouldn’t be done. If a user has had a lock for too long, and it seems they are not going to unlock it, or they have gone on vacation, etc, another user can steal or break the lock, but this should be used carefully. See the following link for help.

With RabbitVCS version 0.15, while lock and unlock work properly, I cannot use the repo browser to see the locked status on files, so if you wish to do this use the svn commands instead. If you are using a RabbitVCS version prior to 0.15, you should update.

  1. Storing Research Data and Results

When you need to store results of your work, or collections of images you have taken, or anything else that isn’t suitable for the wiki, you need to store it on the server in a common place accessible by the whole class. I’ve setup a location on the vip server for everyone to have access. Right now it’s here:

Currently there are no groups setup, so everyone has full rwx rights in this folder, so don’t put something here that isn’t safe for anyone with access to this server to see. Here’s the tree:

GTRIRobotics/ Top Level

|-- Common Images, logs, etc, that relate to common work, same as the common svn folder.

`-- Projects Top Level for Application Projects

|-- MobileSensing Images, logs, etc, that relate specifically to this project.

`-- SmartArm …same.

It’s easy to use this in nautilus by pressing ctrl-l (l for location), and typing in:


Download 29.22 Kb.

Share with your friends:

The database is protected by copyright © 2023
send message

    Main page