Skip to content

Build fails on Jetson (ARM64) for OrbbecSDK_ROS2 with file format not recognized and `dlopen errorBuild and Runtime Issues on Jetson with Astra Pro Plus: Placeholder Libraries and Point Cloud Failures #141

@wahaha-1

Description

@wahaha-1

Environment

  • Hardware Platform: NVIDIA Jetson orin nano 4G (ARM64 architecture)
  • Operating System: Linux
  • Software: ROS2, orbbec_camera ROS2 package
  • SDK Version: Orbbec SDK v1.10.22 (from the official linux_arm64_release.zip package)

Problem Description

While compiling the orbbec_camera package on a Jetson platform, I encountered a series of issues ranging from linking during compilation to library loading at runtime. The root cause is that the library files provided in the orbbec_camera repository's SDK/lib/arm64/ directory are invalid placeholders (ASCII text files) instead of genuine ELF shared libraries.

Steps to Reproduce & Solutions Tried

  1. Initial Compilation Failure: A direct colcon build after cloning the OrbbecSDK_ROS2 repository fails during the linking phase of liborbbec_camera.so with the error:

    /usr/bin/ld: .../orbbec_camera/SDK/lib/arm64/libOrbbecSDK.so: file format not recognized
    

    Using the file command, I confirmed that libOrbbecSDK.so at this path is an ASCII text file.

  2. Installing the Correct SDK: I downloaded the official OrbbecSDK_C_C++_v1.10.22_..._linux_arm664_release.zip. After extracting it, I found the real library file is lib/libOrbbecSDK.so.1.10.22 (a valid ELF shared library). I installed it to the system path /usr/local/lib/ and created the correct symbolic links:

    /usr/local/lib/libOrbbecSDK.so -> libOrbbecSDK.so.1.10.22
    /usr/local/lib/libOrbbecSDK.so.1.10.22 (ELF 64-bit LSB shared object, ARM aarch64)
    
  3. Resolving the Compilation Issue: To allow the build to pass, I copied the real file, /usr/local/lib/libOrbbecSDK.so.1.10.22, and renamed it to libOrbbecSDK.so, overwriting the placeholder file in the src/orbbec_camera/SDK/lib/arm64/ directory. After this, colcon build completed successfully.

  4. Runtime Loading Failure: After a successful build, running ros2 launch orbbec_camera astra.launch.py fails to start the node with the error:

    [ERROR] [...]: Failed to load library: Could not load library dlopen error: /home/wahaha/Desktop/AstraProPlus/install/orbbec_camera/lib/libOrbbecSDK.so.1.10: file too short ...
    
  5. Root Cause Analysis: I inspected the install/orbbec_camera/lib/ directory and found the following:

    • libOrbbecSDK.so and libOrbbecSDK.so.1.10.22 are the genuine ELF files that I copied (around 10MB).
    • libOrbbecSDK.so.1.10, however, is an invalid ASCII text file (only 23 bytes).

    It appears that during the installation phase, colcon build not only bundles the real library files but also packages other placeholder files with similar names from the src/orbbec_camera/SDK/lib/arm64/ directory. At runtime, dlopen attempts to load this incorrect libOrbbecSDK.so.1.10 file, leading to the "file too short" error.

My Questions

What is the best practice for handling compilation and runtime issues caused by placeholder library files provided in an upstream repository?

  1. Manual Cleanup? Should I manually clean up the src/orbbec_camera/SDK/lib/arm64/ directory before building, removing all placeholder files and keeping only the genuine library files and necessary symbolic links?
  2. Modify CMake? Alternatively, should I modify the orbbec_camera CMakeLists.txt file to ignore the bundled SDK directory and force it to link against the system-wide SDK I've installed in /usr/local/lib?
  3. Other Solutions? Are there other, more standard solutions for this situation?

Part 2: Runtime Point Cloud Failure (No valid point in point cloud)

Description

After resolving the build issues, the orbbec_camera node starts successfully and connects to the Astra Pro Plus. However, it fails to generate any point cloud data, and the log is continuously spammed with the warning: [WARN] [camera.camera]: No valid point in point cloud.

Analysis

  • Native SDK Demo Works Perfectly: I can run the native SDK example (./OBMultiStream) without any issues. It streams color and depth data correctly, which confirms the camera and the low-level SDK are functioning properly. This suggests the problem lies within the ROS2 wrapper's configuration.
  • Likely Cause is USB 2.0 Bandwidth: The Jetson is connected to the camera via USB 2.0. The default launch parameters for resolution and frame rate (640x480 @ 30 FPS for both color and depth) likely saturate the USB 2.0 bandwidth, causing data corruption or loss that prevents point cloud generation.
  • Partial Workaround: I found that I can get the node to function somewhat by reducing the data load with launch arguments:
    ros2 launch orbbec_camera astra_adv.launch.py enable_ir:=false depth_format:=Y11
    While this helps, it is not a stable or complete solution.

Request for Part 2

Since the native SDK demo works, it must be using a more optimized configuration. Could you please provide a recommended launch file or a set of optimized parameters specifically for the Astra Pro Plus that is tested to work reliably over a USB 2.0 connection?

Relevant Log Output for Part 2

[component_container-1] [INFO] [1757069238.799566346] [camera.camera]: usb connect type: USB2.0
...
[component_container-1] [INFO] [1757069238.064674102] [camera.camera]:  stream color is enabled - width: 640, height: 480, fps: 30, Format: OB_FORMAT_RGB
[component_container-1] [INFO] [1757069238.065488146] [camera.camera]:  stream depth is enabled - width: 640, height: 480, fps: 30, Format: OB_FORMAT_Y11
...
[component_container-1] [WARN] [1757069310.211786350] [camera.camera]: No valid point in point cloud
[component_container-1] [WARN] [1757069310.213881142] [camera.camera]: No valid point in point cloud
...
Image

Thank you

Metadata

Metadata

Assignees

No one assigned

    Labels

    arm64The type of system usedastramainbranch

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions