Onboard Winch

Andi Lamprecht ·2026-05-11· 2 min read· Accepted

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

Decision

Onboard Ecosystem

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

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
  • Host an HTTP Server/Web App for observability and alternate control

• Virtual Winch: An Auterion App that pretends to be the Winch hardware

  • Used to test the Winch App in Virtual SkyNode
  • Hosts an HTTP Server/Web App to monitor and control
  • Playback failure scenarios

High Level Winch App Design

• MAVLink Adapter a module that connects to the MAVLink Router and know how to speak MAVLink

• HTTP Server a module that hosts the web app

  • Displays telemetry in real-time
  • Interface to issue 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.

• <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

N/A

Outcome

Testable Winch Control Software