Build the examples and configure your cameras

Build on Windows

cd <prefix>\example
cmake -S . -B build -G "Visual Studio 17 2022" -A x64 -DGSTREAMER_DIR=C:/gstreamer -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build --config Release

cd <prefix>\example
cmake -S . -B build -G "Visual Studio 17 2022" -A x64 -DGSTREAMER_DIR=C:/gstreamer -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build --config Release

cd <prefix>\example
cmake -S . -B build -G "Visual Studio 17 2022" -A x64 -DGSTREAMER_DIR=C:/gstreamer -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build --config Release

This produces example\build\Release\viewer_opengl_*.exe, with the SDK runtime DLLs copied beside them so they run directly.

Build on Ubuntu

cd <prefix>/example
cmake -S . -B build -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build

cd <prefix>/example
cmake -S . -B build -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build

cd <prefix>/example
cmake -S . -B build -Dflowbit-server_DIR=<prefix>/cmake
cmake --build build

If the loader cannot find the shared objects at run time:

LD_LIBRARY_PATH

LD_LIBRARY_PATH

LD_LIBRARY_PATH

Debug builds

To build the viewers against the debug SDK, build them in Debug:

• Windows: cmake --build build --config Debug

• Ubuntu: configure with -DCMAKE_BUILD_TYPE=Debug

The build then links <prefix>/lib/debug/ and copies the d-suffixed debug runtime DLLs next to each executable. On Linux the .so are found via RPATH, or set LD_LIBRARY_PATH=<prefix>/lib/debug. This needs an export that includes the Debug build. Debug and Release build trees can coexist.

Import your real devices into config/

[!WARNING] The config/ tree ships with per-device folders named AAAA-BBBB-CCCC-0129, …-0138 and so on. These are placeholder examples for the demo rig - they are almost certainly not your cameras, and their calibration is not deployed space.

1. Run the manager viewer:

   viewer_opengl_with_manager --config=<prefix>/config

   viewer_opengl_with_manager --config=<prefix>/config

   viewer_opengl_with_manager --config=<prefix>/config

2. Press I to list the cameras discovered on your LAN. Those are your real device IDs.

3. Press C and type a device ID to connect it. On connect, the manager reads that camera's own device_config.json, capture_config.json and sensor_config.json and writes them into config/<device-id>/.

4. Repeat once per camera. You then have a config/<device-id>/ folder for every real device, ready for the streaming and segment viewers' --devices argument.

Supply the calibration

Every config/<device-id>/sensor_config.json contains a "Sensor to World Extrinsic" - a 4×4 row-major matrix giving that camera's pose in the shared world frame. This is what places each camera's cloud into one common coordinate system so multiple cameras overlap instead of drifting apart, and it is what 3D segmentation fuses against.

This matrix comes from Calibration. Flowbit Calibration computes it and syncs it for you. Do not compute it by hand.

RESOLVE(software): State the exact mechanism. Does the SDK read calibration_result.json directly, or must each matrix be copied into sensor_config.json? The original SDK documentation instructs developers to "measure/calibrate your own rig and edit this matrix per camera", with no mention of Flowbit Calibration - the two documents describe two different workflows. See docs-restructure-plan/PLAN.md §4, gap 4.

Depth to Color Extrinsic and the intrinsics in the same file come from the device and normally need no editing.

Advanced: setting the extrinsic manually

Identity places the camera at the world origin. Symptoms of a wrong extrinsic are clouds that do not line up, or detections that ghost or land in the wrong place.

Next steps

Run examples