Forum Replies Created

Viewing 14 posts - 481 through 494 (of 494 total)
  • Author
  • in reply to: caught exceptions with RawKinectViewer and SARndbox #100696
    Oliver Kreylos

    That’s unfortunate. While it’s true that all versions of the original Kinect (-for-Xbox 1414 and 1473 and -for-Windows 1517) are not 100% reliable, we’re typically only seeing issues very rarely. I haven’t noticed Kinect-for-Windows devices being less reliable than -for-Xbox ones in general.

    When issues do occur (such as error messages, or the depth map being completely flat or non-existent), it’s usually sufficient to restart the application that was using or trying to use the Kinect. If that doesn’t help, KinectUtil reset all typically does the trick.

    If you’re seeing problems that often, there might be a problem with your specific Kinect device, or with the USB port into which it’s plugged, or your entire USB subsystem. If your Kinect is currently plugged into a USB 3 port, try using a USB 2 port. While our software fully supports Kinect over USB 3, USB 3 support in the Linux kernel is still a bit lacking, and Ubuntu 14.04 uses a somewhat older kernel.

    If you’re already on USB 2, try a different plug, ideally on a different bus (front-facing and back-facing ports on a typical tower PC are usually on different buses). If all that doesn’t help, try the Kinect software on a different PC if you have one, and if that helps but you want to keep using the one you currently use, try to find a cheap USB 2 or USB 3 PCI expansion card ($5-$20) and put that into the PC and the Kinect into it.

    in reply to: build issues #100695
    Oliver Kreylos

    For simplicity reasons, Vrui and its add-on packages and applications (Kinect, SARndbox, …) are set up to install in the installing user’s home directory. For experimentation, I recommend not changing anything in the build system and just running make, make install on Vrui and Kinect, in that order, and make on SARndbox. That creates a working system with the CalibrateProjector and SARndbox executables in ./bin in the directory from which make was run.

    Depending on how the sandbox computer is set up, it might not be necessary to ever do a system-wide installation, but if desired, the easiest way is to pass installation paths directly to make, as in:


    $ make INSTALLDIR=/usr/local
    $ make INSTALLDIR=/usr/local install


    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make
    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make install


    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make INSTALLDIR=/usr/local
    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make INSTALLDIR=/usr/local install

    This procedure doesn’t modify any files, so it could be put into a script.

    in reply to: libusbx and USB nodes #100692
    Oliver Kreylos

    The udev rule file distributed with the Kinect-2.8 package only has rules for the original Kinect-for-Xbox (model number 1414). I added detailed instructions for newer Kinects to the Kinect download page.

    in reply to: libusbx and USB nodes #100682
    Oliver Kreylos

    The device manager rule file that’s installed by make installudevrule is only applied when new USB devices are plugged into the system, or the system is rebooted. Meaning, it will not affect the USB device nodes of a Kinect that’s already plugged in.

    There are three alternative methods to activate the rules:

    1. Unplug the Kinect from its USB port, wait five seconds, and plug it back in.

    2. Restart the device manager by running the following two commands from a terminal:

    $ sudo udevadm control --reload
    $ sudo udevadm trigger --action=change

    3. Reboot the computer.

    in reply to: Compatibility with Kinect for Windows v2? #100678
    Oliver Kreylos

    The current AR Sandbox software only works with the first-generation Kinect, either Kinect-for-Xbox 360 or Kinect-for-Windows. I’m still working on a low-level driver for the Kinect-for-Xbox One and Kinect-for-Windows v2.

    You should still be able to pick up Kinect-for-Xbox 360 in the gaming aisle at electronics stores, for around $100.

    in reply to: Sandbox design #100673
    Oliver Kreylos

    The ECHO AR Sandbox, and its identical twins at Lake Tahoe and Lawrence Hall of Science, were designed by the San Francisco Exploratorium workshops. We paid for the design, so the drawings should be available. Please contact the person in charge at the Exploratorium, Allyson Feeney, via .

    The ECHO et al. sandboxes are in portrait orientation, in the sense that the back cabinet is along one of the short box edges. Due to the projector being natively landscape, this leads to a less stable setup where the projector is dangling from the top hood. I recommend a design where the projector is directly attached to the cabinet, running up from the center of one of the long edges.

    Since you’re in Berlin, have you checked out the AR Sandbox at the GameScienceCenter?

    in reply to: Step 5 calibration camera space #100671
    Oliver Kreylos

    KinectViewer shows a 3D reconstruction of what the Kinect camera sees, which is important to measure the 3D positions of the four box corners. Did the video illustrating that step, , help? It shows how to change the viewpoint of the program to move the observed sand surface into the screen plane and take the corner measurements.

    Please note that there’s a mistake in the narration for that video. The corners need to be measured in lower-left, lower-right, upper-left, upper-right order.

    in reply to: Automating drainage key mapping #100670
    Oliver Kreylos

    Unfortunately, the “mouse click before key press” issue is a known bug in the current release that’s already fixed in the upcoming next version, see elsewhere on this forum.

    in reply to: Water Drain #100668
    Oliver Kreylos

    My bad; the angle brackets <…> indicate a variable that needs to be replaced with a concrete value. There is another wrinkle that I forgot myself, and that’s that evaporation rate is actually water deposit rate, meaning that it should be negative to remove water.

    Try adding this to the command line:

    -evr -0.25

    and that should do the trick. There needs to be a space between -evr and -0.25.

    in reply to: Water Drain #100660
    Oliver Kreylos

    The software contains a “water management” tool that can be bound to two keys or buttons. First, to account for a bug in the current software, click the left mouse button within the application window. Then press and hold the key/button you want to use to make it rain, and move the mouse (without clicking any mouse buttons) to select “Manage Water” from the tool selection menu that pops up. Once there, release the key/button you were holding. Afterwards, press and release the key/button you want to use to drain the sandbox.

    After this, press and hold either of these keys/buttons to add/remove water from the sandbox.

    See another post on this forum on how to make this tool binding permanent.

    You can also use a single or a pair of USB buttons that act like keyboard keys to add/remove water.

    Finally, there is a command line option to slowly remove water over time. It is -evr <evaporation rate>, where <evaporation rate> is the rate at which water disappears in cm of depth/s.

    in reply to: Automating drainage key mapping #100657
    Oliver Kreylos

    There are two ways, and the easier one is probably the following:

    * Start the application, and manually set up your tools as you want, e.g., bind your favorite keys to the water management tool etc.

    * In the application’s main menu (right mouse button), select “Vrui System” -> “Devices” -> “Save Input Graph…” An input graph is the full set of virtual input devices and tool bindings that are currently active in an application.

    * In the file selection box that pops up, either enter a name for your input graph file (press F1 to go to “text entry mode,” enter the filename, then press F1 again to go back to regular mode), or go with the default name. Press OK to confirm.

    * After exiting the application, find the file you just saved. If you didn’t give it a meaningful name from within the application, rename it using the file manager or command line.

    * When starting the application the next time, add -loadInputGraph <input graph file name> to the command line, where <input graph file name> is the name of the file you saved.

    If you use a script or icon to start the application, append the command line arguments in there.

    in reply to: Problem with calibration #100593
    Oliver Kreylos

    “This link:

    Stated to pass a parameter to the SARndbox program as follows:

    ./SARndbox -fpv

    I did not find this specified in the README.”

    Yes, that was a mistake I made in the 1.5 package. Since you have run into that problem and found the solution, here is the relevant section of the README file that will go into the next release:

    “Step 8: Run the Augmented Reality Sandbox

    At this point, calibration is complete. It is now possible to run the
    main Augmented Reality Sandbox application, SARndbox, in calibrated
    mode by passing the -fpv (“fix projector view”) option on the command
    line. This option will load the projector calibration matrix calculated
    in step 7, and disable manual navigation. Without the -fpv option, the
    scanned 3D terrain surface will be rendered as a typical 3D model, with
    full rotation, panning, and zooming ability, and will therefore not
    align properly with the physical sand surface.”

    Will that do the job?

    in reply to: GL error: Invalid enum #100589
    Oliver Kreylos

    If you just run the SARndbox executable without any calibration, what you’ll get is unpredictable; it depends on the position of your Kinect relative to your sand surface. You’ll have to at least run calibration steps 4 and 5 first, as described in the README.

    The error message is probably due to running OpenGL in software emulation mode, using the Mesa library. For the sandbox to run properly, you need to install proper vendor-supplied drivers for your graphics card, e.g., those available from Nvidia or AMD/ATI directly, or through the additional hardware driver repositories in Ubuntu.

    in reply to: Full Screen Mode #100564
    Oliver Kreylos

    There are multiple ways to do it. First, you want to create a keyboard shortcut to toggle full-screen mode for any window. Go to the keyboard settings dialog, and select the “Shortcuts” tab (where this exactly is depends on the distro, but you’ll find it). Then, under “Windows” shortcuts, find “toggle fullscreen mode” (do not use “toggle maximization state”, that’s a different thing) and assign a key combination to it. I usually use Ctrl+Alt+F or Win+F, depending on the local keyboard.

    Then, after starting the calibration program, press the assigned key combo to switch its window into fullscreen mode. Depending on your window manager, you might have to give keyboard focus to the calibration program’s window first. Either click into the window using the left mouse button, or press Alt+Tab to cycle focus through all open windows until the proper window is selected. Check that there is no border or decoration around the window at all, and that any panels or menu bars disappeared as well. Then run the calibration procedure as documented.

    You need to run the sandbox application using the exact same window position and size you used during calibration, or it won’t match. You can either use your fullscreen shortcut to maximize the sandbox window manually after start-up, or you can make it permanent by modifying a configuration file.

    Create a Vrui.cfg file in the directory from where you run the sandbox application, and put the following inside:

    section Vrui
      section Desktop
        section Window
          windowFullscreen true

    Subsequently the sandbox application will start in fullscreen mode when started from the directory that contains this Vrui.cfg. To be able to start the sandbox from anywhere and still use the custom setting, add -mergeConfig <path>/Vrui.cfg to the command line, where <path> is the full directory path to the custom Vrui.cfg file, for example /home/user/SARndbox/etc. Actually, when using the -mergeConfig option, you can name your configuration file whatever you want, say SandboxFullscreen.cfg, and place it wherever you like.

Viewing 14 posts - 481 through 494 (of 494 total)