This document explains how to setup software for this project

This document explains how to setup software for this project.

Overview:

ROS (Electric version, for Ubuntu.)

Kinect ROS Package

KDevelop

OpenCV

Full:

1. 
   Install Ubuntu 10.10 (you need to download the iso from http://releases.ubuntu.com/10.10/, 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 https://help.ubuntu.com/community/Installation/FromUSBStick, and for Windows use http://www.linuxliveusb.com/en/download).
   

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

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

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

5. 
   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.)
   

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

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/libopencv_core.so.2.3.1.

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

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

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

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

10. 
    SSH
    

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:

ssh user@vip.gatech.edu

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

11. 
    Using SVN.
    

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

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

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 user@vip.gatech.edu, 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).

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

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

http://svn.gnu.org.ua/svnbook/svn.advanced.locking.html

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.

http://wiki.rabbitvcs.org/wiki/install/ubuntu

http://code.google.com/p/rabbitvcs/issues/detail?id=386

12. 
    Storing Research Data and Results
    

vip.gatech.edu/mnt/home/jm527/GTRIRobotics

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.