Useful Links - Build with Yocto

Follow us on:

Share This Page

Facebook Twitter LinkedIn WhatsApp Email Copy Link

Close

Send Email Using

Gmail (Web) Thunderbird (default mail app)

Close

RidgeRun Video Stabilization Library

<

RidgeRun Video Stabilization Library

Table of Contents [Sticky]

• Basics and Foundation
  • What is Video Stabilization
  • Video Stabilization Process using IMU
  • Stabilization Algorithms with IMU
  • Video Stabilization Process using Optical Flow
• Getting Started
  • Supported Platforms, Sensors and Backends
  • Evaluating the Library
  • Getting the Code
  • Building the Library
• API Reference
  • Library Architecture
  • Adding New Sensors
  • Adding Algorithms
  • Adding Smoothing Algorithm
  • Adding Backends
  • Adding OpticalFlow Algorithms
  • Adding Transformation Algorithms
  • Digital Stabilizer
  • Electronic Stabilizer
  • API Documentation
  • Examples Guidebook
• Library Integration for IMU
  • Preparing the Video
  • Preparing the IMU Measurements
  • Measurement Integration
  • Interpolation
  • Computing the Stabilization
  • Video Undistortion
  • Example Application
• Library Integration for DIS
  • Preparing the Frames
  • Preparing the Runtime Settings
  • Example Application
• GStreamer
  • Add Support for Video Timestamps (EIS)
  • Add Support for IMU Sensors (EIS)
  • Electronic Video Stabilizer Element (IMU-Assisted)
  • Digital Video Stabilizer Element
  • Analyzer Element
  • Example Pipelines
• Calibration Process (EIS)
  • Installing Calibration Tool
  • Camera Calibration
  • IMU Calibration
  • Tuning Process
• Useful Links
  • BMI160 Setup
  • ICM42688 Setup
  • Performance
  • Jetson setup
  • Horizon Lock guide
  • Build with Yocto
• Contact Us

RVS Yocto Build Guide

This guide describes how to build the RidgeRun Video Stabilizer (RVS) recipe from meta-ridgerun-github. It is intentionally focused on the recipe and its OpenCL/CUDA backend selection. This guide shows steps for a clean build, if you have an existing build setup, you should adjust only the neccesary changes.

Layer setup

Start from a compatible Poky build directory and add the required layers to conf/bblayers.conf:

BBLAYERS += " \
  /path/to/meta-ridgerun-github \
  /path/to/meta-openembedded/meta-oe \
  /path/to/meta-openembedded/meta-python \
  /path/to/meta-openembedded/meta-multimedia \
"

meta-oe provides the OpenCL recipes used by RVS. meta-python and meta-multimedia are also required by the RidgeRun layer configuration.

For a Jetson image, add meta-tegra as well:

BBLAYERS += " /path/to/meta-tegra "

Use the oe-init-build-env script for the Poky checkout before invoking BitBake:

source /path/to/poky/oe-init-build-env /path/to/build

RVS recipe behavior

recipes-multimedia/gstreamer/rvs_git.bb builds the RVS library and its GStreamer plugin. It always enables OpenCV and GStreamer support.

Target configuration	PACKAGECONFIG selected by the recipe	Backend
Non-Tegra target, including qemux86-64	opencl	OpenCL enabled; CUDA disabled
Tegra/Jetson target with meta-tegra	cuda	CUDA enabled; OpenCL disabled

For OpenCL builds, the recipe depends on opencl-headers, opencl-clhpp, and virtual/opencl-icd. opencl-clhpp supplies CL/opencl.hpp, used by current RVS source. The OpenCL loader is built into the target; an actual OpenCL platform/device still requires an installed ICD vendor driver.

For CUDA builds, meta-tegra supplies the cuda override and the recipe adds the Tegra CUDA libraries. Do not force CUDA on a non-Tegra target.

local.conf examples

Add RVS to an image:

IMAGE_INSTALL:append = " rvs opencv "
IMAGE_FEATURES:append = " ssh-server-openssh "

rvs pulls in its declared runtime dependency, gstcameradrivermeta. Add other GStreamer plugins or camera source packages only when the intended pipeline needs them.

QEMU/OpenCL compile test

Use the standard QEMU machine and do not include meta-tegra:

MACHINE = "qemux86-64"
IMAGE_INSTALL:append = " rvs opencv "

Do not add Jetson-specific packages such as cuda-samples, NVIDIA kernel modules, tegra-tools-tegrastats, or kernel-module-r8168 to this QEMU image. They are not provided by the QEMU kernel or by a build without meta-tegra.

Build the recipe or a minimal image:

bitbake rvs
bitbake core-image-minimal

This proves that the OpenCL backend compiles and links. QEMU normally has no OpenCL ICD vendor/device, so it is not a GPU/OpenCL runtime-acceleration test.

Jetson/CUDA image

Enable meta-tegra, select the exact machine that matches the board and root filesystem storage, then include RVS:

MACHINE = "jetson-orin-nano-devkit-nvme"
IMAGE_INSTALL:append = " rvs opencv "

jetson-orin-nano-devkit-nvme is for an Orin Nano developer kit whose rootfs is on NVMe. Use the matching meta-tegra machine for another Jetson board or storage layout. The CUDA override then selects RVS’s CUDA backend automatically. Keep Jetson-only packages behind a Tegra override if the same configuration may also build QEMU:

IMAGE_INSTALL:append:tegra = " cuda-samples tegra-tools-tegrastats "

Enable the BMI160 IMU driver

The Tegra kernel append in this layer includes recipes-kernel/linux/files/bmi160.cfg. It enables the IIO buffers and the BMI160 core and I2C drivers:

CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
CONFIG_BMI160=y
CONFIG_BMI160_I2C=y

To inspect or adjust these settings for the selected Jetson kernel, run:

bitbake -c menuconfig virtual/kernel

In menuconfig, press /, search for BMI160, and enable BMI160 plus BMI160_I2C; also enable the prompted IIO buffer options. Save the configuration, then record the required symbols in a kernel configuration fragment in the layer rather than relying on the generated work-directory .config. Rebuild the kernel or image after updating the fragment.

Verification

On a built target, confirm the library is and plugin is installed:

readelf -d /usr/lib/librvs.so.* | grep NEEDED
readelf -d /usr/lib/gstreamer-1.0/libgstrvstabilize.so | grep NEEDED
gst-inspect-1.0 | grep -i rvs

Brief Jetson flashing outline

1. Build the desired image for the selected Jetson MACHINE.
2. Locate the generated tegraflash archive under tmp/deploy/images/${MACHINE}/.
3. Put the board into recovery mode and connect it by USB to the build host.
4. Extract the archive into an empty directory and run its initrd-flash helper according to the generated package instructions.
5. Power-cycle or reboot the board and verify the rootfs storage device.

For Orin Nano/NX systems using an NVMe rootfs, use initrd flashing. Do not use the direct doflash.sh path for this configuration. Flashing changes boot and storage partitions; verify the selected machine and storage layout before running the generated script.

For more detail, consult meta-tegra/docs/initrd-flashing-support.md in the same revision of meta-tegra used for the build.

Back to top ↑ <