Locally built MAVSDK not functional for PX4 SITL mavsdk tests

MAVSDK
1

Description

I am trying to use a locally built MAVSDK to execute mavsdk tests on PX4 SITL, the commands I have used are as follows:

MAVSDK Local Install

Following the doc : Building library from Source · MAVSDK Guide

cmake -DCMAKE_BUILD_TYPE=Release -Bbuild/default -H.
sudo cmake --build build/default --target install

Note: I omitted the -DCMAKE_INSTALL_PREFIX=install part on the first command to make sure it will be configured to be installed system-wide : /usr/local, which is a default CMake Behavior (I believe).

Note: I did the sudo command on the second command, to make sure it installs system wide

PX4 SITL build

Following the SITL tests.yaml worksflow : PX4-Autopilot/.github/workflows/sitl_tests.yml at 37fa4bccb638410734e077ef18c3c9c0ecd117c4 · PX4/PX4-Autopilot · GitHub

  1. Build mavsdk_tests target
    make px4_sitl_default gazebo mavsdk_tests
  2. Run mavsdk_test_runner.py file
    test/mavsdk_tests/mavsdk_test_runner.py --speed-factor 20 --abort-early --case "Follow target*" test/mavsdk_tests/configs/sitl.json --verbose

Result

image
image1542×821 190 KB

The MAVSDK doesn’t connect to the drone.

Question

I am quite sure that this issue arises from the MAVSDK install not being correct. I am wondering:

  1. Do I always have to do rm -rf build/default, if I have done the build configuration command
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install -Bbuild/default -H. beforehand?
  2. Any other reason why the MAVSDK would not be working properly?

Posting on Discuss forum for history prevention, instead of posting on PX4 Slack (where after 10,000 messages the history gets deleted)

2

At the end of the cmake --build <...> --target install run, it tells you where it installs MAVSDK. You can see there if your install prefix was used or not. Another way is to check in build/default/CMakeCache and check the value of CMAKE_INSTALL_PREFIX.

2 Likes
3

Thanks! So that means, as long as I set the install path command (the last command) to /usr/local, the configure step’s DCMAKE_INSTALL_PREFIX (first command) doesnt come into effect?

For example,

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX install -Bbuild/default -H.
sudo cmake --build build/default --target /usr/local

Would install the MAVSDK to /usr/local?

4

The question is which library the PX4 tests really use. Could be that you also have a mavsdk library installed in /usr/lib?

To find out you can use ldd:

ldd build/px4_sitl_default/mavsdk_tests/mavsdk_tests 
	linux-vdso.so.1 (0x00007ffe99fd0000)
	libmavsdk.so.1 => /usr/local/lib/libmavsdk.so.1 (0x00007f95cfa01000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f95cf9b3000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f95cf7e6000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f95cf6a2000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f95cf688000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f95cf4c3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f95d03cc000)

This being said, I’m not convinced the timeout issue comes from the wrong library but it’s probably just a regression in MAVSDK due to my recent refactoring. I’ll try to run the tests with latest main on my side to check that.

1 Like
5 
ldd build/px4_sitl_default/mavsdk_tests/mavsdk_tests 
	linux-vdso.so.1 (0x00007ffc2bb1e000)
	libmavsdk.so.1 => /usr/local/lib/libmavsdk.so.1 (0x00007f80d5c4c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f80d5c03000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f80d5a21000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f80d58d2000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f80d58b7000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f80d56c5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f80d617f000)

It does inded show that libmavsdk being used is from /usr/local/lib, which is expected location for the local build. So yes would appreciate it if you could check if you also have this error!

1 Like
6

Note for myself

When building from a modified proto file: Writing Plugins · MAVSDK Guide

In the configure step:

cmake -DBUILD_MAVSDK_SERVER=ON -Bbuild/default -H.
tools/generate_from_protos.sh
tools/fix_style.sh .

So the command should be:

cmake -DBUILD_MAVSDK_SERVER=ON -DBUILD_SHARED_LIBS=ON -Bbuild/default -H.

7

Did you figure out what the problem was or should I try this next week?

8

Note to myself

Current MAVSDK Build command

rm -rf build/default

  • Remove previous build system

cmake -DBUILD_MAVSDK_SERVER=ON -DBUILD_SHARED_LIBS=ON -Bbuild/default -H.

  • Generate build system for the MAVSDK Server
  • Generate build system for the shared Libs as well (generate .so files)

cmake --build build/default -j8

  • Actually build the MAVSDK-Server.
  • This part is very important! As if you just execute the command below (--target <directory-to-install>), it doesn’t really build the MAVSDK-Server (as it seems)
sudo cmake --build build/default --target /usr/local
  • Build and the library in the /usr/local
9

Nope, the problem was solved!

I am quite sure that I forgot to do build the mavsdk_server with

cmake --build build/default -j8

before doing

sudo cmake --build build/default --target /usr/local

Which is a bit odd since I would expect the last command to also build the mavsdk_server :person_shrugging:

Do these two commands do different things?

10

Ok thanks for the follow up.

mavsdk_server is only built if the configure step has cmake -DBUILD_MAVSDK_SERVER=ON.

--target /usr/local is wrong, it should be either set at configure time

cmake -DCMAKE_INSTALL_PREFIX=/wherever/to/install

or used later like this which might have only been added to cmake in version 3.23.

cmake --install build --prefix=/wherever/to/install

Also see CMAKE_INSTALL_PREFIX — CMake 3.23.2 Documentation.

1 Like