Using Library on Linux
Aurora Vision Library is designed to be used with GCC compiler on Linux x86_64, embedded ARMv7-A and ARMv8-A systems.
gcc in version 5.4 is supported,
and corresponding toolchains for embedded linux:
Custom build can be prepared upon the earlier contact with Aurora Vision team.
The Aurora Vision Library is distributed as
The library is compatible with Debian-like system, including - but not limited to - Ubuntu distributions.
Properly set locale on target computer is important.
Non-existing locale will cause bugs and bad behavior.
To list locale that exists on your computer use:
and currently set:
Remember that running your application as daemon (e.g. from
systemd) may set different locale,
than the one in your user terminal.
Refer to your Linux distribution documentation.
To build example in simple manner, GNU Make tool and CMake is needed.
- Ubuntu 16.04/Debian 9 or newer:
- package libc6 ≥ 2.23
- package libudev1 ≥ 229
- package g++ version ≥ 5.4
- package make
- package cmake version ≥ 3.5
sudo apt-get install cmake make g++
sudo apt-get install libgtk-3-dev libsdl-dev qtbase5-dev
- CentOS 8/Fedora 29/OpenSUSE 15.0 or newer:
- package glibc ≥ 2.23
- package systemd ≥ 229
- package gcc-c++ version ≥ 5.4
- package make
- package cmake version ≥ 3.5
dnf install gcc-c++ make cmake
zypper install gcc-c++ make cmake
dnf install SDL2-devel qt5-qtbase-devel gtk3-devel
zypper install libSDL2-devel libqt5-qtbase-devel gtk3-devel
- libraries libc.so.6, libpthread.so.0, libm.so.6, libdl.so.2, librt.so.1, libgcc_s.so.1 from glibc version ≥ 2.23 or compatible (i.e. musl libc)
- library libudev.so.1 from systemd version ≥ 229
Supported input devices
|Allied Vision Vimba||✔||✔||✔|
In unpacked directory call the
This command will install the library to a proper directory in opt.
It will also make the library visible to CMake
Unpacked directory consists of following entries:
examples/- directory contains source files of example programs written with Aurora Vision Library
include/- this directory contains library header files
lib/- here the .so file with library is stored, along with any kits
bin/- directory for additional binaries, like Licensing tool.
/README- instruction of library usage
/sha512sum- checksums for all files in archive, check with
sha512sum --quiet -c sha512sum
/metadata.json- file containing information about the optimal target system, and library version
/install- installation script
/uninstall- uninstall script, will be copied to installation directory, where it can be safely used
A simple template for a
CMakeLists.txt file is presented below:
cmake_minimum_required(VERSION 3.5) project(avlexample) find_package( AVL # for a specific version, uncomment the line below #4.11 CONFIG REQUIRED ) add_executable( # executable name example_exec # source files main.cpp ) target_link_libraries( example_exec PUBLIC AVL )One can also copy one of the CMake examples, and modify to your needs. For further cmake use refer to online documentation. Be aware that ubuntu 16.04 is the baseline distribution, so minimal CMake version is 3.5
Using Makefile or your custom build system
For compiling with Aurora Vision Library please remember to:
- add the
include/subdirectory to the compiler include directories:
- add the
lib/subdirectory to the linker directories:
- link with Aurora Vision Library:
-rpathin linker options,
- link with dependencies:
-lpthread -lrt -ldl
One can consult makefile in the examples/ directory to see how to compile and link with Aurora Vision Library.
Known compilation bugs
In case of the following linker errors: (or similar)
/usr/bin/ld: warning: libiconv.so, needed by lib/libAVL.so, not found (try using -rpath or -rpath-link) lib/libAVL.so: undefined reference to `libiconv' lib/build/libAVL.so: undefined reference to `libiconv_close' lib/build/libAVL.so: undefined reference to `libiconv_open'
It is a known gnu linker bug, affecting versions older than 2.28 (e.g. in Ubuntu 16.04).
To solve the problem you can:
- Try a different linker (add for linking
-fuse-ld=goldfor gold or
-fuse-ld=lld, consult your linux distribution manual)
- Link with the missing library (for example add
- Update the linker (
binutils2.28 or newer)
Licensing and distribution
File based licenses are supported on all Linux platforms. Dongle licenses depend on CodeMeter runtime. Currently Codemeter runtime is available for x86_64 and ARMV7-A. To develop and debug programs written with Aurora Vision Library, Library license has to be present. To run compiled binaries linked with Aurora Vision Library, LibraryRuntime license has to be present.
One can use
bin/ directory to list currently installed file or dongle
Red marked licenses are invalid, for example past the license date or installed license for the wrong machine (bad ID)
To obtain license:
- In a terminal, on the target machine run
- Copy the printed Computer ID
- Use that Computer ID to get a
.avkeyfile from User Area on www.adaptive-vision.com website.
- Download the key to the target machine
- Install the license by one of the following methods:
- Run in terminal
license_manager install downloaded_file.avkey(Recommended)
- Copy the
.avkeyfile next to executable, that is using Aurora Vision Library
- Run in terminal
Installed CodeMeter Runtime is required, as well as proper license available on plugged in dongle.
Download runtime package from WIBU
section "CodeMeter User Runtime for Linux".
"Driver Only" (lite) version recommended for headless (no desktop GUI) installations. ARMV7-A is available under "CodeMeter User Additional Downloads" as "Raspberry PI" version
To distribute program with Aurora Vision Library, one have to provide license (file or dongle - depending on system used) and
To provide the
.so file, one can install SDK on target machine, but this will provide headers etc.,
which may be unwanted.
In such case, the library file, with any used kits should be copied to suitable system directory,
or the program has to be compiled with
-rpath and relative path to the .so file.
Third option is to provide a boot script,
which will set
Program development - general advise
The most convenient way to make programs with Aurora Vision Library for Linux is to develop vision algorithm using Aurora Vision Studio on Windows and then generating C++ code. This code can be further changed or interfaced with rest of the system and tested on Windows. Then, cross-compiler can be used to prepare Linux build, which will be provided to target machine. It is easy to organize work this way, because:
- developing vision algorithm using plain C++ is hard, troublesome and error prone, but Aurora Vision Studio makes it easy,
- programs written with Aurora Vision Library on Windows can be easily debugged using Microsoft Visual Studio thanks to provided debug visualizers and the Image Watch extensions to Microsoft Visual Studio,
- cross compilation using virtualization solution, like Vagrant, is easy and fast, and does not force developer to use two systems simultaneously.
Of course, the programs can be also developed on Linux machine directly.
Then a dose of work should be put into writing good
Debugging can be done by GDB, but we do not provide debug symbols for Aurora Vision Library.
Some architectures might impose restrictions on libavl code. In this section we present pitfalls the user should be aware of.
There are many identical cores. One might have a problem when cores span across multiple physical CPUs, frequent on servers. The CPU's don't share CPU cache, so when execution of thread from CPUx/COREa is moved to CPUy/COREb, cache needs to be updated. It imposes time penalty. A workaround would be to pin threads to specific cores, (set affinity) or limit execution of libavl to specific number of cores on one physical CPU.
tasksetlinux command to limit execution on specific cores
OMP_PROC_BIND=TRUEenvironment variable to bind threads to cores they started on
There are different kinds of processors the code runs on. Some examples are ARM big.LITTLE architecture, (where the cores mainly differ in maximum speed), or Tegra TX2 (where the cores serve different purpose). This kind of architecture might also suffer from Homogeneous Multiprocessor problems, but might suffer from different set of problems. One have to consider the cores are designed for low power and high performance, single threaded multithreaded optimized. Use the same solutions as in previous point, just take into account what type of algorithm will be executed.
This CPU is an example of Heterogeneous Multiprocessor architecture. It comprises of 6 cores: 2 Denver2 4 Cortex-A57. Denver2 core is designed for single thread performance, while Cortex-A57 for multithreaded. One can use both, but with thread binding, so threads are executed on the cores they started on. Limiting to one type of core might be beneficial when power consumption is a factor. Remember that thread binding might bind your application to core you did not want to use. Core 0 is Cortex-A57, core 1 and 2: Denver2, and cores 3-5: Cortex-A57. Core 0 is always active.
|Previous: Project Configuration||Next: Technical Issues|