How to install the Azure Kinect SDK on Ubuntu 16.04

By Thomas Weng on July 19, 2019

Microsoft recently released the Azure Kinect DK sensor, a $399 developer-oriented sensor kit for robotics and mixed reality applications. The kit’s SDK officially supports Windows and Linux 18.04. I’ve managed to get the v1.1 SDK working on Ubuntu 16.04, and have documented the steps below.

Why downgrade to Ubuntu 16.04?

Many of the robots I work with or have worked with are tied to Ubuntu 16.04, e.g. the Rethink Robotics Sawyer robot, as well as the PR2. Upgrading the robot hardware to 18.04 is difficult and would break existing projects. Although upgrading to 18.04 will eventually be necessary, it is helpful to have the Azure Kinect DK working on 16.04 in the meantime.

Installation steps

These steps worked for me on an existing Ubuntu 16.04 installation, not a fresh one, so your mileage may vary.

  1. Download the v1.1 SDK from Github.1
    $ git clone https://github.com/microsoft/Azure-Kinect-Sensor-SDK/tree/release/1.1.x
    
  2. Install dependencies using the provided script.
    $ bash ./Azure-Kinect-Sensor-SDK/scripts/bootstrap-ubuntu.sh
    
  3. Follow the build steps in https://github.com/microsoft/Azure-Kinect-Sensor-SDK/blob/release/1.1.x/docs/building.md.
    • If you get a CMake error, you may need to upgrade CMake2.
      % Download and extract cmake 3.14.5
      $ mkdir ~/temp
      $ cd ~/temp
      $ wget https://cmake.org/files/v3.14/cmake-3.14.5.tar.gz
      $ tar -xzvf cmake-3.14.5.tar.gz
      $ cd cmake-3.14.5/
      
      % Install extracted source
      $ ./bootstrap
      $ make -j4
      $ sudo make install
      $ cmake --version
      
    • If you get a libsoundio error, you may need to install jack-tools.
      $ sudo apt-get install jack-tools
      
  4. Get a copy of the depthengine binary libdepthengine.so.1.0 and missing dependencies

    libdepthengine.so.1.0 is closed-source code for processing the raw depth stream from the camera. This binary is included as part of k4a-tools, the Azure Kinect SDK Debian package for Ubuntu 18.04.

    As a result, you’ll need to install k4a-tools on an Ubuntu 18.04 OS following these instructions, then copy the files installed into /usr/local/lib/x86_64-linux-gnu onto your Ubuntu 16.04 OS.3

    In practice, I found that I only needed libdepthengine.so.1.0 and libstdc++.so.6 from the x86_64-linux-gnu folder.

  5. Copy the depthengine binary and missing dependencies into the bin/ folder generated by the build in step 3.
    $ cp path/to/x86_64-linux-gnu/libdepthengine.so.1.0 path/to/Azure-Kinect-Sensor-SDK/build/bin/libdepthengine.so.1.0
    $ cp path/to/x86_64-linux-gnu/libstdc++.so.6 path/to/Azure-Kinect-Sensor-SDK/build/bin/libstdc++.so.6
    
  6. Test the installation by running the SDK viewer.4
    $ sudo path/to/Azure-Kinect-Sensor-SDK/build/bin/k4aviewer
    

    If all went well you be able to open your device and see all data streams coming in as below.

Screenshot from k4aviewer

To integrate the sensor with ROS, take a look at my follow-up post: How to install ROS drivers for Azure Kinect on Ubuntu 16.04


Footnotes

  1. I used commit fd6f537bb5ad9960faafc80a3cededbc8eb68609, but a later commit may work. 

  2. https://askubuntu.com/questions/355565/how-do-i-install-the-latest-version-of-cmake-from-the-command-line 

  3. Or find a friend who has a copy :) 

  4. There are instructions for running the viewer as non-root here 

Tags: robotics

Using my calendar as a time log

By Thomas Weng on January 5, 2019
~4 min. read

I used to only use my calendar to track upcoming meetings. But then I read Philip Guo’s blog post on time management, and was fascinated by how he used his calendar to show where his time went.

The color-coding makes it easy to review at a glance.

I decided to try Philip’s calendaring method to see if I was being as productive as I thought. It’s been over a year since I started logging, and I have found it to be great not only for gauging my past productivity, but also for kickstarting changes to how I spend time going forward.

In the rest of this post, I’ll describe how I log my time and talk about the insights I’ve gained in more detail.

