V-BAT 5.3 Autonomy Upgrades

A Quick History of the V-BAT and My Role

The V-BAT is a vertical takeoff and landing (VTOL) group 3 unmanned aerial vehicle (UAV), originally designed by Martin UAV (before Shield AI's acquisition in 2021). Its near-zero footprint, i.e. very little ground support equipment (GSE), makes it ideal for agile and expeditionary missions.

In late 2023, Shield AI decided to upgrade the V-BAT to Block 5.3 (here's the spec sheet and archived copy from the Shield AI site). I joined the Aircraft team in 2024 to help with Block 5.3 and to scale up the team. While we achieved a lot, I'm going to focus on four key outcomes for our customers:

1. Unassisted launch and landing
2. GNSS-denied operations
3. V-BAT Commander, our in-house command and control (C2) application
4. Next-generation avionics for robustness and Hivemind

Unassisted Launch & Land

Historically, the V-BAT required a human operator to assist it on launch and landing.

• Launch: the operator keeps the V-BAT vertically oriented until the engine spools up, giving it enough control authority.
• Landing: the operator keeps the V-BAT vertical while the engine is cut.

In both cases, the operator needs to prevent the V-BAT from tipping over. Unfortunately, this ultimately resulted in a US Navy sailor losing three fingers in early 2024.

Our goal was to improve safety, first and foremost by taking the human out of the loop and putting them on the loop. We also wanted to make launch and landing so simple and straightforward to reduce the cognitive overhead of launching and landing the V-BAT — the less cognitive overload, the more operators can focus on things that matter and reduce the chance of human mistakes.

For unassisted launch, the V-BAT integrated with a launch device that could hold the aircraft upright while the engine spooled up. While conceptually simple, this feature required a thorough design and test campaign to ensure the system was safe and trustworthy. This meant designing in health checks, clear diagnostic messages and alerts to the ground control station (GCS), layers of redundancy, and ultimately automatic aborts if preconditions weren't met. Taking into account launches in windy conditions, potentially from boats and having to avoid superstructures, was a challenging problem.

For autonomously landing the V-BAT 5.3, we cut the engine when close to the ground, onto landing legs that could absorb the impact. From an autonomy perspective, our core work included:

• Sensor integration and fusion for a relative pose
• Motion planning updates to handle landing on stationary and non-stationary targets (e.g. boats)
• GCS C2 upgrades

GNSS-Denied State Estimation

The legacy V-BAT platforms had demonstrated various GNSS-denied technologies. Even with early demonstrations, the value-add was clear, and customers were looking to use early versions of this capability wherever they could, even with the compromises of the prototype versions. With Block 5.3, we upgraded to make GNSS-denied operations native to the V-BAT, plus overhauled the state estimation architecture for increased robustness and performance.

Initially, our prototypes targeted fixed-wing flight to prove out the capability. While still challenging, it was ultimately more forgiving in comparison to the making this work for the vertical and transition flight modes. This required extensive testing across the system, including algorithmic testing via simulation and sensor playback; HIL testing; failure modes testing; etc.

However, what was arguably more challenging yet, was making the user experience and operating procedures simple and clear enough that it didn't differ significantly from standard operating procedures for the V-BAT under nominal conditions. This required optimising algorithms for operator workflows and updating our C2 application.

We deployed this capability to real-world operations in extremely contested environments. In particular, it's been instrumental in supporting Ukraine in its fight for freedom. I'm extremely proud of the work we achieved here.

V-BAT Commander

The V-BAT originally started as just the aircraft, with the GCS applications outsourced. Over time, small applications were insourced where the team had capacity or the need was clear. However, the core C2 application was still outsourced.

With Block 5.3, we finally officially released our full in-house C2 application, V-BAT Commander. This took extensive effort by the team to design, develop, test, and deploy, but it enabled us to fully own our outcomes. Not only could we own the user experience across all GCS applications now, but we were able to (a) iterate extremely quickly across both the GCS and aircraft (b) design unique features specific to the V-BAT, such as for the GNSS-denied work.

We also build an over-the-air (OTA) software update solution that let us monitor what was deployed on our internal aircraft and to make software updates when appropriate. This further cut down on long-lead time activities and areas of ambiguity in the fleet.

Next-generation Avionics for Robustness and Hivemind

The legacy V-BAT's avionics had started to plateau for both its reliability and for its performance, especially in terms of being able to support the latest Hivemind capabilities. Three main upgrades included:

1. Microcontroller upgrade to improve reliability and performance
2. Upgraded compute for Hivemind capabilities, such as state estimation, VIDAR, teaming
3. SATCOM for beyond-line-of-sight (BLOS) capability

The microcontroller and compute upgrades were instrumental for core V-BAT 5.3 capabilities mentioned earlier, but SATCOM deserves a short highlight of its own. BLOS capability was key for single-agent and multi-agent performance, as it extended flight and our communications range. It was quite the moment the first time we flew it at our test site from our Frisco HQ office (of course, with a GCS crew at our test site as a mitigation option).