Summary

In this post, I’ll review at the last 2 years of VRTX Systems and talk briefly about the challenges/opportunities that led me to sidelining it.

VRTX Systems; the pitch.

So a little background; a little over two years ago I left a good job and a great team @ Arkeus to set out on my own. There were a few motivating factors; the desire to work for myself, and recognition of some significant gaps in the market when it came to building distributed robot systems. In particular, there was (and continues to be) significant hype around drone swarms and autonomous robot collaboration despite there being at least one significant engineering barrier that is yet to be overcome, at least in the open/civilian market – relative drone positioning & communication.

I was/am mostly excited about using distributed robot collaboration on heavy lift copters – for places where you want a crane, but can’t get one there – coastlines, shipping, mine sites, search-and-rescue and (in the defence setting) contested logisitics. Key feature being that the environment does not have reliable infrastructure, making having portable heavy lift a benefit. By doing this with drones, you might not be as cost-effective as a hiring a helicopter, but you’ll have a smaller per-unit cost, and if swarming technology is good enough, then the ability to scale to fit the problem. All of this assumes that each drone in the fleet knows the relative position of their neighbors.

GPS is by far the most common drone positioning tool, is passive and easily scalable, but vulnerable to spoofing/jamming, and only provides a location for the robot with the GPS receiver – you need a communication network as well. To get drone-to-drone position estimates, you would measure your GPS location, and broadcast that to the network.

Most of the current communication technologies are not designed for distributed operation – both WiFi & Cellular usually require a centralised node. Those that do (e.g. BATMAN) are set up to mimic the existing BSD network stack enforcing a layered approach, which makes less sense in a network of highly mobile communicators. In traditional networking, we decouple the network address from the physical location, for networks of mobile agents, we want the exact opposite.

VRTX Systems first product (VRTX RDIO) was indented to solve these problems by providing an encrypted mesh communication network with relative positioning for drones; meaning low power, hard-realtime, secure, resilient to interference and scalable. The key to solving this problems was to implement a secure decentralised network clock so that network nodes could measure time-of-arrival of packets to estimate distance.

Over the course of VRTX Systems, I got to the point where i had

1. a mostly working software stack on the embedded radio base on a STM32 LoRa development board & DecaWave unit),
2. broadcast-based communication over LoRa,
3. a distributed secure handshake & AES encryption scheme that could handle nodes joining and leaving,
4. Partial Network clock synchronisation.

I had hit a bit of a wall around November 2024, the key problem was that the network sync algorithm required either a coarse clock to separate the synchronisation into rounds (not scalable), or the development of a fully asynchronous version. The first case was an engineering problem, which would take time to solve (and probably a new board, since i was outgrowing the memory capacity of the STM32L0 chip). The second case required actual research; for me to take off my engineer hat, and put on my mathematician hat. The first cost time & money, the second cost time & risk.

The obvious decision was to implement the coarse clock sync, it was more important to move closer to a product than to “get it right”, but it was a little disheartening nonetheless. Fortunately, around this time I had a opportunity to work with my friends at Arkeus again, which gave me some breathing room, a team environment, and some new experiences.

Learnings

Embedded software is hard.

I knew this going in, but i keep getting reminded of it every time. Embedded software development is a different beast. In most application development, you expect that your vendored code is either a binary blob with header files, or source code at works, or a library provided by your OS or development envirnomnet at best.
This is a lot less standardisation in embedded development. That radio you’re using? Someone from ST has put together a demo application but it’s a demo – heaps of features listed on the device datasheet are missing and there is a lot of drudge-work to get the stuff you want implemented in the way that you want it.

There is also a whole lot of churn. I settled on the Arm M-bed 2.0 ecosystem initially since it seem to have the friendliest development experience, only to have Arm pull the plug on officially supporting it 2-3 months later.

The biggest win was getting familiar with embedded rust, particularly the RTIC and embassy-rs libraries. The next bare-metal project I work on will most likely use one of these. I definitely feel that with a few more tweaks embedded rust will be the best embedded development environment by far.

Don’t underestimate low TRL risk.

Technology Readiness Level (TRL) is a common way to measure how mature a particular technology is. Generally speaking, academic publications are between TRL 1 and TRL 3, while things you can buy on the shelf of your favourite tech store are TRL 9+.
Generally speaking, my personal “sweet spot” is to pick things at low TRL (say 2-3) – academic publications, prototypes etc. – an drag them up to TRL6-ish – i.e. a working system with almost no design/implementation risk left, but still heaps of risk around deployment & sustainment. This gap (TRL-4 to TRL-6) is the so-called “valley of death” because it is here where many technologies fail on their way to commercialisation.

There are many reasons why this happens, but the one I want to focus on is “assumption propagation”. When you bundle a bunch of technologies together making then co-interacting, the operating requirements of one technology puts operating constraints upon another. These interactions cascade out in a way that can be pretty unpredictable. Best case, you can handle it. Worst case, it just straight up won’t work and you need to go back to the drawing board.

The best way around this is to build the smallest, dumbest, dirtiest, “complete system” prototype, but to build it in a way that makes iteration, learning & discovery the objective.

My mistake with VRTX RDIO was that I focused on the engineering risk, and iterated on the embedded software, before appropriately de-risking the clock sync. At the end of the day though, I think it was a damned-if-you-do-damned-if-you-don’t, since there was a whole bunch of risks associated with the radio board development that I had to work through.

The solo founder experience is not for me.

I’m very familiar with working solo for prolonged periods of time – a PhD. in maths will do that – but the solo founder experience is a different beast. When you do a PhD., you focus deep on one topic with the help of a supervisor, the camaraderie of your fellow candidates, and ideally feedback from your school/wider community.

As a solo founder, you’re frequency context switching to solve whatever the most immediate problem is (software, firmware, electronics, design and business), with no established community (you have to take time out of work to do that) and no real feedback unless you’re open-sourcing (different business model) or you are at the point where you have customers/clients. This might work well for some people, but it doesn’t for me. I think it would be fine if i were not “on a timer” (i.e. when the allocated savings run out), but as it was I struggled to stay positive about getting VRTX sustainable quickly enough.

Doing some freelance work really highlighted for me how much being part of a team means to me, and how much more effectively I work when I know what I contribution is part of a larger cause.

The future of VRTX Systems

For now, VRTX Systems is on ice while I focus on other things.
Details are for another time, but I’ve founded a company – Pneumatica.Bio – with some friends/colleagues from my days in the Systems Biology Lab.
You’ll be hearing more about Pneumatica very soon as we have a pretty massive 2026 coming up.

Thanks for reading.