Logging is simple and flexible

There’s not much to it—after working on a task, I create a calendar entry for the time spent and color-code it. I use Google calendar, but any kind of calendar works. Here is an example of what one of my recent work days looks like.

Had a slow morning and missed my bus...didn't want to spend more time looking for an ~ideal~ day

I’ve color-coded the activities as follows:

Pink Health
Grey Travel
Blue Coursework
Cyan Research
Green Social and Family

The system is very flexible. You can use whatever color categories suit you best. Your labels for each activity can be as simple or as descriptive as you like. You can even adapt it for a productivity methodology like David Allen’s Getting Things Done or Cal Newport’s Deep Work. Cal Newport even describes a similar method of logging your time.

Logging shows me where my time goes and how to adjust

Since I started using this method, I have a better sense of how I’m spending my time compared to when I relied on my intuition. I’m able to catch patterns of behavior and reinforce them if they are positive, or work on eliminating them if they are negative. For example, I’ve noticed that my energy and focus dips in late afternoon before returning in the evening. Taking a break from work to nap or exercise helps me get through the slump.

I also have a better sense of the present. Logging each task helps me be more deliberate about each activity I start, and makes me aware of deviations from my planned schedule quickly, so that I don’t reach the end of the day and realize too late that I went off track.

Some may think it takes a lot of work to log time like this, but it really doesn’t take long. To me, the benefit of having a better handle on my time is worth the few moments it takes to do the logging.

Some final notes

  • If there are events that fit into multiple categories, I don’t worry too much about it and just pick one.
  • I work in thirty minute chunks, so I set the default event duration in Google calendar to thirty minutes instead of an hour.
  • I also generally try not to have overlapping things in my calendar. If there are conflicting events, I will cancel my appointment with the less important one and move it off my calendar or gray it out. I can’t be in two places at the same time anyway.
  • Unlike Philip Guo, I don’t keep track of my efficiency level for each task. I found it both difficult and distracting to assess how efficient I was.
  • In a way, this is similar to the post I wrote about how I journal in that it’s about recording things. When I started using this calendar, I stopped journaling my day-to-day items in as much detail because the calendar serves that purpose now. But I’ll still put my thoughts and feelings in my journal.

Many thanks to Cherie Ho and Ada Taylor for reviewing this post!

Tags: productivity

Staying on top of email

By Thomas Weng on November 3, 2018
~1 min. read

I find it hard to be productive when my inbox is cluttered with emails. It’s easy to lose track of high-priority tasks in a messy inbox.

Screenshot of someone's inbox from the Internet. 13k unread emails = instant anxiety.

To keep a tidy inbox, I aim for Inbox Zero daily. That means for each email:

  1. If there’s a task that can be done in a minute, I’ll do it immediately and archive it.

  2. If there’s a task to be done today, I’ll add it to my to-do list and then snooze the email.

  3. If the task isn’t urgent, I’ll just snooze it to whenever I can/need to do it.

Much better!

I don’t always achieve an empty inbox following this approach, especially when a lot of things are happening at once. The goal may also not always be to clear all emails, if you need some handy for your task for example.

Though I tried to keep my approach lightweight, there’s definitely room for improvement. For example, I’m still experimenting to find a good to-do list workflow. I could be more disciplined about when I check my email to avoid interruptions in my work. So far, though, this method is pretty effective in helping me stay organized.

Tags: productivity

Setting up TeX math rendering for your blog or website

By Thomas Weng on April 26, 2018
~1 min. read

Setting up \(\TeX\)math typesetting on your website is one of those tasks that can seem really difficult if you don’t know what to look for. Here’s a simple way to do it.

I used Khan Academy’s KaTeX typesetting library for my blog. KaTeX is fast, self-contained, and works largely as you would expect. Here are the instructions:

  1. Include KaTeX on your site by adding the required reference tags and scripts to your html template1. See this commit for the changes I made to get it working on this blog.

  2. Typeset math by enclosing your notation within \\( and \\) for inline typesetting, or \\[ and \\] for typesetting on a separate line.

    For example, with inline typesetting, \\(\alpha\\), becomes \(\alpha\). With non-inline typesetting, \\[x^2 + y^2 + z^2 = r^2\\] becomes: \[x^2 + y^2 + z^2 = r^2\]

  3. If you have any rendering issues, check your console for error messages. Also take a look at the full documentation on Github.


