Перфекционизм - главный враг продуктивности

Завайрил контроллер задних моторов, сенсор напряжения, 2 step down регулятора, один для серво руля, другой для моторов и контроллера и запустил от батареи. Кажется ничего не задымилось, хороший знак.

Сегодня развел все провода и компоненты. Пришлось 5 раз его разобрать и собрать заного потому что каждый раз какая то новая херня возникала.

Из хорошего батарея вообще огонь. Во первых может пропускать ток когда подключена к зарядки и может заряжаться и питать робот одновременно.

Большой мэилстоун. Он может передвигаться и управляться удаленно.
- работает от батареи
- видео стримится в реалтайме в 720p@30
- задержки контроллера минимальные

Из проблем:
- руль очень нервный
- передаточное число редукторов слишком больше и робот очень медленный и шумный (bldc?)
- видео не сжато h264, я беру каждый кадр и сжимаю в jpeg из за чего перегоняться много гигабайт, что не будет работать в 4g
- углы руля очень маленькие, надо переделывать ступицу и линки

Сегодня поймал себя на мысли что столько классных идей которые хочется попробовать реализировать при этом уже куча технического долга который тоже бы по хорошему решить сейчас.

Как минимум хочется прямо сейчас закончить механику чтобы перейти к perception.

- переделать руль
- укрепить второй этаж (нарезать лазером акриловую пластину и пересобрать на новой площадке)
- поменять задние моторы или поднять немного оси и купить колеса побольше
- подрегулировать ускорение или распределить весь лучше (сейчас рэббит слегка подпрыгивает при резком ускорении)

Очередное разочарование, в NVIDIA Jetson Orin nano нет аппаратного сжатия h264.

Из за этого идея вытекают несколько других проблем. Изначально я думал сделать несколько узлов которые работают с камерой. Из за того что к камере может иметь доступ только один процесс я подумал о локальном стриминге через ZED SDK. То есть к камере коннектится один процесс и стримит пожатый h264 поток. Так же SDK позволяет и читать все другие параметры через стриминг словно используешь камеру локально. Но проблема в том что стриминг через SDK сильно завязан на аппаратное сжатие и без него крашится и не работает.

Теперь приходится схлопнуть все обратно в один узел который эксклюзивно имеет доступ к камере и делает все.

Не удержался и решил поиграться с points cloud и depth measurment. Пока попробовал самую легкую модель.

То что на экране снизу это еще не SLAM а просто stateless point cloud который с частотой 30hz паблишится из робота в nats и рисуется с помощью treejs в браузере. Чем дальше точка тем ближе она к зеленому. Это всего лишь для удобства но в кода это просто 3 или 4 мерная матрица (4 если хочется сохранить оригинальный цвет с камеры)

Из сложного оказалось что 1280x720 слишком тяжело и просто байтовый блоб этой матрицы весит 70+Mb. Прокачивать такой массив 30 раз в секунду невозможно из за ограничения в 64Mb на сообщение и ограничения канала. Уменьшив разрешения до 320p и сжав его zlib получилось получить пару сотен килобайт что выглядит ок. Плюс эта матрица sparse поэтому можно еще выкинуть нули из нее. Хотя может и нет смысла если все равно сжимать.

Из за того что baseline стереопары довольно широкий она может измерять глубину только от 30см. Что создает слепой участок перед роботом. Терпимо но не очень приятно. Возможно можно подумать в сторону лидара или или проксимити сенсора для obsticle avoidance.

У меня прям горит от того что NVIDIA выпилила аппаратный энкодер h264 из jetson хотя позиционирует его как edge ai device с двумя csi портами под камеры. Софтварным кодеком нагрузка на CPU на 1080p@30fps доходит до 40% и потребление ватт сильно взлетает.

Немного изучив топик сложилось ощущение что rapsberry pi 5 тоже лишился аппаратного энкодера из за шортэджа кристаллов, но rpi4 все еще имеет его. У меня кстати он есть и использовался в роботе пока я не переработал его на jetson. На том же разрешении и частоте кадров rpi4 потребляет на больше 5W и загрузка CPU не больше 5% переваривая поток без затыков.

