Tuesday, November 23, 2010

Kinect on OSX Snow Leopard

Exhilarating Madness!

Microsoft's XB360 Kinect Sensor reached the market the other day to enrich games on the Microsoft Xbox 360 Console with biological motion detection and superb three-dimensional enhancements. Kinect has received good marks to date. The possibility of creating three-dimensional images with Kinect caught my eye yesterday in a post with the title "With Kinect Controller, Hackers Take Liberties" by Jenna Wortham published online in The New York Times Nov. 21, 2010. The potentials are intriguing. Watch Oliver Kreylos' demonstration below:

I decided to give this a try and compile the software driver needed to run the sensor on a MacBook running Snow Leopard (OSX 10.6.5). Sean Nicholls provides useful information in his post with the title "Compiling OpenKinect on a stubborn OSX 10.6.5 (Updated 21/Nov)", first published Nov. 13, 2010. Sean's instructions are straight forward, leading to a functional application that provides as with a simple start. Below I added a few annotations that may be helpful to the novice builder.

In order to obtain the source codes and compile them into binaries, we need to install the packages 'git' (git- and 'cmake' (cmake-2.8.3-Darwin-universal.dmg), respectively. Both can be downloaded ready for installation from the links Sean provides in his post. Note that third party unix programs traditionally are installed into the directory /usr/local. The header files needed for compiling other packages are installed in the directory /usr/local/include. Compiled executable binaries will be installed in /usr/local/bin. Libraries will be found in /usr/local/lib, and files with information to be shared in /usr/local/share. This is the default map for the directory tree of all installs that conform to GNU conventions.

However, some software designers prefer to have their packages installed into their own directory tree in a separate subdirectory to /usr/local. This is the case with 'git'. We will find the package in /usr/local/git. If we wish to use 'git' commands in a terminal without providing the full path where they are located each time, we must add this path to our environmental PATH variable just so:
  • export PATH="$PATH:/usr/local/git/bin
If we now type:
  • echo $PATH
The terminal should print a colon-separated chain of bin directory paths ending with /usr/local/git/bin.

The next package to install is 'cmake'. The installer will prompt us to provide a directory where to install the executables; the default is /usr/bin. This is a directory for commands that the operating system uses. To avoid mixing system commands with others, I chose /usr/local/bin according to the above conventions. Again we add /usr/local/bin to our PATH variable as suggested above. Then we create a folder for the driver application, change to this directory in the terminal in which we previously set the PATH variable, and follow Sean's further instructions.

Note our additions to the PATH variable pertain only to this terminal window and are lost when we close it. To make them permanent, we need to edit the PATH variable listed in the .bashrc file in our home directory. But this is not strictly necessary for our purpose here.

Sean instructs us to download the sources for two packages that we must compile ourselves, using git: OpenKinect and LibUSB.  The first depends on the latter. Hence, LibUSB must be patched for the use with Openkinect, built and installed first, using the OSX generic make command. Note that the package will install into the appropriate subdirectories of /usr/local.

In the next step, we build OpenKinect, more precisely libfreenect, with cmake. The compiler needs to be pointed to the header files that come with LibUSB. This is accomplished with providing /usr/local/include/usblib-1.0/ on the appropriate line in the cmake configuration gui opened using the ccmake command as Sean illustrates. After cmake has configured the build successfully, we compile the package using the make command.

In my configuration, the build also needed to have the path to libjpeg specified, in order to successfully complete its last stage known as linking. The compiler complaint reads:
Linking C executable as3-server
ld: library not found for -lJPEG

In OSX, this library is located in: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/. There must be ways to configure cmake with this path, probably by adding "-framework ApplicationServices -framework CoreFoundation" to the LDFLAGS variable. Proper configuration is crucial, if we wish to deploy our binaries to other systems. Because I was not planning to deploy the binaries, I decided to avoid re-configuration. Since the compiler always checks /usr/local/lib, I helped myself with providing a soft link in /usr/local/lib to the library's true location just so:
  • sudo ln -s /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib /usr/local/lib/libJPEG.dylib
With the repeat of the make step the build finished successfully and was ready to install.

  • I just received the Kinect and have been running a test for close to one hour without fail (11/29/10).
Kinect on the Mac
  • The next step to more functionality entails hooking the kinect video stream up to an Actionscript3 flash server. The openkinect package provides help. Juan Carlos del Valle posted a video of the procedure to be followed with the title "Kinect now accessible from Flash" on the Freenect - Kinect projects site. The video moves along at a fast clip. I had to review the steps over and over again. Below I wrote out a step-by-step protocol of the procedure.

    Juan uses two Adobe Flash ActionScript files named test_depth.as and test_rgb.as which can be found in the libfreenect/actionscript directory. We need to download Adobe flex SDK_2.4 from the Adobe flex.org site to accomplish this. Once unzipped, we move the folder to our preferred location. The folder contains a bin-directory that is home to the mxmlc executable we need to use. Hence, it is helpful to add the path to this bin-directory to our PATH variable on the command line in the terminal window, as we added paths to bin-directories earlier. Then, we change into 'libfreenect/actionscript' directory using the cd command and type:

    • mxmlc test_depth.as

    With a little delay the terminal will respond:
    "Loading configuration file {your path}t/flex_sdk_4.1/frameworks/flex-config.xml
    {your path}/kinekt/libfreenect/actionscript/test_depth.as: Warning: This compilation unit did not have a factoryClass specified in Frame metadata to load the configured runtime shared libraries. To compile without runtime shared libraries either set the -static-link-runtime-shared-libraries option to true or remove the -runtime-shared-libraries option."

    Juan Carlos ignored the message. The command produces the file test_depth.swf in the same directory. We repeat the last step for test_rgb.as to generate test_rgb.swf.

    Next we need to start the Actionscript3 flash server. The subdirectory 'libfreenect/c/build/examples' containing the glview executable which generated the twin view in our earlier work is also home to the as3-server excecutable. Because I had not added this directory to my PATH variable, I changed into it and typed:

    • ./as3-server

    The terminal responded:
    Number of devices found: 1
    ### Wait depth client
    ### Wait rgb client
    ### Wait data client

    Opening test_rgb in my browser produced a live test image for color beginning with the comment:
    ### Got rgb client

    We kill the server with ctr C, and restart it with:
    • ./as3-server
    Then we opening test_depth.swf in our browser, producing a live image for depth beginning with the comment:
    ### Got depth client

    However, note that the red channel is not working. I am investigating (12/01/10).
  • The red channel works with as3-server built using a current libfreenect clone obtained with:
    • git clone git://github.com/imekinox/openkinect.git
    In order to prompt cmake to include as3-server in the build, we must first change the target option for as3-server in CMakeLists.txt to "ON" (12/07/10).
textbookx.com (Akademos, Inc.)

Sunday, September 26, 2010

The Stuxnet Worm, Windows & The Internet

A malware known as Stuxnet has attracted major media attention in recent days. This software inserts itself into computer systems using Microsoft Windows, Microsoft Explorer, and WinCC developed by the German electrical engineering giant Siemens AG. The latter piece of software is a Supervisory Control and Data Acquisition, or SCADA, application named Simatic S-7 that controls large scale industrial processes like power plants.

Stuxnet is a type of computer worm. That is, the program self-installs executable files that can be hidden on a USB flash memory stick or hard drive to the host computer. Subsequently, the executables are capable of transferring other files through the internet, if a connection is available. Stuxnet checks for narrowly specified system configurations and only acts if WinCC is running. Therefore, its mission consists of taking control of only a small number of exclusive targets.

An East European security firm was first to report Stuxnet last July. The worm is believed to have been active for about a year and has caused considerable disruptions in Asia, notably Iran. Potentially, the program may be capable of disrupting plant operations leading up to the destruction of the facilities. Its release is considered the first discovered cyber attack meant not only to disrupt information technology, but furthermore destroy capabilities.

The Chertoff Group's internet security expert David Falkenrath provides interesting insights on Stuxnet's impact and its ramifications in this interview by Bloomberg's Deidre Bolton entitled "Virus May Target Nuke Plant" aired Sep. 24, 2010.

Supposedly the vulnerabilities in Microsoft Explorer exploited by Stuxnet have been plugged. What may be of interest to the common user is that the worm used Microsoft approved security signatures from the network interface card chipset maker Realtek and the flash memory controller developer JMicron to install its files via the internet in the disguise of seemingly legitimate Microsoft-certified driver updates.

We should be safe as long as we keep our system and browser up to date with the latest security patches and avoid legacy hardware with obsolete drivers. That is, we should upgrade to the newest generation of internet adapter cards and regularly update the drivers, downloading directly from manufacturer sites.

  • In 2007, a large-scale bribery scandal broke in Germany, implicating Siemens AG's business in Southeast Asia. By 2008, a number of employees involved in this affair were let go. It only takes one disgruntled software engineer with intricate knowledge of the SCADA program running the targeted facility, maybe with the help of one or two other hackers knowledgeable in Microsoft Explorer and USB driver vulnerabilities, to accomplish Stuxnet in revenge. Perhaps, Iran is a clever diversion, Siemens already paid, and we never find out the actually intended target (10/04/10).
  • According to William J. Broad and David E. Sanger's article with the title "Worm Was Perfect for Sabotaging Centrifuges" published online in the New York Times today, recent results from the ongoing examination of Stuxnet code suggest that the worm was meant to target the speed control of ultra-centrifuges as those used for uranium enrichment, revving up their speeds to destructive levels. Since the implicated controllers were identified as products manufactured by companies in Finland and Iran, uranium enrichment facilities in Iran may have been the target (11/18/10).
  • According to William Broad, John Markoff and David Sanger's article with the title "Israel Tests on Worm Called Crucial in Iran Nuclear Delay" published online in The New York Times yesterday, more signs point to Israel and the U.S. as Stuxnet's originators with centrifuges in Iran's Natanz uranium enrichment plant as the target (01/16/11).
  • John Markoff reports in his article with the title "Malware Aimed at Iran Hit Five Sites, Report Says" posted online Feb. 11, 2011, that according to a Symantec study Stuxnet may have infiltrated as many as five Iranian institutions in three, possibly four, waves (01/13/11).
  • Listen to KCRW TO THE POINT's Warren Olney interview David Albright, President of the Institute for Science and International Security, on Stuxnet's effects in Iran 44 minutes into today's show with the title "A New Paradigm in the Middle East". According to Albright, Stuxnet disrupted the Iranian uranium enrichment program noticeably, but only in small ways. The greater threat may lie in the potential of adversaries using the worm, now public, as prototype for future attacks elsewhere (02/16/11).
  • According to Noah Shachtman's WIRED report with the title "Computer virus hits U.S. drone fleet" published online on CNN today, U.S. drones have been infected with a tracking virus, possibly through USB flash memory devices. This is not quite stuxnet yet, but a first step seems taken (10/10/11).
  • According to David Sanger's article with the title "Obama Order Sped Up Wave of Cyberattacks Against Iran" published online in The New York Times today, U.S. officials unofficially admitted that U.S. intelligence agencies created Stuxnet in collaboration with Israeli cyber warfare specialists to destroy ultra-centrifuges at the Natanz uranium enrichment facility in Iran. The article is scant on detail and Sanger's book "Confront and Conceal: Obama's Secret Wars and Surprising Use of American Power" to be published next week may be more illuminating (06/01/2012).
Related Posts

Wednesday, September 15, 2010

Solar Power: Way to Go!

We own a 12.0-inch diameter, 9.0-inch high urn-shaped fountain carved from limestone by the Tennessee artist Scott Wise. The fountain features a round shallow indentation on top into which water needs to be pumped slowly through a 0.5-inch center bore to feed a gentle, steady glistening pour over the ledge and down the sides of the rugged surface of the stone.

I set the fountain on two weathered brownstones in a 14.5-inch diameter, 4.0-inch deep pan sold for changing automotive oil, threaded a plastic hose through the center bore, sealed it with Macco Adhesives LN903 Liquid Nails Heavy-Duty Construction and Remodeling Adhesive, and connected it to a small pump nestled between the stones. I balanced the fountain stone with small flat river stones to allow the water flow down evenly on all sides. The pan holds more than enough water for the fountain to perform properly. However, owing to evaporation we need to top the water in the pan at least once a week to protect the pump from overheating. If we live in a dry climate, we need to check more regularly. At our first home, I used a pump fed by a power line laid underground in 0.75-inch diameter PVC tubing. I had to dig a foot-deep trench from our home across the entire yard. The job meant considerable work for a small flow of water.

To minimize the effort at the fountain's new location, I opted for a solar-powered pump which I purchased from Shore Power Inc. / BatteryJunction.com.

Power is generated with a 5.875-inch by 9.625-inch solar panel that can be installed at a distance from the fountain. The pump is equipped with a 14-foot long power cable. Where we live in the Southeastern U.S., the setup works great. However, the panel's effective angle is narrow; it must face the sun directly to produce the greatest power. We had to place it in the sunniest spot of our yard. Perhaps, mounting the panel on top of a wind-up clockwork that turns it along the sun's course is worth a consideration. Regardless, the smallest cloud blocking the sun will shut the fountain down. Despite, I got used to the intermissions, enjoying the sight of the bubbling little flow glistening in the sunlight as an affirmation that solar power does work indeed. However, if we wish to power our home with solar panels, it must be located in a particularly sunny spot, we probably need plenty panel surface, and the panels must be oriented such that a sufficient number face the sun at any time of the day. My small experiment is supposed to constitute an affordable test, informing us on the costs we may have to anticipate, if we aspire to convert our home.

  • Solar power windows sound like a great idea. Watch this Reuters report (08/11/2011):
  • Listen to this broadcast by Laura Krantz and Nicole Beemsterboer with the title "Colorado Voters get Revved Up Over Energy Policy" aired on National Public Radio's Morning Edition today. The New Belgium Brewing Co. in Fort Collins, CO, known for Fat Tire Beer, has got ideas on energy conservation worth pondering (10/3/2012).


Wednesday, January 6, 2010

Nexus One: The Google Phone

With Google's Nexus One officially introduced to the world yesterday, a new potent competitor has entered the highly-contested smartphone market. I won't comment much on the phone's features. Nexus One appears to be a solid product based on Google's Android operating system and Google applications not unlike the Droid introduced late last year. However, while the Droid is only available locked in with a particular cell phone service provider, the customer will be free to choose a plan to her/his liking with the Nexus One.

By contrast to their strongest competitor, Apple's iPhone, Android-based smartphones are open to Java programming. This constitutes a great advantage for application developers. However, beware! The libraries are restricted. Conventional Java applications will not run without major tweaking.

The footage below highlights last week's news development on the issue:

Review (01/05/10)

Revelation (01/05/10)

Rumor (12/31/09)

  • Alexei Oreskovic reported in his post entitled "Google's Android takes No 2 spot from iPhone" on Reuters yesterday that according to NPD Group market research Google's Android has become at 28 percent market share the second most prevalent smartphone operating system in the U.S. after Symbian used on Blackberry (36 percent market share) in this year's first quarter, displacing Apple's IPhone using OS X (21 percent market share). The figure comprises all phones running Android. Google's own Nexus One has not had such great success yet (05/11/10).
  • According to Doug Gross' CNN post today entitled "Google quietly kills its once-hyped Nexus One phone", Google Inc. decided to stop selling its own smartphone Nexus One entirely because of sluggish sales. Nexus One uses Google's Android operating system. Other smartphones with the same operating system like HTC's Droid Incredible are selling briskly, and Google will maintain full support for the operating system (07/19/10).