Azure_Kinect_ROS_Driver icon indicating copy to clipboard operation
Azure_Kinect_ROS_Driver copied to clipboard

Ubuntu SDK source installation. How to let the Azure Kinect ROS driver know about this?

Open carcormir opened this issue 4 years ago • 9 comments

Hi!

Describe the bug We had some issues with the Azure Kinect SDK, for that reason the developers made some changes in the develop branch (here) so we had to install the SDK from source without using the .deb as suggested in their instructions. The problem is that as #118 mentioned, it is not very clear from the documentation how to make the ROS driver know where to look for the SDK. I looked at the CMakeLists.txt of the ROS driver but could not figure out how to make it work.

To reproduce Follow the instructions to build from source from Azure Kinect SDK git documentation. There is no specification on where to clone the repository to later on build the tool so I chose my working directory (I am guessing that you could choose any directory?) I also installed libk4a1.4 from the debian since they suggest to do so to include the depth libraries.

Desktop:

  • OS: Ubuntu 18.04

carcormir avatar May 06 '20 12:05 carcormir

When you manually build the Azure Kinect SDK the binaries you care about will be placed in the bin folder of the build location you called Ninja from.

Simmilarly if you use VS2017, it will create build<target_type>\bin\RelWithDebInfo and place the built binaries there.

@ooeygui any idea where to copy them from here?

wes-b avatar May 21 '20 17:05 wes-b

I was aware of where to find the binaries but In any case thanks for your comment. As you may have guessed I am having trouble linking the binaries with the ROS driver. Hopefully @ooeygui could give us some guidelines.

carcormir avatar May 22 '20 19:05 carcormir

The code that attempts to find the k4a binaries lives in https://github.com/microsoft/Azure_Kinect_ROS_Driver/blob/melodic/cmake/Findk4a.cmake.

Currently it is specifically looking for binaries in the system path. Without doing testing, I suspect that you can add the output path into your system path.

ooeygui avatar May 22 '20 19:05 ooeygui

I added the /build/bin directory to the system path. I also had to add /build/src/sdk and create some symbolic links to avoid errors in the catkin build step. These are the added lines in the system path:

export PATH="/home/usr-name/Desktop/Azure-Kinect-Sensor-SDK/build/src/sdk:${PATH}"
export PATH="/home/usr-name/Desktop/Azure-Kinect-Sensor-SDK/build/bin:${PATH}"

However, now I am getting this error during the catkin build step, that I am not sure how to solve:

CMake Error at /home/usr-name/catkin_ws/src/Azure_Kinect_ROS_Driver/cmake/Installk4a.cmake:21 (message):
  Target 'k4a::k4a' in package k4a does not contain an IMPORTED_LOCATION**
  property
Call Stack (most recent call first):
  CMakeLists.txt:106 (include)

Maybe I have to add other paths to the system path?

Thanks in advanced for the help!

carcormir avatar May 23 '20 09:05 carcormir

Any follow up on this @ooeygui ? If I did any of the steps wrong or you have the right steps to follow to make it work I would really appreciate any inputs. Thanks in advance!

carcormir avatar Jun 01 '20 20:06 carcormir

@carcormir I just wanted to let you know that I see the thread, but have not been able to dig into this yet.

ooeygui avatar Jun 01 '20 21:06 ooeygui

Hi @ooeygui , I found a workaround to make this work. These are the steps I followed:

  1. Install the debian packaged libk4a1.4 and libk4a1.4-dev using apt/apt-get
  2. Download the debian package and extract it. Locate the libdepthengine library. You could probably just use the libdepthengine.so.xx that comes with in the 1 step but I have not tried. Notice that for the later case libdepthengine.so.xx is located in /usr/lib/x86_64-linux/libk4a1.4/
  3. Build the desired SDK version from source following the steps provided in the documentation.
  4. Copy libk4a.so.1.4.0 (from your build_from_source_directory/build/bin), libk4arecorder.so.1.4.0 (from your build_from_source_directory/build/bin) and libdepthengine.so.2.0 (from the extracted debian package mentioned in step 2). Copy this files into /usr/lib/x86_64-linux which is where the SDK was installed in step 1. In that directory you may find the same files with the same name. Just force the copy to substitute the files with the new ones.

That did the fix for me. The /ext/sdk folder structure mentioned in the Documentation as alternative installation does not match with the structure created when building from source in Ubuntu. Even when forcing the Findk4a.cmake to look into the right place, you would need to create multiple symbolic links and maybe that will work. It did not in my case since the structure does not follow the bin, lib, include type.

In any case, thanks for the help and let me know if you have any suggestions.

carcormir avatar Jun 02 '20 08:06 carcormir

I encountered the same issue and spent nearly 3 hours debugging this. For my case, I didn't clear the local cache /usr/local/lib/cmake. Therefore, the CmakeList found two files of the same name, one in the system path, one in the user local path. Since the user local copies do not have symbolic links attached, the compilation always fails. Simply do sudo rm -r -f /usr/local/lib/cmake/ solves my issues.

AlexSunNik avatar Dec 12 '20 01:12 AlexSunNik

@AlexSunNik Thank you for your investigation.

ooeygui avatar Dec 12 '20 18:12 ooeygui