First Mission (template)

When creating a mission thanks to the airsdk-cli tool, a directory called <my_first_mission> is created. Whether it is a service-only (resp. full) mission, you have access to the services (resp. fsup and guidance) folders.

Services folder

Template service code peeling

Creating an Air SDK service is explained below for the C++ language, but the process is identical to C and Python languages.

In the <my_first_mission>/services/<my_service> folder, you find a main.cpp file. It enables to run <my_service> endlessly as soon as the mission is loaded on the drone. This folder is where you may add your own service files (.cpp and .hpp).

A service is a loop and is not supposed to end. If a service exits (by a crash or another way), it will be restarted a few times. If the crash persists, the broken service will drop forever and ever.

The main.cpp file is a standard main file, with the appropriate includes at its beginning:

/**
Copyright (C) 2023 my_company
*/
#include <csignal>
#include <unistd.h>

The log macro is then defined:

#define ULOG_TAG my_service
#include <ulog.h>
ULOG_DECLARE_TAG(ULOG_TAG);

The ULOG_TAG named my_service declares the <my_service> logs system.

Note

To log information, you may use the ULOGI macro. I stands for information, and details the level of data you want to log. See the log related documentation for additional information about the log system.

To properly stop the service, a global variable and a signal handler are required:

sig_atomic_t run = 1;

extern "C" void sig_handler(int sig)
{
    run = 0;
}

The main starts with initialization when the mission is loaded:

int main(int argc, char *argv[])
{
    /* Initialisation code
    *
    * The service is automatically started by the drone when the mission is
    * loaded.
    */
    ULOGI("Hello from my_service");
    signal(SIGTERM, sig_handler);

    // [...]

Then comes the loop code, that runs the service until a SIGTERM signal stops it:

// [...]

/* Loop code
*
* The service is assumed to run an infinite loop, and termination
* requests are handled via a SIGTERM signal.
* If your serivce exists before this SIGTERM is sent, it will be
* considered as a crash, and the system will relaunch the service.
* If this happens too many times, the system will no longer start the
* service.
*/
while(run) {
    ULOGI("Running ...");
    sleep(1);
}

// [...]

When the service is over, there is some cleanup to do (ressources allocation, streams, files closing, data coherency check, …):

    // [...]

    /* Cleanup code
    *
    * When stopped by a SIGTERM, a service can use a short amount of time
    * for cleanup (typically closing opened files and ensuring that the
    * written data is coherent).
    */
    ULOGI("Cleaning up from my_service");
    return 0;
}

From theory to practice, let’s try this mere service on a real drone.

Practical exercise of a ‘Running’ printing service

Note

For Anafi Ai, you have to first switch on your drone, connect to it over Wi Fi

From <my_first_mission> directory:

$ airsdk build
$ airsdk install --default

Let the drone reboot to complete the installation process (the gimbal calibrates itself and all the four motors beep).

Once done, check you are reconnected to the drone correctly, and display the logs of the drone. You are supposed to see the logs the service is printing endlessly:

# make sure the drone responds
$ ping 192.168.42.1

>>> PING 192.168.42.1 (192.168.42.1) 56(84) bytes of data.
    64 octets de 192.168.42.1 : icmp_seq=1 ttl=64 temps=9.49 ms
    64 octets de 192.168.42.1 : icmp_seq=2 ttl=64 temps=10.5 ms
    64 octets de 192.168.42.1 : icmp_seq=3 ttl=64 temps=16.2 ms
    ^C
    --- statistiques ping 192.168.42.1 ---
    3 paquets transmis, 3 reçus, 0 % paquets perdus, temps 2003 ms
    rtt min/moy/max/mdev = 9,490/12,068/16,226/2,968 ms

# connect to the drone
$ adb connect 192.168.42.1:9050

>>> * daemon not running; starting now at tcp:5037
    * daemon started successfully
    connected to 192.168.42.1:9050

# launch the drone shell
$ adb shell

# display the logs
>>> autopilot@anafi2:/ $ ulogcat -b autopilot | grep <my_service>

You are supposed to see one Running ... every second.

You are now all set up to insert any service of your own, test it and have fun!

Note

Before reading those logs, make sure you have followed the steps of the developer settings section :

Fsup and guidance folders

Those are used to customize the autopilot state machine and add guidance modes of your own, which are both hard work. We strongly recommend you read carefully the guidance and flight supervisor documentation before digging into those folders.

The service process is way sufficient to do basic stuff on your drone, such as your own processes, basic moves, video recording, data logging, computing, … Have a look at other examples for more inspiration.