This entry adds some notes and brief comments about the autopilot interface blocks, the software bus, and the service layer in the context of our Open Source flight platform.

The autopilot interface blocks

Autopilot

The autopilot runs on the flight computer. It is responsible for critical flight computations. The interface with it is through a low-latency link and protocol known as MAVLink. More information on these components and how they relate to each other, can be found in this previous entry.

DroneKit

DroneKit is an open development kit. It offers a SDK and web API to implement applications for drones. The DroneKit project, API and examples were also covered in detail in this post.

Keep in mind that DroneKit, like the rest of the components that follow, runs on the companion computer. It leverages Pymavlink to handle the MAVLink protocol.

Vehicle library

Above DroneKit are the vehicle libraries. These libraries serve as a bridge between DroneKit's more generic vehicle model and real vehicles.

An example of this type of vehicle libraries is Plane. This type of vehicle library not only facilitates the management of UAV sensors and actuators, through DroneKit, but also manages specific flight modes, telemetry, missions, etc.

At first it may seem that a vehicle library is redundant code on top of DroneKit although in practice this layer adds mature and robust code with support for corner-cases/issues, precise configuration, adequate timing, etc.

In this line, also mention the implementation of the takeoff maneuver or the verification of the existence of a takeoff command within a mission.

Autopilot controller

The autopilot controller mediates between the software bus and the autopilot. To do this, create the appropriate object (plane, copter, etc.) through the vehicle library.

The autopilot controller monitors the C&C bus to interpret, execute and respond to the commands addressed to the autopilot.

Some examples of commands that it supports are the following:

{"COMMAND": "TAKE_OFF"}
{"COMMAND": "SET_ALTITUDE", "METERS": 50}
{"COMMAND": "SET_MISSION", ...}
...
{"COMMAND": "LAND"}

The autopilot controller is also aware of the flight phase of the vehicle, pre-flight / in-flight / post-flight, which allows it to have the proper context when handling the commands.

Although the vehicle library manages the telemetry, it is the autopilot controller that sends it on the appropriate bus with a certain frequency.

The autopilot controller can also implement other features such as command input buffering, mission caching, etc.

Software bus

The software bus implements a publish-subscribe pattern through the lightweight messaging library nanomsg-next-gen (nng) and Python bindings (pynng)

Service layer

We are interested in a functional architecture similar to the one used in ICAROUS (pg.2), which is similar in spirit to the USAL service-based architecture (pg. 8) proposed by Pastor et al.

The ICAROUS-2 architecture integrates different algorithms as distributed services that support different autonomous applications. These applications are organized in conflict monitors, conflict solvers, decision makers and mission-specific functions.

So each application is independent and communicates with the other applications through the software bus using a publish-subscribe pattern.

In this way, conflict monitors notify the decision making application to activate the resolvers in order to resolve one or more conflicts. The results of the applications are ignored while handling an imminent restriction violation. Only the mission resumes once all conflicts are resolved.

Take into account the notion of conflict is defined in the project as "a set of descriptors that convey meta level information about a conflict such as its severity, time to conflict violation, and point of no return".

A notional figure of ICAROUS understood from the perspective of Service Oriented Architecture is also included in the paper (pg.2)

The ICAROUS source code is available here.

Wrapping up

The interface and integration of the autopilot with the flight middleware is direct. The codebase and protocols (DroneKit, MAVLink, Pymavlink, etc) are open and mature.

As expected, the control logic resides fundamentally in the autopilot controller that interacts with DroneKit through the vehicle libraries.

While it is possible to avoid vehicle libraries, in practice they constitute a layer of abstraction that increases the reliability of the solution and can reduce the testing time and number of bugs/errors in the first real flights.

These vehicle libraries are also the natural place to include the implementation of well-known and tested maneuvers associated with specific vehicle models (plane, copter, etc.) such as a takeoff maneuver, evasion, landing, etc.

In the integration with the software bus, a sockets library was used together with a publish-subscribe pattern without specific support for the domain.

The implementation of the bus is good enough to reach a functional state of the prototype, although probably some type of library and protocol more oriented to IoT such as MQTT could have a better fit in relation to security, QoS, filtering, etc.

In relation to the service layer, a design based on a functional architecture similar to that of ICAROUS is interesting in order to have distributed applications / services cooperating and communicating through a software bus.

Two positive aspects to consider in this type of architecture, based on a publish-subscribe pattern, are the loose coupling and the scability of the service layer.

The architecture makes it easy to implement applications / services with different languages, as well as to test them in isolation.

Comments

comments powered by Disqus

Recent Entries