В начале это выглядело как обычный интеграционный проект. У команды был большой четырёхколёсный робот-доставщик SpeedyBot стоимостью как новый автомобиль. Главной задачей было отвязать его от китайского облака: оставить штатные навигацию и железо, но перенести управление, данные и операторский интерфейс в собственную Fleet-систему. А затем научить робота самостоятельно ездить между точками в реальном парке и возвращаться на зарядку. SpeedyBot выпускает китайская Suzhou Alpha Robotics, также известная по экосистеме CSJBot. Производитель описывает семейство SpeedyBot как роботов для доставки внутри и снаружи зданий, с автономной навигацией, объездом препятствий и автоматической зарядкой. В аппаратной части экземпляра работали Linux на ARM64, ROS, SLAM, несколько камер и лидаров, Java SDK alpha-pro-sdk и отдельное приложение для картографирования alpha-pro-sdk-scan. На рекламной странице всё выглядело почти готовым продуктом, но на практике проект превратился в курс по робототехнике, сетям, реверс-инжинирингу и цифровой криминалистике. Китайская программная экосистема работала нестабильно и плохо соответствовала модели реального сервиса: производитель выдал один аккаунт дистрибьютора, а нормальной системы клиентских аккаунтов и разграничения доступа не было. API у облака существовал, но многие нужные операции через него либо отсутствовали, либо не давали построить надёжный Fleet-продукт. Поэтому команда решила заменить облачную часть: написать собственный backend и развернуть непосредственно на роботе свой Edge, который должен был общаться со штатными SDK и SLAM локально, а с Fleet-панелью через независимый канал.

Однако быстро выяснилось, что простого адаптера поверх опубликованного API недостаточно. Для карт, управления питанием, русской озвучки, устойчивой навигации и диагностики приходилось разбираться во внутренних сервисах робота гораздо глубже, чем предполагала документация производителя. Первой проблемой оказалась связь: российская SIM-карта регистрировалась в сети, модем видел оператора и хороший сигнал, но передачи данных не было. Заводская служба ожидала интерфейс wwan0, которого на этой аппаратной конфигурации не существовало. Одновременно маршрут по умолчанию указывал на собственный адрес робота, а DNS-запросы регулярно уходили в тайм-аут. Команда восстановила LTE через штатные NetworkManager и ModemManager, настроила APN, маршрутизацию и DNS, не ломая сервисную точку доступа, и робот наконец научился сам возвращаться в сеть после перезагрузки. Следом выяснилось, что его голосовая жизнь в основном проходит на английском, поэтому инженеры исследовали штатную систему аудиособытий, подготовили русские реплики и установили локализованный комплект, проверив 144 фактических пути к аудиофайлам.

Картографирование тоже не было полностью локальным. Вход мог отвечать формальным успехом без токена, сохранение карты зависело от облачного списка, а отдельный scan-сервис однажды застрял со старым служебным токеном. Временами казалось, что робот способен построить карту местности, но не способен доказать самому себе, что имеет право её сохранить. Главный сценарий проекта был уличным, а не гостиничным: клиент собирался запускать доставщика в парке, где маршруты проходят по дорожкам из мелкой каменной крошки и рядом с газонами. Именно эта поверхность показала слабое место штатной механики и навигации. SpeedyBot умеет эффектно разворачиваться почти как танк: в одном из таких манёвров он крутит одним ведущим колесом, а специальные задние колёса состоят из поперечных роликов. На твёрдом гладком полу это позволяет развернуть тяжёлый корпус почти на месте, но на траве, влажном грунте или сыпучей дорожке такой манёвр работает плохо: колесо прокручивается, ролики зарываются или скользят, а корпус остаётся почти на том же курсе.

Штатный planner усугублял проблему: он строил маршрут от точки к точке, не учитывая начальный угол корпуса при выборе траектории. Перед началом движения робот пытался сначала повернуться на месте в направление первого участка маршрута. Колёса уже сообщали вращение, поэтому planner видел ложный прогресс, хотя SLAM-поза почти не менялась. Нагрузка на привод доходила примерно до 19 ампер, после чего аппаратная защита отключала его и колёса разблокировались. При этом навигационная задача могла остаться в состоянии running. В результате робот просто стоял в случайном месте парка, не ехал, не завершал задание и больше не удерживал колёса. Для публичного пространства это недопустимо: дорогой аппарат можно было просто укатить руками. Это был важный урок: движение колёс и движение робота не одно и то же. Команда перестроила работу с маршрутами, исключила опасный стартовый разворот, добавила честную обработку отключения привода и добилась устойчивых поездок по маршруту. К демонстрации робот уже ездил между точками и возвращался на док без прежней постоянной пробуксовки.

Первый ключ лежал в SDK. Официальной документации для полноценного сервисного доступа не было, а ответы производителя становились всё более сдержанными по мере того, как вопросы становились конкретнее. Первый настоящий доступ нашли не перебором паролей: в текущем Java SDK оказался класс SshClientUtil, а в нём зашифрованные константы адреса, пользователя и пароля для SSH. Инженеры статически разобрали байткод, восстановили использованный алгоритм расшифровки и получили учётную запись nvidia. Вход с проверкой SSH host key сработал, после чего можно было спокойно работать с роботом: исправлять LTE, изучать ROS и штатный SDK, делать резервную копию накопителя и строить карты. Этот эпизод показывает, что даже при отсутствии официальной поддержки грамотный реверс-инжиниринг позволяет вернуть контроль над устройством без физического вмешательства.

Для российского рынка эта история имеет двойное значение. С одной стороны, она демонстрирует, что импортные робототехнические платформы можно адаптировать под локальные условия и интегрировать в собственные сервисы, несмотря на закрытость производителя. С другой стороны, она вскрывает риски: зависимость от китайского облака, отсутствие нормального разграничения доступа, слабая документация и потенциальная уязвимость через встроенные учётные данные. В условиях, когда всё больше компаний рассматривают автономную доставку как коммерческую услугу, такие проекты показывают, что готовность продукта к реальной эксплуатации требует глубокой технической экспертизы. Отрасль уже сталкивалась с похожими проблемами: роботы-курьеры на улицах городов нередко застревают, теряют связь или становятся объектом вандализма. Опыт команды может быть полезен другим интеграторам, которые планируют разворачивать подобные решения в парках, жилых комплексах и бизнес-центрах.

В перспективе остаётся ряд открытых вопросов. Насколько устойчиво робот будет работать на разных поверхностях и в разную погоду? Как поведёт себя система при потере связи с Fleet-панелью? Сможет ли команда обновлять прошивку и SDK без риска сломать штатные сервисы? Наконец, какова юридическая сторона использования восстановленных учётных данных и модификации устройства — этот аспект требует отдельного анализа. Пока же проект показал главное: даже дорогой и внешне готовый робот требует значительной доработки, а успешная интеграция возможна только при сочетании компетенций в робототехнике, сетях и реверс-инжиниринге. Дальнейшее развитие зависит от того, сможет ли команда масштабировать решение на парк роботов и предложить рынку готовый сервис, а не единичный эксперимент.