Вже становиться цікавіше. Вийшло зрізати ще 50мс затримки на відео. Тобто по 4G тепер стабільно 150мс, в локальній мережі 120мс.
Все ще використовуючи WebRTC, але не через програвання потоку у video елементі, а ручним декодуванням h264 пакетів.
Як виявилось, браузер може буферизувати декілька кадрів у video елементі, для стабільної картинки. Але за допомогою Web Codecs API та WebRTC Encoded Transform можна вклинитись у стрім, перенаправляти пакети в нативний h264 декодер і рендерити кожен кадр в канвас, як webgl текстуру. Ну і робити це з воркеру, щоб мейн тред не перетинався з декодінгом.
Додатково можна обійти vsync браузеру і рендерити кадри одразу як вони залітають на клієнт.
Також зі сторони raspberry pi виявилось що mediamtx має захардкожений буфер у три кадри. Прийшлось перезібрати собі кастомну версію, зі своїми налаштуваннями.
Тут все ще залишається можлива буферизація в самій імплементації WebRTC у браузері, і з цим вже нічого не зробиш.
Більше технічних деталей у відео. Про інтеграцію магнітного датчику, компасу та акселерометру. Створення системи traction control, стабільного спідометру, компасу та одометру через sensor fusion.
Я радів шо затримка на відео всього 50мс, але потім зрозумів що одне тільки зняття картинки з сенсору може зайняти стільки часу на такій простенькій камері.
Тому зробив те, шо називаєтьс glass to glass latency test. Коли знімаєш на камеру таймер і потім порівнюєш реальний час з тим шо в кадрі.
Перший тест показав 350мс через 4G. Зменшив буферизацію і підкрутив пару налаштувань, і вийшло 200-250мс (150-200 в локальній мережі, тобто інтернет додає лише 50мс затримки).
Буферизація це один з latency killers у відео стрімінгу, вони є як на стороні передавача, так і на клієнті. У fpv системах не так важливо уникати фпс дроп, як бачити актуальну картинку якомога швидше. Бо від очей залежить керування, у якого теж є затримка.
В системах які передають відео напряму, по радіо, цілком можливо отримати 30-50мс glass to glass.
PS Десь я читав як айтівець у війську пробував автоматизувати табличку, але нічого з того не вийшло, бо кожен як хотів так і тикав ту нещасну табличку)
Затримка на керування 50-60мс через 4G модем. Це добре шо на тому місці хороший зв'язок.
Проклав трассу, повісив на машинку GPS і замепив координати. Тепер є карта траси з позицією та швидкістю в реальному часі. З часом хочу поставити тахометр щоб вимірювати пройдену дистанцію.
Трохи переробив по залізу, щоб менше їло батку і керування давало менше шуму. Додав «турбо» режим щоб за потреби газанути через перешкоду.
Також додав рестрімінг відео на YouTube.
Так шо ми все ближче до проведення чемпіонату з раллі)
Переніс керування з веб сокета (і релея на cloudflare) на WebRTC Data Channel.
Команди керування з браузеру приходять на raspberry на машині, звідти по UDP на esp32 і далі на пульт.
Це сильно зрізало пінг, бо релей + websocket давали оверхед.
Тепер на 4g маю пінг на керування у ~200мс, що дає можливість їхати спокійно, не зупиняючись.
Якщо браузер у одній мережі з машиною, то пінг взагалі 2-4мс бо по WebRTC вони комунікують напряму в межах локальної мережі.
Але все одно пакети можуть приходити з затримкою, тому щоб не було запинок, додав згладжування керування експоненційним згладжуванням та обмежувач швидкості зміни сигналу щоб не було стрибків. І фейл сейф щоб машина їхала навіть коли розрив між пакетами більший ніж очікується, але коли значно більший по часу, то переключається на нейтралку.
Також допомогло рознести задачі між ядрами esp: зчитування udp сокету на одному ядрі, цикл керування на іншому.
