This is the Java frontend implementation to MAVSDK.
It is organized as follows:
- The examples directory contains Java and Android examples using the sdk.
- The sdk directory contains the actual SDK.
- The mavsdk_server directory contains the Android library exposing
mavsdk_server.
The fastest way to start is to follow the instructions in the README of the java-client example. For Android, the android-client is the next step.
Please note MavsdkServer currently is not compatible for running on x86 and x86_64 Android images. If you would like to develop using MavsdkServer, you will need to deploy and develop using an ARM-based product or emulator.
MAVSDK-Java is distributed through MavenCentral, meaning that it can be imported using gradle with:
dependencies {
...
implementation 'io.mavsdk:mavsdk:2.1.0'
...
}
For Android, mavsdk_server is distributed as an Android library (aar):
dependencies {
...
implementation 'io.mavsdk:mavsdk:2.1.0'
implementation 'io.mavsdk:mavsdk-server:2.1.0'
...
}
ProGuard users may need to add the following rule:
-keep class io.mavsdk.** { *; }
-
MAVSDK-Java's plugins initialize on a background thread (mavsdk-event-queue). The initializations happen in a thread-safe manner and the library handles the correct order itself. This is done to provide a simple API to the users. -
For Android, run the
mavsdk_serveras follows:
MavsdkServer server = new MavsdkServer();
MavsdkEventQueue.executor().execute(() -> server.run(SYSTEM_ADDRESS, MAVSDK_SERVER_PORT));This makes sure that the calling thread (which may be the UI thread) is not blocked as the mavsdk_server discovers a system. This should ideally be done before the user creates the io.mavsdk.System so that MavsdkServer.run() is the first command to run in the mavsdk-event-queue.
To stop the server:
MavsdkEventQueue.executor().execute(() -> server.stop());- Users should avoid using the plugins directly by accessing them only through
io.mavsdk.Systemobjects.
The plugins are constructed and initialized lazily upon their first call through System, therefore the users do not bear any runtime overhead for the plugins that they won't be using.
-
Data streams start flowing in the background once the system is discovered by the
mavsdk_server, so they are safe to subscribe to immediately after the creation of aSystemobject. Streams that are not accessed won't start flowing. -
One-shot calls like
takeoffandlandare not added to themavsdk-event-queuewhen the user subscribes to them. This is done to avoid their piling up while themavsdk_serverdiscovers a system. Instead, theonErrorcallback will be triggered after a 100ms delay indicating that no system was available for the command.
Java/Android coding style is ensured using CheckStyle with the Google style.
A checkstyle task is defined in the root build.gradle of each project and can be run as follows:
$ ./gradlew checkstyle
The build task depends on checkstyle, meaning that $ ./gradlew build runs the checks as well.
There exist a plugin for CheckStyle in JetBrains' IDEs.
- Install the plugin called "CheckStyle-IDEA" in IntelliJ / Android-Studio.
- Import the checkstyle configuration as a code style scheme in Settings > Editor > Code Style > Java > Manage... >
Import... by selecting "CheckStyle configuration" and then browsing to
config/checkstyle/checkstyle.xml. - In Settings > Other Settings > Checkstyle, change the "Scan Scope" to "Only Java sources (including tests)".
- Still in Settings > Other Settings > Checkstyle, add a new configuration file and browse to
config/checkstyle/checkstyle.xml.
In IntelliJ / Android-Studio's bottom task bar, you should see a "CheckStyle" tab. It will allow you to select your configuration with the "Rules" dropdown-list, and to run the analysis on your code.
Note that by default, the IDE will not run checkstyle when building the project (whereas $ ./gradlew build always does it).
In IntelliJ / Android-Studio, the IDE might force the order of the imports in a way that is not following the checkstyle rules. For some reason, this is not set when importing checkstyle.xml as a code style scheme. However, it can be manually updated in Settings > Code Style > Java > Import Layout.
Both sdk and mavsdk_server are released with Maven. Publishing can be done through a gradle task:
./gradlew uploadArchivesThis task requires a few secrets in gradle.properties:
signing.keyId=<keyId>
signing.password=<password>
signing.secretKeyRingFile=<ring_file>
ossrhUsername=<username>
ossrhPassword=<password>
Sometimes you just need to rebuild mavsdk_server or even libmavsdk_server.so a couple of times to directly debug a problem.
This can be achieved with the Gradle composite builds. This is already setup in the Android example project here (just uncomment the lines to build sdk and/or mavsdk_server from sources, as described in the Gradle documentation).
Then you can just build the example and it will in turn build mavsdk_server.
To replace the libmavsdk_server.so, you have to build it using dockcross and replace the file for the architecture that you're testing on. This is assuming you have MAVSDK-Java and MAVSDK side to side in the same directory:
cd ../MAVSDK
docker run --rm dockcross/android-arm64 > ./dockcross-android-arm64 && chmod +x ./dockcross-android-arm64
tools/generate_mavlink_headers.sh
./dockcross-android-arm64 cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_MAVSDK_SERVER=ON -DBUILD_SHARED_LIBS=OFF -Bbuild/android-arm64 -DMAVLINK_HEADERS="mavlink-headers/include" -H. -DCMAKE_INSTALL_PREFIX=build/android-arm64/install
./dockcross-android-arm64 cmake --build build/android-arm64 --target install && cp build/android-arm64/install/lib/libmavsdk_server.so ../mavsdk-android-test/mavsdk_server/src/main/prebuiltLibs/arm64-v8a/libmavsdk_server.so
Now build, install, run the Android app again.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent