Skip to content
Droneup Winch App MAVLink Architecture

Droneup Winch App MAVLink Architecture

Andi Lamprecht Andi Lamprecht ·· 4 min read· Accepted
ADR-0122 · Author: Sybil Melton · Date: 2025-02-07 · Products: uncrew
Originally ADR-0111 DroneUp Winch App MAVLink Architecture (v4) · Source on Confluence ↗

Deciders: Micah Martin
Date: May 8, 2024
Ticket: UNCREW-2270

DroneUp Winch App MAVLink Architecture

Background

The DroneUp Winch App aims to control the DroneUp (Sebastian) Winch.
Constraints:

  • Integrate with current Uncrew architecture
  • Deploy in Auterion OS
  • Use MAVLink for communication
  • Accommodate ROS 2 for communication down the road

Decision

Onboard Ecosystem

First, let’s look at the high level view of how the Winch App fits into the Uncrew/Auterion ecosystem.

2ebed7ecdb553e90feb51a61e6f274b2-auterion-apps-mavlink.png

Existing Components:

  • SkyNode: Auterion computer hardware on the drone.
  • Docker: Auterion Apps include Docker images that run in a Docker Contain on the SkyNode.
  • MAVLink Shim: the drone-side component of Uncrew
  • Avatar: server-side component of Mercury
  • MAVLink Router: runs on the drone, routes all MAVLink messages
  • Winch: DroneUp Winch hardware/firmware

New Components:

  • Winch App: An Auterion App that will control the Winch.

    • It connects to the MAVLink Router for all on-drone communication.
    • Listens for high level Winch commands (sent by MAVLink Shim)
    • Issues low-level Winch commands to Winch hardware
  • Winch Avatar/Winch Control Plane: Cloud based service to interface with the Winch app.

    • The Winch App will connect to Control Plane at startup
    • “Avatar” is used for familiarity, but is a misnomer. Unlike the Shim Avatar which is 1-to-1, there is only one
      Winch Control Plane that all the Winch apps will connect to.
    • Telemetry will be set from the Winch App to Control Plane
    • Authorized Users may observe and command individual Winches
    • The communication protocol will be REST and/or gRPC.
  • Virtual Winch: An Auterion App that
    pretends to be the Winch hardware

    • Used to test the Winch App in Virtual SkyNode
    • May host an HTTP Server/Web or connect to a Control Plane to monitor and control
    • Playback failure scenarios

MAVLink vs ROS 2

MAVLink and ROS 2 are communication protocols between devices and programs. Here is a brief overview of their differences:

MAVLinkROS 2
CentralizedDecentralized
Pub/Sub and Point-to-PointPub/Sub (Servers, Actions)
Specific to dronesGeneral Purpose Robotics
Predefined, Standardize MessagesCustom Messages (Interfaces)

There is a desire for DroneUp to migrate from MAVLink to ROS 2. Here is the design using ROS 2.

0315da7d366c164a8522a9e7451fd5c5-auterion-apps-ros2.png

This is very similar to the MAVLink. Notable differences:

  • There is no MAVLink Router, nor any similarly centralized component
  • Devices communicated through topics (Decentralized)

High Level Winch App Design

5c9b0cfadad74972b25e0eaa879e5ccb-winch-simple.png

  • MAVLink/ROS2 Adapter a module that connects to the MAVLink Router or ROS 2

  • Avatar Client a module that connects to the Avatar/Control Plane

    • Sends telemetry in real-time
    • Accepts high-level winch commands
  • Statemachine A State Machine seems like to best way to model the hardware.

    • events consist of

      • High level winch commands
      • Winch telemetry
    • states model the activity of the actual hardware

Detailed Winch App Design

This is a best guess and the internal design of the software. It is subject to change as development progresses.

491f05b678ae13dfb439274ba5d20bd1-winch-detailed.png

  • <I>: Interface or Abstraction

  • Dependency Inversion Principle:

    • No module has a dependency on another concrete module. Everything depends on abstractions.
  • Open/Closed Principle

    • It may be possible to extend this app to work with ROS2 without changing any existing code.

      • ROS2WinchCommander
  • Testability

    • The decouple architecture allows for Mock implementations of the interfaces.
    • Mock make it possible to test each module in isolation

Drivers

We need winch control software. This design approach fits the constraints and allows for extensibility.

Considered Options

Hosted HTTP servers in the Auterion App.

There are many examples of Auterion apps that host an HTTP server. This is a convenient way for users to interact with the embedded app. However, experience within DroneUp has shows it to be an anti-pattern for the following reasons:

  • The HTTP server is not reachable except in test or…
  • Requires complicated network infrastructure
  • How do you authenticate users?
  • Consumes extra resources on the drone
  • Complicates code on the drone

Outcome

Testable Winch Control Software

Last updated on