Product: Anafi
Product version: [X.X.X]
SDK version: Latest in github
Use of libARController: [YES/NO] (Only for ARSDK)
SDK platform:Uni
Reproductible with the official app: [Not tried]
Hello all,
In my company we have a C++ application that we used to control Ardupilot. We checked the Anafi and it fits a lot of our new business cases so we are evaluating how to move into the Parrot ecosystem.
Our C++ has a lot of logic for connecting with other systems and we would like to keep it that way. To that end we are investigating if it is worth to get the olimpe python bindings into the C++ application, or to work directly with the arsdk-ng libraries. Maybe the community is aware of success stories in one way or the other?
To evaluate the option I would like to build the examples in the arsdk-ng. The problem is that I cannot find a way to build them, nor are the examples documented anywhere as far as i can see. Am i missing something? Could you point me in the right direction?
Also is it possible to build the arsdk-ng with a cross compiler?
First, arsdk-ng is a fairly low-level library, compared to what Olympe offers:
It is a ‘protocol’ library, not a controller one. So it will happily let you send commands in the wrong direction (some commands are meant for drone-to-controller communication only), or incompatible commands (only supported by older products).
It does not handle video at all (so you would also have to use libpdraw if you need to get the live video stream).
It requires a pomp_loop to run (and require all calls to be made on the loop thread), which means that you’ll need to use libpomp in your application, and do the inter-thread communication on your side.
But it is the basis of both Olympe and GroundSDK, so yeah, it should work!
The arsdk-ng examples (found in packages/common/arsdk-ng/examples/) are described to Alchemy (our build system) as the ‘arsdk-ng-controller’ and ‘arsdk-ng-devices’. For this example, I will use the PDrAW target, as it builds binaries for either Linux or macOS:
./build.sh -p pdraw-linux -A arsdk-ng-controller # or pdraw-macos
The sample can then be run with:
./out/pdraw-linux/staging/native-wrapper.sh arsdk-ng-controller
(more details about the build/run command lines are available in the PDrAW documentation)
Note that these examples are only meant to provide a really basic usage of the library, and are far from a fully functional controller code. We mostly use them as test benches when we change the internals of the library.
Yes, that’s actually what’s done when we’re building GroundSDK for Android and iOS. If you’re using one of those two platforms, you can directly use our build target, and use the alchemy-generated SDK (i.e. build your software with -I <SDK>/out/groundsdk-(android|ios)/sdk/usr/include -L <SDK>/out/groundsdk-(android|ios)/sdk/usr/lib)
If you have another target, you should create your own product (the configuration for alchemy). If your target is a linux machine, but with a specific cross compiler, you can probably copy the pdraw product (without its macOS part):
A great thanks for the thorough answer. In the mean time we got the sensation of what you explained more: The investment and effort of going from the basic library into something functional is just too big and unproductive at our scale. The cross-compilation information is useful though, and I will try to integrate it with Yocto and hopefully produce a recipe.
As a heads-up for the people that may read this thread and have the same desire to go native. We are thinking of integrating the Olympe with our application through an RPC interface. It seems feasible and saves us a lot of work, towards our product.
For OS X developers, be sure glfw3 (open gl development) is installed
brew install glfw3
And (while I have just started) I need to track down the source of this build error:
Undefined symbols for architecture x86_64:
"_arsdk_transport_mux_new", referenced from:
_arsdkctrl_backend_mux_start_device_conn in arsdkctrl_backend_mux.c.o
"_arsdk_transport_mux_get_parent", referenced from:
_backend_mux_channel_cb in arsdkctrl_backend_mux.c.o
_device_conn_destroy in arsdkctrl_backend_mux.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/shell/groundsdk/out/pdraw-macos/build/libarsdkctrl/libarsdkctrl.dylib] Error 1
I’m finding most of this covered in the pdraw docs @Nicolas referenced so perhaps I’ll get a clean build by the time I’m done.
The build error you encounter is not caused by Catalina, but by the alchemy configuration.
If you want the sample to properly build, you would need to enable it in the product configuration (./build.sh -p pdraw-macos -t menuconfig, then go in packages/common/arsdk-ng and enable the arsdk-ng-controller module). This will properly enable all dependencies (which is the issue here).