Ако следите трудното и продължително развитие на доставките с дронове в САЩ – забавяния, малки пилотни зони, приземени тестови флотилии и онова постоянно „скоро започваме“ от големите технологични компании – вероятно сте се запитвали дали изобщо някой успява да се справи с трудната част. Оказва се, че има такъв.
Zipline, базираният в Сан Франциско пионер в автономните доставки, тихо се е превърнал във „възрастния в стаята“. Докато други все още се опитват да докажат, че дроновете могат надеждно да доставят пакетче кафе, без да изплашат съседите, Zipline вече е провел една от най-големите авиационни тестови кампании в историята, за да подготви своя дрон P2 за реални клиенти.
А сега компанията дава на обществото рядък поглед отвътре към това как точно извлича поуки от полетни инциденти – много преди тези инциденти въобще да стигнат до нечий заден двор.
В нова публикация в блога на Zipline, Ерик Уотсън, ръководител на системното и инженерното звено за безопасност, разкрива, че преди дроновете P2 да доставят дори един-единствен артикул на реален дом, те вече са изпълнили десетки милиони симулирани мисии и повече от 150 000 физически тестови полета в различни точки на САЩ.
За сравнение? Това са 15 пъти повече полети от тези, които изтребителят F-35 е натрупал преди да влезе на въоръжение. И за разлика от други потребителски програми за дронове, които сякаш са вечно в „бета“ режим, Zipline вече доставя истинска храна, истински медикаменти и истински стоки на истински семейства.
И не са спрели дотук. Днес компанията отчита над 9 000 тестови полета седмично и подлага определени компоненти на дроновете на над 4 милиона цикъла на натоварване. Това е мащаб, с който малко авиационни компании – да не говорим за технологични фирми, които само „тестват“ авиация – могат да се сравнят.
Но дори с цялата тази подготовка, понякога нещо може да се обърка. А именно това, което Zipline прави след това, отличава сериозните оператори от компаниите, които гонят само заглавия.
На 24 март 2025 г. инженерите на Zipline тестват нова версия на софтуера за управление на полета на дрон, известен като Zip 290, на изпитателен полигон в САЩ. Като част от обичаен стрес тест, екипът умишлено прекъсва захранването към един от моторите по време на полет.
Обикновено – нищо особено. Zips са проектирани да компенсират незабавно. Вместо това Zip 290 започва да се държи… странно.
Дронът, който обикновено изпълнява над 500 проверки за безопасност всяка секунда, прави всичко възможно, за да се стабилизира, но възстановяването не работи. Останалите мотори се натоварват до максимум, само за да поддържат устройството във въздуха.
Zip-ът едва успява да се върне към зоната за скачване, но не може да изпълни последната маневра за издигане и скачване. Затова системата му за безопасност взема решение: да разположи парашута и да кацне безопасно върху защитната платформа отдолу. Няма повредено имущество. Няма драма. Няма ядосани съседи, публикуващи снимки онлайн с въпроса „Какво се разби в двора ми?“.
Всичко проработи точно както е проектирано. В рамките на секунди се случиха три неща:
Другите тестови полети бяха незабавно приземени. В рамките на минути инженерният екип на Zipline – разположен в няколко различни центъра – беше активиран с пълни пакети данни, снимки и логове. Тоест истинска авиационна реакция. Не „ами нещо се разби, да пратим имейл до централата“.
До 18:15 ч. инженерите на Zipline вече преглеждаха телеметрията на дрона. Отключването на мотора се бе случило точно по план, но след това дронът реагирал много по-различно в сравнение с хиляди предишни тестове.
Виновникът? Проблем в управлението. Комбинация между хардуера на дрона и новия софтуер предизвикала това, което инженерите наричат „недемпфирана осцилация“ – обратна връзка, при която микрокорекциите правят полета по-нестабилен, вместо да го стабилизират. Подобно на шофьор, който прекалено рязко коригира волана на заледен път.
Обикновено автономният софтуер на Zipline прави корекции на всеки 20 милисекунди – пет пъти по-бързо, отколкото можете да мигнете. Но в този случай тези корекции били лошо синхронизирани с конкретния сценарий. Екипът вече имал ясната следа към проблема.
Оттук нататък идва впечатляващата част. Отстраняването на осцилации е печално известно като изключително трудно, особено при апарат толкова напреднал като P2. Екипът на Zipline е трябвало да:
Решението? Контраинтуитивно, но ефективно: да се забавят определени микрокорекции от всеки 20 ms до всеки 200 ms. По-малко „нервни движения“, повече стабилност.
До 11:00 ч. на следващия ден – само 17 часа след инцидента – новият код беше готов за масово тестване.
До 18:18 ч. – по-малко от 24 часа след разгръщането на парашута на Zip 290 – дронът изпълни същия тестов сценарий, но вече с обновения софтуер. Този път премина безупречно.
Два дни по-късно, след повече от 1 000 реални валидационни полета, актуализацията беше въведена в търговската кодова база на Zipline. Проблемът не се е появявал оттогава.
Прозрачността, която Zipline демонстрира, не е просто PR украса. Тя подчертава какво всъщност изисква една зряла, напълно тествана система за дронове: култура на безопасност, изградена върху авиационни стандарти, инженерна реакция в реално време, симулации в огромен мащаб, способност да се изпълняват хиляди реални полети за дни, както и хардуер, софтуер и операции, разработени изцяло вътрешно. Посланието на Zipline е ясно: ако искаме хиляди автономни летателни апарати да прелитат над американските домове, това е нивото на прецизност, което е необходимо.
