KenMankoff

Kinect Go Kit for fieldwork

Following up on my previous post about using the Kinect for earth science applications, I’m documenting the Kinect Go Kit I built for fieldwork.

I travel with two Kinects, two power supplies, and two computers in case one gets damaged or destroyed in the field, although only one computer is in the kit.

The Netbook is a cheap $240 computer running Ubuntu and the libfreenect software stack at a minimum. I have also found it useful to have more advanced data collection software (ROS, RGBDemo, RGBDSLAM), and some analysis software (CloudCompare, points2grid, Viewpoints, etc.). This netbook works fine for raw data dumps from the libfreenect ‘record’ program. It can run the more computationally expensive scene stitching algorithms such as RGBDSLAM, but it takes about 10 seconds per stitch, while a more powerful laptop (but still a few years old) can do it at 0.5 to 1 Hz. Since ‘record’ collects about 1.5 GB of data per minute, it is good to have a lot of free space on the hard drive.

The plugs and cables are shown laid out below, and in addition, some velcro straps are stored in that compartment, used to attach the Kinect to the tripod arm.

The Pelican 1510 case supports two levels, and the lower level looks like this:

Battery #1 is a 12 V 5 Ah sealed led acid battery. It provides >5 hours of Kinect runtime, about equal to the runtime of the netbook.

Battery #2 is 8 AA batteries (12 V), and underneath is an 8 AA battery holder and a battery charger. If I need to turn the Kinect on for a short amount of time and want to travel lightly, these will do.

As shown above the cord to the Kinect can be cut and alligator clips or some other electrical termination can be attached. I often have wall power and have attached clips to the detached plug so I can use it as originally intended. However, when in the field, the clips can connect directly to the 12 V battery or the AA battery pack.

The Kinect Go Kit above is close to the minimum necessary for fieldwork. Things that I would like in it, but are not yet, include:

• Tape measure
• Liquid container (tupperwear) and opaque liquid (or additive) so that any scene can have a defined flat surface
• Sling for under tripod to hold battery, netbook, protecting equipment and keeping it off the ground
• Counter weight for tripod arm

Additional tools I have found handy to have with me in the field include, but are not limited to, the following:

• External hard disk for backups
• Zip-ties to complement the Velcro straps
• Multimeter
• Spare notebook, perhaps with a more powerful CPU, for scene stitching
• Rope or other ‘image noise’ for scene stitching with RGBSLAM when working in environments that have ‘self similar’ scenes (no good tie points)
• Mounting systems for long term deployment
• Trashbags for environmental protection

 

Tags: Computers, HowTo, Kinect, PhD, Research

Kinect for Earth Scientists

We have successfully used a Kinect outdoors to study ablation on a glacier, map a subglacial cave in 3D, and tested it in a variety of hydrological situations (imaging roughness on the base of a stream, calibrating the Kinect data through water, and imaging surface waves). Results will be presented at the 2011 AGU conference.

There are a variety software interfaces to the Kinect. One high-level tool that is easy to use (binaries provided, no need to compile source, supports ‘scene painting’) is RGB-Demo. It is a good tool to start with if you want to work with the Kinect.

However, most Kinect software and calibrations so far have been developed by the robotics and computer vision communities. I am grateful for the work they have done, but those communities have different data needs than earth scientists. For example, quadrotor obstacle avoidance (link (PDF), link) has distance measurement errors that appear to be on order cm, but it still works fine as the helicopter avoids obstacles by an amount larger than the error.

Earth scientists should aim for a better model of the world than the one currently provided by the Kinect and its primary users. I suggest recording and storing the raw digital numbers (DN) from the Kinect rather than higher-level auto-calibrated real-world coordinates. It will require more post-processing, but storing the DNs will allow the data to be re-processed as better calibrations are developed. In addition, the low level recorder operates at 30 Hz and the higher level point-cloud products currently do not record data at that rate.

The best supported low-level interface is the LibFreenect Fakenect record program. It dumps the uncalibrated RGB and depth images to a folder at 30 Hz until you kill the process. Uncalibrated means both that the depth data is in sensor units, and that the depth and RGB images are not aligned. You can easily convert the depth data to real world x,y,z coordinates using existing published algorithms (link, link, link, and many others exist on the web), but importantly the raw data is stored and can be used with better calibrations in the future.

After processing the raw ‘record’ data, you can work with the point cloud data or DEMs using a variety of standard software for pointclouds, LiDAR, etc. I have had great success with CloudCompare and Poinst2Grid, in addition to custom code in MATLAB, IDL, and Python. A good list of software is available at the NSF OpenTopography site.

To work with the depth data to we initially use the following algorithms found on the various sites dedicated to Kinect hacking. The data provided by these algorithms is sufficient for certain uses, and for testing algorithms and visualizations, while better calibrations are performed.

DN to distance (source):

k1 = 1.1863d
k2 = 2842.5d
k3 = 0.1236d
Z = k3 * tan( double( DN ) / k2 + k1 )

XYZ to world (source):

Xres = 640
Yres = 480
FovH = 1.0144686707507438 (rad)
FovV = 0.78980943449644714 (rad)
XtoZ = tan( FovH / 2 ) * 2
YtoZ = tan( FovV / 2 ) * 2
X = ( X_pixel / Xres – 0.5 ) * Z * XtoZ
Y = ( 0.5 – Y_pixel / Yres ) * Z * YtoZ

Question or comments? Post below…

Tags: Code, Computers, HowTo, Kinect, Research

GLIMMER Ice Shelf Modeling (OS X HowTo)

A new beta version of the Community Ice Sheet Model, Glimmer-CISM, has been released. Below are instructions to compile and run it on OS X.

