Skip to content

Software Development Kit (SDK)

The Avular SDK is a collection of tools and libraries that allow you to interact with the Vertex One. The SDK can be used to develop custom applications, integrate with existing systems, and interact with the Vertex One in real-time.

The SDK is designed to be easy to use and flexible, allowing you to develop applications in a variety of programming languages. The Vertex One runs a server which can be connected to using the SDK, allowing you to send and receive data in real-time. The SDK can be accessed using the C++ Client or the ROS 2 Client.

Installation

The user docker container is the default container that is running on the Vertex One. This container comes pre-installed with the SDK, allowing you to start developing applications right away. The SDK is also available as a standalone package, which can be installed on your local machine.

The SDK can be installed on a 'arm64' or 'amd64' architecture. The SDK is available as a Debian package, which can be downloaded and installed using the following commands:

amd64

wget https://avular.blob.core.windows.net/creos/creos-sdk-0.2.2-arm64.zip
unzip creos-sdk-0.2.2-arm64.zip
dpkg -i creos-*_*_arm64.deb

arm64

wget https://avular.blob.core.windows.net/creos/creos-sdk-0.2.2-amd64.zip
unzip creos-sdk-0.2.2-amd64.zip
dpkg -i creos-*_*_amd64.deb

Examples

To help you kickstart your development with the SDK and the Vertex One, Avular provides a comprehensive set of code examples available in the public Vertex code examples repository. This repository contains various sample codes that demonstrate how to interact with the Vertex One using the SDK.

For more information and to get started with the Vertex code examples, visit the Vertex ROS code examples repository.

Vertex One ROS code examples

Tip

Controlling the Vertex One using ROS 2 Humble requires a basic understanding of ROS 2 concepts and the ROS 2 Humble framework. If you are new to ROS 2, we recommend you to first familiarize yourself with ROS 2 concepts and the ROS 2 Humble framework before using the Vertex ROS code examples.

Warning

It is recommended to first learn how to operate the Vertex One using the remote control before using the Vertex ROS code examples. This will help you understand the basic functionalities of the Vertex One and how to interact with it using the remote control. Make sure you know how to take control of the Vertex One using the remote control incase of an emergency or unexpected behavior.

Documentation

The Full SDK documentation can be found.

CreOS SDK Documentation

Using the SDK with the Vertex One?

Vertex One implements the SDK, which is customized API. The Flight Controller can receive external commands from the Onboard Computing Module to trigger events. This page contains the behavior of the flight controller when receiving such commands, as well as details about the implementation.

There are two basic principles that are at the core of the implementation on Vertex One:

1. In all cases, the Flight Controller is responsible for deciding if a trigger is valid and accepted

2. The pilot can always take over manual control via the remote controller

Nominal Operation of Vertex One

During nominal operation, the following workflow is expected:

  1. The Vertex One is on the ground, LEDs indicate it is ready for a flight.
  2. The pilot pre-arms the Vertex by pressing the arming button on the drone.
  3. Pilot switches RC to manual position mode, LED indicators change.
  4. Pilot switches RC to external position mode, LED indicators change.
  5. The pilot arms Vertex via RC
  6. Onboard Computing Module sends takeoff command, Vertex climbs to the pre-defined take-off height and hovers in position
  7. Onboard Computing Module sends a state reference (e.g., a position or velocity), Flight Controller accepts and follows this reference. The position is continuously updated by the Onboard Computing Module to make the Vertex follow the trajectory.
  8. Mission is done, Vertex One stays hovering in place
  9. Onboard Computing Module sends land command, Vertex One descends and disarms when landing is detected.
  10. At any time the pilot can take over manual control via the remote controller
  11. At any time of the operation (but while in external position mode) the killswitch command can be used to turn the motors off. The pilot can always trigger the killswitch command by using the dedicated kill switch on the remote controller.
  12. At any time while the motors are armed, the emergency land command can be used to trigger an emergency landing which cannot be cancelled. Not even by the pilot via remote controller. Emergency landing will be executed in manual position mode, allowing pilot to control vertical descent velocity and horizontal position.

Specific Situations and Expected Behavior

Besides the workflow of nominal operations, different abnormal situations may occur. This table outlines the expected behavior of pre-programmed actions of the Flight Controller should these situations occur.

Situation Expected Behavior/Response
RC is in manual position/attitude mode All external Onboard Computing Module commands are ignored.
Pilot switches to automatic position mode, but is still in manual attitude mode Directly switching to automatic position mode may result in it being rejected. First verify that manual position mode is available before switching to automatic position mode.
Onboard Computing Module sends reference already during take-off Vertex One will continue take-off, last received reference will be followed after take-off is completed (Any XY references are ignored, different from manual position mode)
Onboard Computing Module sends take-off command during flight Flight Controller ignores command - no further action happens.
Onboard Computing Module sends land command while in take-off Vertex One will initiate landing procedure.
Onboard Computing Module sends changing waypoint/heading reference during landing mode All references are ignored during landing. Vertex holds last estimated position and heading and descends automatically. Changing reference requires aborting the landing (Any XY references are ignored, different from manual position mode).
No waypoint/heading references are received after take-off Vertex One will hover in place until references are received or other commands are given.
During any non-emergency state, the pilot switches from automatic position mode to manual position mode Vertex One hovers at last estimated position, any Onboard Computing Module commands are ignored.
Onboard Computing Module or Flight Controller triggers emergency landing Flight Controller changes MoO to manual position mode (if available) and ignores any Onboard Computing Module commands. Even if triggered by the Onboard Computing Module, emergency land can not be cancelled. Vertical velocity and position references from the RC are accepted as usual.
Pilot switches from automatic position mode to manual position mode while in flight. RC switch is however still in landing position. The Flight Controller only responds to the land/take-off command after exiting automatic position mode if the switch was equal to the current state. In practice: the pilot has to first switch to take-off mode before it can trigger land via the remote controller. This is to prevent unexpected landing behavior when switching from automatic position mode to a manual mode.
Remote control loss in automatic mode Flight Controller switches to manual position mode and goes into emergency land, no longer possible to go into automatic mode
Waypoint/heading references are flagged as incorrect before takeoff Vertex One hovers and holds position after takeoff