Теперь появляются мысли о том, что разгрузить jetson перенеся все узлы для контроля механикой и стриминг камеры с jetson на rpi объединив их в кластер не такая уж и плохая идея. Кажется что дополнительные 5W погоду не сделают но освободят все ресурсы для Хуанга.

Возникает вопрос как объединить их вместе так как где то должен подниматься сервер NATS. Ethernet + мини свитч или ethernet over usb?

Решил по быстрому накидать блог на английском чтобы был. Буду туда дублировать все посты отсюда. https://xrabbit.dev

Давно ничего писал но это не означает что ничего не делал. Пока был в Byron Bay робота не было под рукой поэтому занимался генератором контента для блога.
- Все посты из телеги попадают в маркдаун файл, с метадатой на каждый пост.
- Переводится каждый пост через api ChatGPT
- Все картинки сжимаються в webp
- Для каждого видео генерится превью через ffmpeg и тоже сжимается в webp
- Хотел сделать без javascript вообще
- Деплоится в cloudflare.
- Source code тут https://github.com/seralexeev/xrabbit.dev

Все больше и больше использую NATS в проекте. Накидал простенький UI для управлением настройками камеры через UI. Для этого решил немного отойти от идеи использовать pub sub для всего и посмотреть в сторону jetstream. По дефолту NATS core не имеет персистентности но это можно включить включив jetstream. По сути это один флаг и у тебя появлятся персистентный KV стор, object store и некоторые гарантии доставки. Все это очень полезно и очень удобно использовать. Например настройки камеры это просто KV. И клиент и робот подписаны на этот ключ (все в jetstream это те же subjects) и могут реагировать на изменение, оба они могет так же менять значение и все клиенты мнговенно на них реагируют, а после перезагрузки состояние восстанавливается.

Spatial mapping + three.js

Собрал nvblox под jetson. Готового torch пакета нет поэтому пришлось собирать самому. Три раза падало по разным причинам в итоге включение свопа помогло, у jetson не хватает памяти чтобы собрать пакет. Сборка плюсов с cuda и питоном тоже боль, даже несмотря на докер контейнер в котором можно все собрать оно не гермитичное разваливается.

Дальше мучился с минимальным dockerfile. Я смог запустить тесты но докер образ огромный с кучей дев зависимостей которые я не понимаю поэтому хотел получить самый минимум рантайма, в итоге после нескольких дней чистки собрал компактный образ с бинарниками и питон биндингами.

Следующим шагом встроил в пайплайн зрения робота. Сначала думал писать в шареный файл карты глубин и гадры но NATS спокойно переваривает поток на низком разрешении. В итоге камера шлёт rgb + depth в топик а nvblox нода подписывается на них. Для высокого разрешения надо будет думать дальше, но пока хватает. Интринсики камеры и поза обновляет kv стор а не просто шлет сообщения в топики, это оказалось гораздо более удобно (хотя под капотом это одно и то же)

nvblox берёт глубину и положение и на gpu в реальном времени строит tsdf (поле расстояний до поверхности). Оно сглаживает шум объединяет много кадров и даёт карту со свободными и занятыми областями. Из этого можно получить воксельную карту прям как мир в minecraft.

Дальше на основе этой карты можно строить графы. Узлы это воксели с весами, зная cost можно использовать его для планирования маршрутов, объезжая дорогие участки, например чтобы робот не приближался сильно к стенам или не врезался в них. Дальше дейкстра или a* и робот может искать путь от своей позиции до цели использую pure pursuit.

Пока оно очень кривое и не точное, надо калибровать и фиксить баги. Но сам факт того что e2e пайплайн уже офигенно хотя столько боли и времени а продвинулся наверное только на 5% цели реализации локальной навигации.

Добрался до дифференциала. Реализовал и откалибровал. Теперь радиус разворота минимальный и колеса не проскальзывают при поворотах.