# build NetCDF
export CFLAGS=-m32
export FFLAGS=-m32
./configure --prefix=/Users/mankoff/local/netcdf-4.1.1 \
          --disable-cxx --disable-curl  --disable-dap
make && make install
say netCDF done

# build GLIMMER
cd ~/local/src/
wget http://download.berlios.de/glimmer-cism/glimmer-1.7.0.tar.gz
tar zxvf glimmer-1.7.0.tar.gz
cd glimmer-1.7.0/

# OS X has issues with 32 and 64 bit libraries.
# The -m32 flag forces 32 bit compilation.
# The following should be one long line:
./configure --prefix=/Users/mankoff/local/glimmer-1.7.0 \
     --with-netcdf=/Users/mankoff/local/netcdf-4.0.1 \
     FC=gfortran F77=gfortran CFLAGS=-m32

make
make install
say GLIMMER done

There are a few ways to test the installation. The source folder provides a test folder:

export PATH=/Users/mankoff/local/glimmer-1.7.0/bin:$PATH
cd ~/local/src/glimmer-1.7.0/tests/shelf
python circular-shelf.py circular-shelf.PP.config
python confined-shelf.py confined-shelf.PP.config
say GLIMMER Test Done # Takes a while. Turn up your volume

Running the above command will result in NetCDF files being created in the output/ subdirectory. You can view the contents of example.nc with most any generic NetCDF viewer. While theses tests run over a given period of time, the output only has one time stored. If you want to see an evolution of the ice shelf, older test suites available from the previous code repository site should be used:

cd ~/tmp/
wget http://forge.nesc.ac.uk/download.php/200/glimmer-example-0.6.tar.gz
tar zxvf glimmer-example-0.6.tar.gz
cd glimmer-example-0.6/
~/local/glimmer-1.7.0/bin/glide_launch.py ./example.config
say done

Examine the output file example.nc to see ice sheet evolution over time. Basal melt is shown below:

Get the Flash Player to see this content.

@article{Rutt:2009,
  Author = {Ian C. Rutt and Nicholas R. J. Hulton and Antony J. Payne},
  Title = {{The Glimmer community ice sheet model}},
  Year = {2009}}
  Journal = {J. Geophys. Res.},
  Volume = {114},
  Number = {F2},

Tags: Antarctica, Code, Computers, Greenland, HowTo, ice, Research

Optical Character Recognition HowTo

Optical character recognition (OCR) is useful for converting images of text into normal computer text that you can edit, copy, paste and search. With OCR software you can convert old image-based PDFs to text. About 95% of words from a cleanly scanned PDF using a modern font are correctly recognized. Of the ~ 1 in 20 that confuse the algorithm, about half are easily corrected with a spell checker, and the remaining must be manually adjusted.

Google has made the tesseract OCR code they use for Google Books available. They don’t officially support OS X. Below are instructions to get tesseract-ocr running on OS X. As usual, Developer Tools (XCode) needs to be installed.

A slightly simpler installation does not use LibTIFF, but in this case you can only convert single page and uncompressed TIFF files. As PDFs are usually multiple pages, it is worth it to install and compile with LibTIFF.

# prepare dependencies
fink install libtiff libtiff-shlibs

# fetch
svn checkout http://tesseract-ocr.googlecode.com/svn/trunk/ tesseract-svn
cd tesseract-svn

# compile
./runautoconf
export CXXFLAGS=-m32 # Force 32-bit architecture
./configure --prefix=/Users/mankoff/local/tesseract/ --with-libtiff=/sw/lib
make
make install

# test run
~/local/tesseract/bin/tesseract image.tif out # run it
say Tesseract finished # might take a while. Turn on your speaker.
gn Finished Tesseract # alias gn='growlnotify -s -m'
less out.txt # check

Notes:

• Here is a sample image for testing
• The image must be in TIF format.
• The extension must be have one “f”: TIF or tif not TIFF.
• Images and complex equations are not handled

I tried to run tesseract on my handwriting and it could not decode it. I wrote a simple sentence as clearly as possible, took a photo:

The Quick Brown Fox

And the result was:

THE ®.U\(.K
[awww Fox
TUMPED oval
#IE uxzv ooé

It got “THE” and “Fox” and most of JUMPED. However, tesseract supports full training so if you need to convert your notes read the documentation and post what your learn below.

Tags: Computers, HowTo

Building a Software/Hardware Environment for Research

Sometimes I get asked what software/hardware systems I recommend for research. Below is my standard advice. I am a scientific programmer and student and my day-to-day tasks involve research, data analysis,  scientific programming, and writing. Data sets might include satellite images, model output, GPS, seismic, and a variety of other data. Data domains are ocean, atmosphere, and/or ice. I travel a lot, either from home to the office or to the field (which might mean months on a boat with no internet connection). Therefore I try to have a setup that supports high performance computing (HPC) on a laptop.

More »

Tags: Computers, HowTo, PhD, Research

Python and wxPython

I’ve recently started developing code with the Python programming language. Prior to coding I had to install the language (Python) toolkits (wxWidgets and wxPython) and tools (py2app, py2exe, wxGlade). I have a *nix computer background so rather than downloading a binary installer I opted to build everything from source on my OS X box. It took quite a while to get it all set up correctly, so I’m documenting it here in case anyone else finds themselves in the same situation.

More »

Tags: Computers, HowTo

Managing Papers and Sources

If you author scientific publications using LaTeX and OS X, there is a useful tool chain you should know about. Even if you write non-scientific papers in MS Word on Windows you might find something useful in this post. If you don’t write, or you already use Zotero, BibDesk, zot2bib, and LaTeXiT or EquationEditor, then you should probably skip this post.

More »

Tags: Computers, HowTo, Research, writing