Onboard In Mission Winch

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

In-Mission Winch

Context

One of the most important objectives Uncrew missions need to support is winch Dropoff (aka winch delivery). When this objective is present in the mission request, the UAV is expected to navigate to the delivery location, min-mission agl altitude above it and command the winch to WINCH_DELIVER.

The main problem with doing this is that WINCH_DELIVER is not supported as part of a PX4 mission definition. Therefore the mission needs to be broken down into segments either by:

• Breaking up the Uncrew mission into two PX4 missions and having the MAVLINKShim issue WINCH_DELIVER in between.
• Pausing the one PX4 mission, having the MAVLINKShim issue WINCH_DELIVER during that pause and then resume the mission.

These two options themselves have limited shelf life as Uncrew has clear plans of migrating away from flying PX4 missions and instead writing its own (Uncrew) Flight Controller.

Another problem lurking is the anticipated migration from the current REEL Winch to Sebastian Winch with yet unspecified interface.

Decision

We shall pause the one PX4 mission when above the drop-off point, issue WINCH_DELIVER and then resume. In order to prevent the drone from overshooting the target, we shall use the feature of PX4 mission item definition called autocontinue. A mission item that has autocontune set to false will automatically stop the UAV upon reaching the target and pause the mission.

The existence of Sebastian Winch suggests that MAVLINKShim should abstract away the method of communicating with the Winch in a suitable, asynchronous C++ abstraction ideally with the connection to MAVLINK independent from MAVLINKShim so that it can plausibly survive the demise of MAVLINKShim itself.Establishing that independent connection will be considerable amount of work, so it has to be weighted against other project priorities.

Alternatives Considered

Two PX4 Missions

We considered breaking the Uncrew mission into two PX4 missions, but that we believe have additional complexities:

• One PX4 mission means that PX4 will accept it in its entirety before the mission is commenced. Two PX4 missions removes that confidence. PX4 could refuse to fly the 2nd mission when far from home.
• Two submissions will force us to map indices of completed mission items from PX4 submissions to one Uncrew mission.

Service Abstracting Winch

We propose to abstract the Winch (REEL and Sebastian) at the software design level with a C++ interface. We instead could consider a deeper incision and have a service/process-based abstraction. That would be justified if more than one Uncrew service will want to speak to the winch. Today it’s only the MAVLINKShim that wants to both direct the winch and hear its telemetry. Tomorrow however the Flight Controller will want to direct it, but the Uncrew Monitoring Service will want to hear from it.
The sole reason we’re not writing a service-based winch abstraction it seems is that we haven’t got the time prior to EVO1.