Footnotes

  1. You can also download these files and host them on your server directly instead of getting them from the cdn. 

Tags: blogging

Automating C++ builds in ROS

By Thomas Weng on September 9, 2017
~3 min. read

If you’re working on a C++ ROS project, you probably run catkin build every time you make a change. This is tedious and takes you out of your programming flow. It’s especially annoying when your build fails multiple times due to small errors. I’m a big proponent of keeping the iteration loop as small as possible.1

To fix this, I’ve automated the build process to build when saving a file! No more manual building :).

Here’s how it works. I’ve written a shell script called builder.sh that kicks off a build for you every time you save a file in your source directories. If the build fails, it will output the error. If the build succeeds, it’ll print a success message. Here’s an example of a build failure, followed by success:

$ bash builder.sh
Setting up watches.
Watches established.
octomapper.cpp modified, rebuilding...
_______________________________________________________________________________
Errors     << perception:make /home/tweng/catkin_ws/logs/perception/build.make.1447.log
/home/tweng/catkin_ws/src/ros-project/src/perception/src/octomapper.cpp: In member function ‘void perception::Octomapper::publish_octomap(octomap::OcTree*)’:
/home/tweng/catkin_ws/src/ros-project/src/perception/src/octomapper.cpp:99:3: error: ‘pub’ was not declared in this scope
   pub.publish(octomap_msg);
   ^
make[2]: *** [CMakeFiles/perception_octomapper.dir/src/octomapper.cpp.o] Error 1
make[1]: *** [CMakeFiles/perception_octomapper.dir/all] Error 2
make: *** [all] Error 2
cd /home/tweng/catkin_ws/build/perception; catkin build --get-env perception | catkin env -si  /usr/bin/make --jobserver-fds=6,7 -j; cd -
...............................................................................
Failed     << perception:make           [ Exited with code 2 ]

There is syntax highlighting in your terminal which makes this output more readable.

After fixing the issue and saving, the build runs again automatically:

octomapper.cpp modified, rebuilding...
[build] Summary: All 2 packages succeeded!

It’s fairly simple to get this set up for your workspace. You’ll need to:

  1. Get the script from this Github gist: builder.sh
  2. Configure it to watch your workspace directories
  3. Run it in a terminal using bash builder.sh
  4. Start coding and enjoying ~build-on-save~

But wait, there’s more: roslaunch auto-restart!

After your build completes, you’ll probably need to run or restart your ROS nodes to test your changes. That’s another manual step we can automate.

This time, a script called launcher.sh runs your project’s roslaunch command and listens periodically to make sure your ROS nodes are alive. As you make changes and get a successful build, builder.sh – the original script – sends a signal to kill your ROS nodes.2 When the ROS nodes die, launcher.sh will automatically restart them, grabbing your newest build. Here’s an example of what restarting looks like:

$ bash launcher.sh
Launching roslaunch
... logging to /home/tweng/.ros/log/3674ab20-73be-11e7-b57f-b8ca3ab4b589/roslaunch-silverarm-15112.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://localhost:39545/

...

/process_cloud_main shutdownCallback:163: Shutdown request received.
/process_cloud_main shutdownCallback:164: Reason given for shutdown: [user request]
================================================================================REQUIRED process [process_cloud_main-1] has died!
process has finished cleanly
log file: /home/tweng/.ros/log/3674ab20-73be-11e7-b57f-b8ca3ab4b589/process_cloud_main-1*.log
Initiating shutdown!
================================================================================
[publish_saved_cloud-3] killing on exit
[person_broadcaster-2] killing on exit
[process_cloud_main-1] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

launcher.sh notices that the node has gone down and triggers a restart:

Launching roslaunch
... logging to /home/tweng/.ros/log/3674ab20-73be-11e7-b57f-b8ca3ab4b589/roslaunch-silverarm-30141.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://localhost:34414/

You can get launcher.sh here. You’d run it in a terminal (bash launcher.sh), just like the first one.

If your builds take a lot of processing power and/or take a long time, you may need to make adjustments to this script. I personally haven’t had any problems rebuilding on every save. One option if you do have problems is to rebuild only the package you are working on, and not the whole workspace.

Hope this helps and you find it useful!


Footnotes

  1. Originally inspired by Brett Victor’s talk, “Inventing on Principle.” Check it out a recording of it here: video link

  2. I set the main node with the required=true attribute in my launch file so I only need to kill that node to stop the others.