Скажить а на отчественном МК ведь далеко не последняя версия INAV/Ardupilot запустилась наверняка? Все-таки они расчитанны на мощные МК на STM32 где много памяти и частота большая. Как далеко пришлось откатится назад, до какого релиза прошивки от нынешнего, часом не inav 1.1. что по сути клон multi wii?
У Tesla/CyberTrack например FSD автопилот по полям ездит и даже в пустыне работает, китайские пользователи благо его постоянно тестирую в суровых условиях и выкладывают видео его работы.
“С локализацией это не сработает, даже если взять целый готовый фреймворк, например, Autoware (открытый стек для автономного вождения на ROS), Apollo от Baidu или пакет robot_localization из ROS (который предназначен для слияния данных с одометрии и IMU).” - Может большество этих пакетов не доведены до ума намеренно? Почему ни один готовый пакет lio не отдаёт например движущиеся точки и не сигнализирует о попадании в дегенерационную сцену (например планарную) для лидара? Ведь разразработчики этих пакетов знают в своих бумагах пишут, что в случае её обнаружения нужно переходить на резервную навигационную систему или например реактивную систему управления? А пакеты лидарные внутри себя движущиеся точки по невязке находят и фильтруют в keyfram’ы их не добавляют что-бы не нарушать работу локализации но не отдают их? Такие “недоработки” наводят на мысль, что этот софт специально так сделан что-бы его можно-было проверить на тестовых данных датасетов, но не возможно на прямую использовать, этакий недостающий пазл отсуствует, который они могут при обращении к ним добавить. Такая вот сложилась система и всех это устраивает.
Но ладно у нас мэйкеров есть простые реактивные алгоритмы типо VHF и Потенциального поля не нуждающиеся в одометрии и следовательно работающие в планарных сценах, где лидар дегенерирует а в насыщеных геометрией сценах, работает оптимальное управление A*, mppi и т.д. Это логичный баланс ведь когда в поле 1-2 куста их можно обьехать просто слева/справа, вокруг пустота и потому самый лучший путь по прямой, что эти алгоритмы и делают, а как кустов станет больше то и одометрия сможет работать, сцена станет насыщена геометрией детекторы дегенерационной сцены запустят потоки одометрии лидарной например и алгоритмы оптимального управления.
А как у вас? Если вы говорите у вас свой надежный мультисенсор фьюжен конвейер, речь конечно об автономной навигации без GPS? Реактивные алгоритмы могут работать лишь на низкой скорости т.к. не осуществляют планирование (ведь они реактивны) и не позволяют использовать модель динамики (симуляцию) для того что-бы предсказывать силы действующие на машину в пути что-бы безопасно быстро перемещатся по открытому пространству. Сможите вы показать класс в следующей статье как выша одометрия надежная работает в поле, в геометрически деградированной сцене ориентируясь по текстурам подстилающей поверхности сопаставляя 2D текстуры от камеры либо по интенсивности лидаров как в пакетах coin-lio либо в IGICP, а может в поле будет работать одометрия от радара (не работал с радарами не знаю)? Вот это действительно будет уровень и покажет высокую надежность! Ведь сопоставлять в планарной сцене интенсивность и текстуры сложно, доступные opensource пакеты не только lio но даже vio и vslam в таких условиях не выдерживают и разваливаются не только потому-что матрица Гессе становится близкой к сингулярной, любое вращение вокруг вертикальной оси (Yaw) выглядит для лидара абсолютно одинаково, так как плоскость однородна, на плоскости нет вертикальных ориентиров (столбов, коробок), алгоритм оптимизации не может понять: сместился ли робот вперед (продольное движение) или он просто наклонил нос вниз (тангаж/Pitch), но и фундоментальная проблема, отсуствие избыточности данных в облоках точек что были в 3d. Эта избыточность позволяла значительно увеличить точность сопоставления облаков в кореляторе т.к. состыковать точно друг с другом 2 3д облака значительно легче чем 2 2д так сказать есть запас на компенсацию шумов и погрешностей. Что в долгосрочной перспективе приводит к более быстрому накоплению ошибки локализации без поправок от абсолютных датчиков типо GPS, создовая значительные ограничения на расстояния в автономной навигации подобно накоплению ошибки, что вы приводили в этой статье ИНС.
Очередная попытка импортозаместить все компоненты FPV, а какие это компоненты? Вот полётник, камера своя аналоговая хотя-бы, видео передатчик, радиомодуль типо lora свой для радио управления, по хорошему свои lcd экраны, РУ аппаратура и видео приёмник. Это минимальная база без которой критическая зависимость от импорта никуда не денется. А ещё нужно массовое произвоство всего этого возможно на следующем этапе. Вообще наблюдаю не одну попытку импортозаместить компоненты FPV и все они как правило заканчиваются на программирование какого-нибудь Российского МК, создании дизаина своей печатной платы а дальше не двигаются. Также в связи с блокировкам интернета и github странно, что вы использовали opensource прошивки и не делаете свои. Все-таки они хоббисткие там много лишнего и многие важные функции отсуствуют, однако, это наиболее простой и лёгкий путь перенести готовое ПО особенно в эпоху ИИ, что-бы продемонстрировать результат. При этом массовым уже становится применение дронов с ИИ и автозахватами/самонаведением (Bumblebee, Hornet), с весьма продвинутыми модулями защищеной связи на чипе и starlink.
Вам ROS надо осваивать и ставить 2D лидар он не дорогой в пределах 1к рублей, он даст вам лидарную карту и лидарный курс с которым вы мучаетесь, магнитный как вы сами заметили не работает а чистый гироскоп + акселерометр может дать только управление по угловой скорости, вот что у меня на видео про ручное управление. В таком случае его дрейф становится не важен. Если в будущем вы хотите что-бы llm или vlm, vla управляла вашим роботом ROS также вам пригодится что-бы ваш ИИ мог управлять роботом по точкам на карте или даже ИИ будет сразу вводить траекторию а робот по ней следовать. Тогда ИИ не придётся переучиваться управлять вашей тележкой и вообще скорость движения будет норм.
Ну в принципе многие контроллеры нормальные вполне исполнители, для многих задач и pid достаточно, что по сложнее mpc, это понятно и предсказуемо. GP-MPPI на гаусовых процессах вообще сам обучается online без нейросетей вносить поправки в вывод математической модели, динамики что-бы она лучше достигала цели, как например смещения из-за не верно посчитанного трения в модели или ставить подцели для её достижения и это математика без нейросетей на gpu работает. VLA имхо лучше сосредоточить не на управлении моторами а на интелекте и принятии решений т.к. именно этого алгоритмы не могут дать что-бы большие модели могли этими контроллерами правильно управлять и роботы меньше зависели от оператора и по миниму переобучались от изменений в механике.
А, что будет без HD карт в геометрически деградрированной сцене, долго EKF сможет работать на одних колёсах и gnss и IMU, что если ещё и gnss не станет как он будет определять курс по imu и колёсам? Есть какой-то аварийный режим, что может работать без одометрии просто реактивно объезжая препятствия?
“Для планирования пути косилки по участку используем алгоритм А*” - Если планируете использовать А* то советую использовать state lattice из ros/ros2 он самый быстрый а hybride A* довольно медленные. Ну и вам придётся над ними вероятно ещё надстройку делать, что-бы задавать маршруты для проходов (галсы) а это тоже не просто но в планерах типо mission planer, QGC есть готовый функционал для GPS галсов может его получится как-то использовать. Идея с радионавигацией как для косилки хорошая, обычно они поднимают много пыли и vslam или лидарный slam может работать плохо, вот только ищите UWB AoA которые возвращают ещё и курс, угол элевации что-бы вам-же было проще. Если не получится до diff rtk на UM982 кажется отличной идеей.
Может лучше было-бы на ROS/ROS2 собирать ваш ровер что-бы он лучше ориентировался indoor? Так-то ездить и собирать данные/показания по комнатам будет нужна навигация более продвинутая.
Что-бы правильно это сделать надо MPC или MPPI туда добавлять и писать в модели физику как в симуляторе что-бы контроллер понимал, что машина не может поворачивать без движения и сразу начинал генерировать тягу ещё модель трения что-бы контроллер понимал, что у колёс есть эффект плуга т.е. при повороте они создают сопративление, что требует больше газа на старте с повёрнутыми колесами. А так-то вообще в определенной ситуации, машина не сможет развернутся и выехать сместа (парковки) если ввести строгое правило, что пока задние колёса не крутятся например рулевые колёса должны смотреть ровно т.к. это увеличивает радиус разворота ведь при старте руль на некоторых машинах может и не успеть повернутся на нужный угол. Т.е. что-бы в крайнем случае если он руль повернуть не успевает он смог повернуть колёса на месте что-бы выехать.
Ну впринципе да, тесла уже один раз отключила радары понадеевшись на одни камеры за-что сразу была поймана на тесте кайота.
Однако, разработка софта по обьединению датчиков, цена датчиков + синхронизация данных от них всё это усложняет и удорожает систему а чем система сложнее тем больше в ней мест для отказа и просто сложности её создания, реализации граматного комплексирования что-бы она реализовывала все возможности того или иного железа на борту. Или для компаний сложность системы управления не важна и можно разработать софт любого уровня сложности, пока не упираешся в технологические пределы своего времени, типо по вычислительной мощности?
А почему не лучше повышать качество сенсоров против увеличения их количества? Так объединяя камеру + лидар лучшем решением будет использовать 3д цветной лидар т.к. он даёт 0ю ошибку проецирования цветных точек на геометрию + работает ночью а камеры нет. Или дорогой гироскоп лучше объединения, дешового гироскопа с магнитометром например или GPS т.к. он не зависит от спутников и магнитных помех, добавляя очередной датчик что-бы решить задачу получаешь новые задачи с этим датчиком.
Наоборот круто, что делают машинки от души искренне а не для войны и саморекламы. К тому-же на войне нужны простые и утилитирные вещи, там нет места прогрессу и техническому творчеству.
Попал-бы он к нам в Россию у нас-бы ему мигом указали место, а то ишь $2,7 млрд, у нас за еду-бы ещё и тапочки носил! )
В таком случае снимаю свои подозрения. Запустить последнею прошивку на Российском МК это круто.
Скажить а на отчественном МК ведь далеко не последняя версия INAV/Ardupilot запустилась наверняка? Все-таки они расчитанны на мощные МК на STM32 где много памяти и частота большая. Как далеко пришлось откатится назад, до какого релиза прошивки от нынешнего, часом не inav 1.1. что по сути клон multi wii?
У Tesla/CyberTrack например FSD автопилот по полям ездит и даже в пустыне работает, китайские пользователи благо его постоянно тестирую в суровых условиях и выкладывают видео его работы.
“С локализацией это не сработает, даже если взять целый готовый фреймворк, например, Autoware (открытый стек для автономного вождения на ROS), Apollo от Baidu или пакет robot_localization из ROS (который предназначен для слияния данных с одометрии и IMU).” - Может большество этих пакетов не доведены до ума намеренно? Почему ни один готовый пакет lio не отдаёт например движущиеся точки и не сигнализирует о попадании в дегенерационную сцену (например планарную) для лидара? Ведь разразработчики этих пакетов знают в своих бумагах пишут, что в случае её обнаружения нужно переходить на резервную навигационную систему или например реактивную систему управления? А пакеты лидарные внутри себя движущиеся точки по невязке находят и фильтруют в keyfram’ы их не добавляют что-бы не нарушать работу локализации но не отдают их? Такие “недоработки” наводят на мысль, что этот софт специально так сделан что-бы его можно-было проверить на тестовых данных датасетов, но не возможно на прямую использовать, этакий недостающий пазл отсуствует, который они могут при обращении к ним добавить. Такая вот сложилась система и всех это устраивает.
Но ладно у нас мэйкеров есть простые реактивные алгоритмы типо VHF и Потенциального поля не нуждающиеся в одометрии и следовательно работающие в планарных сценах, где лидар дегенерирует а в насыщеных геометрией сценах, работает оптимальное управление A*, mppi и т.д. Это логичный баланс ведь когда в поле 1-2 куста их можно обьехать просто слева/справа, вокруг пустота и потому самый лучший путь по прямой, что эти алгоритмы и делают, а как кустов станет больше то и одометрия сможет работать, сцена станет насыщена геометрией детекторы дегенерационной сцены запустят потоки одометрии лидарной например и алгоритмы оптимального управления.
А как у вас? Если вы говорите у вас свой надежный мультисенсор фьюжен конвейер, речь конечно об автономной навигации без GPS? Реактивные алгоритмы могут работать лишь на низкой скорости т.к. не осуществляют планирование (ведь они реактивны) и не позволяют использовать модель динамики (симуляцию) для того что-бы предсказывать силы действующие на машину в пути что-бы безопасно быстро перемещатся по открытому пространству. Сможите вы показать класс в следующей статье как выша одометрия надежная работает в поле, в геометрически деградированной сцене ориентируясь по текстурам подстилающей поверхности сопаставляя 2D текстуры от камеры либо по интенсивности лидаров как в пакетах coin-lio либо в IGICP, а может в поле будет работать одометрия от радара (не работал с радарами не знаю)? Вот это действительно будет уровень и покажет высокую надежность! Ведь сопоставлять в планарной сцене интенсивность и текстуры сложно, доступные opensource пакеты не только lio но даже vio и vslam в таких условиях не выдерживают и разваливаются не только потому-что матрица Гессе становится близкой к сингулярной, любое вращение вокруг вертикальной оси (Yaw) выглядит для лидара абсолютно одинаково, так как плоскость однородна, на плоскости нет вертикальных ориентиров (столбов, коробок), алгоритм оптимизации не может понять: сместился ли робот вперед (продольное движение) или он просто наклонил нос вниз (тангаж/Pitch), но и фундоментальная проблема, отсуствие избыточности данных в облоках точек что были в 3d. Эта избыточность позволяла значительно увеличить точность сопоставления облаков в кореляторе т.к. состыковать точно друг с другом 2 3д облака значительно легче чем 2 2д так сказать есть запас на компенсацию шумов и погрешностей. Что в долгосрочной перспективе приводит к более быстрому накоплению ошибки локализации без поправок от абсолютных датчиков типо GPS, создовая значительные ограничения на расстояния в автономной навигации подобно накоплению ошибки, что вы приводили в этой статье ИНС.
Очередная попытка импортозаместить все компоненты FPV, а какие это компоненты? Вот полётник, камера своя аналоговая хотя-бы, видео передатчик, радиомодуль типо lora свой для радио управления, по хорошему свои lcd экраны, РУ аппаратура и видео приёмник. Это минимальная база без которой критическая зависимость от импорта никуда не денется. А ещё нужно массовое произвоство всего этого возможно на следующем этапе. Вообще наблюдаю не одну попытку импортозаместить компоненты FPV и все они как правило заканчиваются на программирование какого-нибудь Российского МК, создании дизаина своей печатной платы а дальше не двигаются. Также в связи с блокировкам интернета и github странно, что вы использовали opensource прошивки и не делаете свои. Все-таки они хоббисткие там много лишнего и многие важные функции отсуствуют, однако, это наиболее простой и лёгкий путь перенести готовое ПО особенно в эпоху ИИ, что-бы продемонстрировать результат. При этом массовым уже становится применение дронов с ИИ и автозахватами/самонаведением (Bumblebee, Hornet), с весьма продвинутыми модулями защищеной связи на чипе и starlink.
Парадаксально, что в стране где без электроники столько проблем в промылености в часности машиностроении и у военных к электронщикам отношение…
Вам ROS надо осваивать и ставить 2D лидар он не дорогой в пределах 1к рублей, он даст вам лидарную карту и лидарный курс с которым вы мучаетесь, магнитный как вы сами заметили не работает а чистый гироскоп + акселерометр может дать только управление по угловой скорости, вот что у меня на видео про ручное управление. В таком случае его дрейф становится не важен. Если в будущем вы хотите что-бы llm или vlm, vla управляла вашим роботом ROS также вам пригодится что-бы ваш ИИ мог управлять роботом по точкам на карте или даже ИИ будет сразу вводить траекторию а робот по ней следовать. Тогда ИИ не придётся переучиваться управлять вашей тележкой и вообще скорость движения будет норм.
Ну в принципе многие контроллеры нормальные вполне исполнители, для многих задач и pid достаточно, что по сложнее mpc, это понятно и предсказуемо. GP-MPPI на гаусовых процессах вообще сам обучается online без нейросетей вносить поправки в вывод математической модели, динамики что-бы она лучше достигала цели, как например смещения из-за не верно посчитанного трения в модели или ставить подцели для её достижения и это математика без нейросетей на gpu работает. VLA имхо лучше сосредоточить не на управлении моторами а на интелекте и принятии решений т.к. именно этого алгоритмы не могут дать что-бы большие модели могли этими контроллерами правильно управлять и роботы меньше зависели от оператора и по миниму переобучались от изменений в механике.
А, что будет без HD карт в геометрически деградрированной сцене, долго EKF сможет работать на одних колёсах и gnss и IMU, что если ещё и gnss не станет как он будет определять курс по imu и колёсам? Есть какой-то аварийный режим, что может работать без одометрии просто реактивно объезжая препятствия?
“Для планирования пути косилки по участку используем алгоритм А*” - Если планируете использовать А* то советую использовать state lattice из ros/ros2 он самый быстрый а hybride A* довольно медленные. Ну и вам придётся над ними вероятно ещё надстройку делать, что-бы задавать маршруты для проходов (галсы) а это тоже не просто но в планерах типо mission planer, QGC есть готовый функционал для GPS галсов может его получится как-то использовать. Идея с радионавигацией как для косилки хорошая, обычно они поднимают много пыли и vslam или лидарный slam может работать плохо, вот только ищите UWB AoA которые возвращают ещё и курс, угол элевации что-бы вам-же было проще. Если не получится до diff rtk на UM982 кажется отличной идеей.
Может лучше было-бы на ROS/ROS2 собирать ваш ровер что-бы он лучше ориентировался indoor? Так-то ездить и собирать данные/показания по комнатам будет нужна навигация более продвинутая.
Что-бы правильно это сделать надо MPC или MPPI туда добавлять и писать в модели физику как в симуляторе что-бы контроллер понимал, что машина не может поворачивать без движения и сразу начинал генерировать тягу ещё модель трения что-бы контроллер понимал, что у колёс есть эффект плуга т.е. при повороте они создают сопративление, что требует больше газа на старте с повёрнутыми колесами. А так-то вообще в определенной ситуации, машина не сможет развернутся и выехать сместа (парковки) если ввести строгое правило, что пока задние колёса не крутятся например рулевые колёса должны смотреть ровно т.к. это увеличивает радиус разворота ведь при старте руль на некоторых машинах может и не успеть повернутся на нужный угол. Т.е. что-бы в крайнем случае если он руль повернуть не успевает он смог повернуть колёса на месте что-бы выехать.
Ну впринципе да, тесла уже один раз отключила радары понадеевшись на одни камеры за-что сразу была поймана на тесте кайота.
Однако, разработка софта по обьединению датчиков, цена датчиков + синхронизация данных от них всё это усложняет и удорожает систему а чем система сложнее тем больше в ней мест для отказа и просто сложности её создания, реализации граматного комплексирования что-бы она реализовывала все возможности того или иного железа на борту. Или для компаний сложность системы управления не важна и можно разработать софт любого уровня сложности, пока не упираешся в технологические пределы своего времени, типо по вычислительной мощности?
А почему не лучше повышать качество сенсоров против увеличения их количества? Так объединяя камеру + лидар лучшем решением будет использовать 3д цветной лидар т.к. он даёт 0ю ошибку проецирования цветных точек на геометрию + работает ночью а камеры нет. Или дорогой гироскоп лучше объединения, дешового гироскопа с магнитометром например или GPS т.к. он не зависит от спутников и магнитных помех, добавляя очередной датчик что-бы решить задачу получаешь новые задачи с этим датчиком.
Наоборот круто, что делают машинки от души искренне а не для войны и саморекламы. К тому-же на войне нужны простые и утилитирные вещи, там нет места прогрессу и техническому творчеству.
Будите в этом году тоже делать автономного робота?
Автопилот сделать например, 2д лидар добавить, что-бы карту строил и ездил по ней сам или по точкам.
А ROS/ROS2 планируете использовать для вашей машинки?
Крутая машина, планируете с ней что-то дальше делать, на ros/ros2 переводить?