Juan Albanell is the head of system test engineering at Zipline, the autonomous drone delivery company. Prior to leading the system test team, Albanell worked in hardware testing and embedded flight systems during his 5 years at Zipline. Albanell holds a BSE in Electrical Engineering from Princeton University.
Q: What does your role leading system test engineering for Zipline look like? What is the team’s approach to testing and prototyping?
A: We’re basically the last gate before anything gets released into the field from a customer perspective. The way we do that is by designing validation test campaigns to make sure we can scale up and make sure every vehicle that comes out is high quality. A lot of the scenario definition and the way that we plan testing campaigns is very informed by past data. When we do FMEA [Failure Mode and Effects Analysis] we basically determine things that could happen in-flight we believe might have specific ‘corner cases’ for the sensor set, for example. And then we spin up software mockups that allow us to easily test different modules of the software with flight simulations. The software that is flying in-the-loop cannot tell that it is not actually flying.
Q: How has Zipline leveraged autonomy in its platforms to date?
A: Zipline has been operating its Platform One for quite some time. And that has always been an autonomous system, since day one. It’s able to navigate from our distribution centers all the way to where it needs to go, to deliver the package that it has, without needing any user input on a specific pathway.
Q: Are there new developments in autonomy at Zipline?
A: Platform 2, what we’re working on now, takes it a step further. It’s a two-part system. The Zip [drone] and the droid. [The droid] is coming down [from the Zip] and unlike an inactive or passive package, it can very accurately position itself to wherever the customer wants the package to be delivered. It’s using IMU, GNSS and we have a perception system as well, so the [droid] can safely steer clear of any obstacles and do so in a reliable manner.
Q: What are some of your takeaways from leading testing and prototying activities at Zipline?
A: The diversity of your [test] scenarios is so important. The scenario suite is pretty extensive. The biggest thing we’ve learned is to make your scenario builder as flexible as possible so you and other people can easily add things in the future.
Q: What proportion of time is spent on system test activities in relation to overall platform development efforts?
A: About half the time we spend is developing new things and developing our software, developing the hardware. Then the other half is testing. More than half of the time, sometimes, is spent on the test development. Because you can have something that nominally works, but nominal is not what hardware interfaces with, right? The real world is not nominal. It is going to rain, it is going to be windier than you expect, a bird will fly by, there will be other aircraft in the field that you didn’t expect. So, I think that’s where the challenge comes in and that’s why I think Zipline has always been a very test heavy company.
