Navigator C++ library

Blue Robotics Products Flight Controllers
1

Hello, I am trying to use the Blue Robotics Navigator FC on a raspberry pi4 with Ubuntu 22.04 server installed.

I am trying to integrate the FC library with ROS2 using C++. I have followed the README provided for the CMake setup with modifications, my cmake having:

set(LIBRARY_PATH "${CMAKE_CURRENT_SOURCE_DIR}/navigator_lib/aarch64-unknown-linux-gnu/libbluerobotics_navigator.so")

target_link_libraries(imu_publisher ${LIBRARY_PATH})
target_include_directories(imu_publisher PRIVATE 
  include
)


set_target_properties(imu_publisher PROPERTIES
  CXX_STANDARD 17
  CXX_STANDARD_REQUIRED ON
)

I have downloaded and put libbluerobotics_navigator.so from the repo release 0.0.6(release 0.1.1 didn’t have aarch64 .so)

The node runs find with root privileges but outputs a permission error:

[INFO] [launch]: All log files can be found below /home/utux/.ros/log/2025-10-16-14-35-00-796008-raspberrypi-2275
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [imu_publisher-1]: process started with pid [2276]
[imu_publisher-1] thread '<unnamed>' panicked at /cargo/registry/src/index.crates.io-6f17d22bba15001f/navigator-rs-0.4.0/src/lib.rs:316:14:
[imu_publisher-1] Error: Setting CS2 pin as output: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" })
[imu_publisher-1] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[imu_publisher-1] thread '<unnamed>' panicked at library/core/src/panicking.rs:221:5:
[imu_publisher-1] panic in a function that cannot unwind
[imu_publisher-1] stack backtrace:
[imu_publisher-1]    0:     0xffff8c43b524 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hcb29d7e9c4b8e461
[imu_publisher-1]    1:     0xffff8c45699c - core::fmt::write::h4ccbcab775f53daa
[imu_publisher-1]    2:     0xffff8c4397a4 - std::io::Write::write_fmt::h6451e7bdea117a16
[imu_publisher-1]    3:     0xffff8c43c620 - std::panicking::default_hook::{{closure}}::h7a4b717451889bc1
[imu_publisher-1]    4:     0xffff8c43c200 - std::panicking::default_hook::hb4ac08344b5f9f90
[imu_publisher-1]    5:     0xffff8c43cb80 - std::panicking::rust_panic_with_hook::hd187d6ce1c7e8c45
[imu_publisher-1]    6:     0xffff8c43ca18 - std::panicking::begin_panic_handler::{{closure}}::h43b171c1206b0bbf
[imu_publisher-1]    7:     0xffff8c43ba0c - std::sys::backtrace::__rust_end_short_backtrace::ha95864c5a524ffde
[imu_publisher-1]    8:     0xffff8c43c710 - rust_begin_unwind
[imu_publisher-1]    9:     0xffff8c416bac - core::panicking::panic_nounwind_fmt::ha1685a2ccdb67c65
[imu_publisher-1]   10:     0xffff8c416c24 - core::panicking::panic_nounwind::hbf5dd09d18ae8ace
[imu_publisher-1]   11:     0xffff8c416cc8 - core::panicking::panic_cannot_unwind::hbe2b8883afbca7ee
[imu_publisher-1]   12:     0xffff8c417a84 - init
[imu_publisher-1]   13:     0xaaaaae44ebec - _ZN12IMUPublisherC1Ev
[imu_publisher-1]   14:     0xaaaaae462abc - _ZN9__gnu_cxx13new_allocatorI12IMUPublisherE9constructIS1_JEEEvPT_DpOT0_
[imu_publisher-1]   15:     0xaaaaae4610d4 - _ZNSt16allocator_traitsISaI12IMUPublisherEE9constructIS0_JEEEvRS1_PT_DpOT0_
[imu_publisher-1]   16:     0xaaaaae45f3b0 - _ZNSt23_Sp_counted_ptr_inplaceI12IMUPublisherSaIS0_ELN9__gnu_cxx12_Lock_policyE2EEC2IJEEES1_DpOT_
[imu_publisher-1]   17:     0xaaaaae45cdac - _ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EEC1I12IMUPublisherSaIS4_EJEEERPT_St20_Sp_alloc_shared_tagIT0_EDpOT1_
[imu_publisher-1]   18:     0xaaaaae45a160 - _ZNSt12__shared_ptrI12IMUPublisherLN9__gnu_cxx12_Lock_policyE2EEC2ISaIS0_EJEEESt20_Sp_alloc_shared_tagIT_EDpOT0_
[imu_publisher-1]   19:     0xaaaaae456f70 - _ZNSt10shared_ptrI12IMUPublisherEC2ISaIS0_EJEEESt20_Sp_alloc_shared_tagIT_EDpOT0_
[imu_publisher-1]   20:     0xaaaaae454c04 - _ZSt15allocate_sharedI12IMUPublisherSaIS0_EJEESt10shared_ptrIT_ERKT0_DpOT1_
[imu_publisher-1]   21:     0xaaaaae451b90 - _ZSt11make_sharedI12IMUPublisherJEESt10shared_ptrIT_EDpOT0_
[imu_publisher-1]   22:     0xaaaaae449e24 - main
[imu_publisher-1]   23:     0xffff8bf47400 - <unknown>
[imu_publisher-1]   24:     0xffff8bf474d8 - __libc_start_main
[imu_publisher-1]   25:     0xaaaaae449cb0 - _start
[imu_publisher-1]   26:                0x0 - <unknown>
[imu_publisher-1] thread caused non-unwinding panic. aborting.
[ERROR] [imu_publisher-1]: process has died [pid 2276, exit code -6, cmd '/home/utux/code/sensor_test/install/uuv-imu_driver/lib/uuv-imu_driver/imu_publisher --ros-args -r __node:=imu_publisher -r __ns:=/utux/sensor --params-file /tmp/launch_params_5swjdex5'].

I can run it just fine with root permissions or just using the python library with the same code. Is this a known issue with the navigator library?

2

Hi @BerkY,

Can you provide your code available in a github repository or similar for us to check exactly what is the problem ?

1 Like
3

The “Permission denied” error (code 13) when setting the CS2 pin as output is a typical Linux security restriction, not a library issue, indicating your non-root user lacks permission to directly control the Raspberry Pi’s hardware (GPIO/SPI pins) required by the Blue Robotics Navigator library. Since it runs fine as root, the solution is to add your user (utux) to the necessary hardware access groups, most commonly the gpio group, by running sudo usermod -aG gpio utux and then logging out and back in to apply the new privileges.

4

image
These are my normal groups

image

and these are the default permissions for gpio interfacing as far as I understand. I can chmod and chgrp them to make their permission:

image

What I think the issue is:

If I were to create export a new gpio line manually echo 8 > /sys/class/gpio/export even though I have the export permission, the new gpio8 directory still needs root access to write or read value from.

image
image620Ă—102 4.33 KB

Is there a way to set a rule for gpio exporting to make them have another group permission like gpio? We have another user without admin and I don’t want to give it root access for both accounts to be able to use the library.

Also, interesting thing:
* if I have a pythın script that uses the library it needs sudo to run
* if the ROS2 nodes are written in C++ with the cpp library it needs sudo to run
* if the ROS2 nodes are written in Python with the python library it works without any issues
I don’t know why python nodes would work without issue like this when even a normal script doesn’t work