Activity

Можно и так, интересует именно восприятие глубины стереокартинки в формате экрана в не полном угле обзора. Просто на окулусе пробовал - там полный угол обзора - то есть полное погружение, но там и искажения сильные… Получится, что скажете?

Ого быстро вы) Есть, для тестов nvidia Jetson TX2, потом можно Zynq 7020 - тоже есть. Сейчас концептуально интересна целесооборазность.
Попробовал транслировать в oculus 2 - пришлось писать приложуху для обработки и объеденения картинки, кооррекции дисторсии линз и хроматических аббераций. Потом подумал - зачем? картинка есть - объем есть, но абберации все равно есть… Вспомнил про данный шлем…

Привет всем, кто нибудь делал шлем для визуализации стереокартинки? Как восприятие глубины? Хочу подключить 2 камеры и передать на дисплей, кто что может сказать по этому поводу?

Алексей прав, нужен аксель, насчет статики или константной скорости я не могу уверено сказать, нужен эксперимент… Скорее всего будет уходить курс, быстро или медленно зависит от качества гироскопа и первоначальной калибровки.
Работает примерно так, грубо говоря: есть ускорения с акселерометра, которые можно спроецировать через ориентацию в глобальную систему координат, проинтегрировать - получим скорость. Если сравнить эту скорость со скоростью от GPS, то полученную невязку можно использовать для корректировки ориентации. То есть наша скорость зависит от а) ускорения с акселя б) ориентации, с помощью которой это ускорение проецируется на глобальную СК. Как высчитать коэффициент коррекции ориентации от невязки скорости я не знаю, дело в том, что он нелинеен и постоянно меняется. В фильтре Калмана на каждом шагу происходит линеаризация этой зависимости, и находится этот коэффициент…

Поздравляю с Днем Рождения Сергея, основателя этой темы и создателя платы F4BY))

Я за темой не следил какое-то время

Обкатал UKF на коптере, штука своебразная. Летает без использования магнитометра
rcopen.com/forum/f134/topic224458/6562
Вот есть видео, где показано как GPS корректирует ориентацию в фильтре Калмана.
rcopen.com/forum/f134/topic224458/6608
Обратите внимание чем больше неверен начальный курс компаса, по которому была начальная калибровка осей, тем сильнее пила. Эта пила - это коррекция GPS. чем сильнее пила, тем больше различается истинный курс и прогнозируемый фильтром. Можно заметить, что через некоторое время даже в 3-ьем тесте пила становиится все меньше и меньше, а можно предположить, что полетав я еще немного, курс приблизился бы к настоящему
rcopen.com/forum/f134/topic224458/6626
Фильтр сам находит как из показания GPS правильно скорректировать позицию и ориентацию.
rcopen.com/forum/f134/topic224458/6628
А вот Александр говорит тоже самое:
Как не помощник ? По нему видны итоги перемещения которые можно сравнить с интгралом акселя и выполнить корректировку.
rcopen.com/forum/f134/topic224458/6717

А кстати забыл сказать. Данный UKF, который я взял у AutoQuad можно еще хорошо так оптимизировать. Дело в том, что сигма точки которые генерятся в количестве 2*A+1. Где A - это кол-во переменных состояния + переменные шума. Так вот почитав форум Autoquad я выяснил, что при настройке UKF Билл использовал его способность к Parameter Estimation, то есть брал этот фильтр гонял в поле, где то брал рефференсные значения по переменным состояния. И загонял эти рефференсные значения в UKF. таким образом настраивались все параметры шумов Q, N, V. Но после настройки из вектора состояния Билл не убрал как раз эти V и N - параметры шумов процесса и шумов измерения. По сути они теперь константы и их рассчитывать не надо. То есть теперь по идее не надо вырабатывать сигма точки с учетом переменных шума (так как они константы), а только лишь для переменных состояния. Вот пример в текушем фильтре используется 17 переменных состояния и 12 переменных шума процесса и 3 переменных шума измерения, то есть всего оценивается 17+12+3=32 переменных. Для них вырабатываются сигма точки аж целых 32*2+1 = 65 точек. Каждая точка имеет размерность 32. То есть имеем 65 векторов с 32 измерениями. Каждая точка проходит через уравнения прогноза и измерения.
Представьте как можно это оптимизировать, если убрать из расчета шумы процесса и шумы измерения, ведь они все равно константы и были включены в расчет, только лишь для первоначальной настройки.
Поэтому кто это сделает может существенно повысить частоту UKF или загрузить еще переменных состояния.
Но чтобы это сделать надо хорошо так разобраться во всех функциях SRCDKF. У меня с разбегу не получилось.

Там связка аксель, гира, GPS. А так да, магнитометр не участвует в расчетах во время полета, только в самом начале, при соотношении осей. Я же об этом раз 5 говорил в предыдущих сообщениях

Думаю применение есть, если эта штука в реальном времени работает и не сползает если показания компаса не меняются (стабильный прямолинейный полет или нахождение на месте)

Конкретно у этого алгоритма, на управляющий вход подается кватернион. В данном случае кватернион рассчитывается с помощью Mahony (гира+аксель). Поэтому он потихоньку уплывает по оси Z. При этом этот уплывающий кватернион поступает в UKF, который занимается только рассчетом коэффициентов и глобального магнитного вектора. Главная цель - это конечно смещения. будут ли уплывать смещения, когда плывет кватернион, я не проверял. Но скорее всего будет уплывать глобальный вектор, а смещения останутся, но это не точно.
Собственно эти самые коэффиценты смещения могут пойти обратно в алгоритм расчета ориентации (уже аксель+гира+магнитометр), получается обратная связь, поэтому хз, как поведет себя эта связка. Поэтому если смещения уходят с плывущим кватернионом, но смысла включать реал-тайм калибровку нет, и тогда единственное применение - единождая калиборовка (просто она будет чуть проще). Если смещения не уплывают от плывущего кватерниона, тогда можно пустить его непрерывно. Но тут надо настроить коэффициенты адаптации, как быстро алгоритм должен реагировать на магнитные возмущения, надо настроить так, чтобы кратковременные выбросы были учтены и отбрасовались алгоритмом ориентации, но долгосрочные изменения магнитного поля перестраивали коэффициенты. Это все в случае раздельного алгоритма ориентации и алгоритма калибровки.
Можно опять все собрать в кучу и сделать единый UKF, настроить коэффициенты адаптации, коэффициенты игнорирования кратковременных магнитных возмущений. Чтобы с этим всем экспериментировать, надо хорошо так разобраться с UKF.
Я не предлагаю готовое решение, тут еще много работы, тестов, подгонки.

Честно говоря, в деталях еще даже не смотрел - времени не было. Реализовано удобно, модульно, если в тестах будет хорошо работать с разными наборами датчиков (аксель+гира, аксель+гира+компас, аксель+гира+GPS, аксель+гира+компас+GPS) - возможно заменит комплиментарник в INAVе.

Да на самом деле, можете говорить как есть, все это писалось паралельно изучению STM, стилей программирования, поэтому код - это сборная солянка, грязный, не гибкий, не удобный. Многое я бы сделал иначе.
Конкретно в той прошивке работает набор - аксель, гира, GPS, барометр(хотя на самом деле, его можно убрать, толку от него 0). Чтобы добавить магнитометр надо добавить функцию simDoMagUpdate. Но я не вижу в этом смысла, так как тот вариант который там есть - это законченное решение, магнитометр там не нужен. Разве что, для того чтобы еще добавить в мат модель магнитные смещения и коэффициенты масштаба. Но тогда в ресурсы STM32F4 уже не впишемся. Поэтому Для коптера я считаю это самый оптимальный вариант.
Для отдельного универсального IMU можно еще поэкспериментировать с разными датчиками, мат моделями, алгоритмами.
А также для полного UKF, который будет иметь мат модели акселя, гиры, компаса, видеокамеры, GPS, учитывающий и коэффиценты смещения и масштаба, работащий внутри и вне помещений. Но тут уже сложнее, и железо как минимум intel core i7.

Ссылка на код:
www.dropbox.com/sh/…/AADAb2jiAQuKgIAE1Eje6mNDa?dl=…
А как вам тот проект с OpenCV и логами, когда видео поворачивается с помощью логов? кто нибудь его использовал?

Ок, да, делайте с кодом, что хотите. Только хотелось бы узнать о результатах тестов, или какие то дополнения, усовершенствования. Вопрос: куда скинуть код?
Кстати какие у вас впечатления о прошивке квадрокоптера? Что то успели перенять полезного?

Интересные вещи говорите. Спасибо.
Кому нужен алгоритм, могу выложить в свободный доступ, вопрос в каком виде? Могу только пару файлов кинуть, или сделать порт на F4BY. Вопрос, есть ли реальное применение этой штуке, и кому оно нужно? Кто готов проверить и развить тему?

Вот еще одно видео, там уже я запустил непрерывный режим калибровки. Попеременно подношу и убираю магнит.

А каким образом склонение определяется, да еще с точность 1-2 градуса? По моему это лучше все же по карте склонений определить.

Тут вы правы, я поспешил с выводами. Изначально были сомнения на этот счет. Провел побольше тестов, я просто удачно попал в первый раз. А работает он так: В UKF отлсеживаются 6 переменных состояния (3 искомых смещения и 3 составляющих магнитного вектора в мировой СК), в качестве алгоритма ориентации используется обычный Mahony. В сам UKF в качестве управляющего сигнала идет кватернион с Mahony. UKF пытается подобрать такие коэффициенты смещения и такой вектор магнитного поля в мировой СК, чтобы его прогноз совпал с реальным значением магнитометра. (это что то типа Parameter Estimation, так можно нейросеть например настраивать, или просто подбирать физические параметры системы, просто для проверки этой концепции попробовал откалибровать магнитометр).

Кстати, масштабы по осям зря игнорируешь - они так же важны как и у акселерометра, а у компасса еще зависят от места установки, так что даже точные калибровки с завода не помогут.

Вот эта мысль меня тоже волновала, но я прообовал подносить магнитомягкие материалы в виде ферромагнитного сердечника трансформатора, сфера почти не исказилась. Поэтому я сделал предположение, что это не так важно.
А как еще можно проверить? Как сильно может плющить сферу?

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

Ух ты, я про это не слышал. А можно поподробнее?

А что дает такой подход ?

Ну примерно экономит время на калибровке компаса, провернул пару раз по осям, как у Dji - все готово.

(фактически поиск максимумов и минимумов по осям, с последующим смещением)

Чтобы попасть в максимумы и минимумы магнитной сферы - это надо знать как расположен магнитный вектор в данной местности, либо собрать кучу точек в предполагеамых областях максимумов/минимумов (а их целых 6 штук), отсеять выбросы, я бы сказал, что это сложнее, чем собрать полную сферу, хотя честно я не пробовал и могу ошибаться.

К тому же не понимаю: зачем для компаса нужен расчет магнитного склонения (?) лететь точно на северный полюс ?

Ну а как комплексировать данные с GPS? Тут в любом случае надо выставить виртуальные оси с реальными осями. Во многих случаев можно пренебречь магнитным склонением, так как оно 0-15 градусов и система использующая магнитометр и GPS будет на грани, но есть места на планете, где магнитное склонение достигает 120 градусов и 50, как можно это не учитывать? посмотрите карту магнитного склонения.
Да и написал я этот алгоритм как проверку концепции, не было конкретной цели.

Привет всем, написал алгоритм калибровки компаса. Работает в реал-тайме, не требует сбора полной сферы магнитных векторов, дополнительно выдает магнитное склонение и наклонение в данной местности. Думается, что DJI используют аналогичный алгоритм, так как, я попробовал провести такие же манипуляции, и компас откалибровался.
Замечания: результатом алгоритма является только 3 коэффициента смещения, коэффициенты масштаба и взаимовлияния осей отсутствуют, но я думаю что этого достаточно, чтобы определить направление на север с точностью в несколько градусов.
В качестве датчиков: акселерометр, ДУС, магнитометр. Алгоритм основан угадайте на чем? правильно моем любимом UKF=) в принципе всего 6 перемнных сосотяния, не жрущий. полный цикл прогноза занимает 208 мкс, а цикл прогноза и коррекции вместе 500 мкс на STM32F407 с включенным FPU.
Видео:

Давно не интересовался как люди калибруют компас. Может я отстал от жизни и это прошлый век??

да я еще ничего не сделал, хотел заняться если время позволит) на ф4 не потянет, то что я хочу и ф7 не потянет. Тут либо тот же i7 либо систему на кристалле типа zynq 7000. Но пока рано говорить, пока даже алгоритма нет.

Если есть спрос, могу написать небольшую прогу на labview для настройки базовых параметров, их передачи через uart-usb и сохранения в fram. Но если делать по уму, то надо сделать порт mavlink, что мне лень. да и собственно кому нужна эта прошивка, если у нее особых фич нет.
Есть ли люди готовые прошиться и попробовать? если есть, то я могу еще пару дней подготовить юзер мануал и прогу для настройки.
конкретно у этой прошивки есть ограничения:
4 ВМГ
вход приемника PPM SUM
вопрос с калибровкой компаса и акселерометра, так как мой способ довольно геморный
это мне переделывать лень

Суть в навигации без GPS, внутри помещений и снаружи. С помощью видеокамеры.
Есть много таких проектов, как коммерческих например:
www.stereolabs.com
bridge.occipital.com
Так и открытых:
github.com/ethz-asl/rovio
github.com/HKUST-Aerial-Robotics/VINS-Mobile
Опять же почти ничего нового я не сделаю. Просто кое-какие моменты сделаю иначе, должно быть получше. Пока для себя, в качестве магистерской.

Всем привет.
В общем первый раз пользовался GitHub и вообще всеми этими непонятными терминами (коммиты, бранчи и тд)
Залил прошивку на гитхаб
github.com/Ilyaprok/QUAD_UKF
в данном случае порт под F4BY. Но так как работает под мой конкретный сетап, врялди кому то пригодится в целом виде.
Сейчас начинаю работу над новым проектом - визуально-инерциальная навигация. С коптером пока заканчиаваю.
Надеюсь хоть кому то прошивка будет полезна.

Всем привет!
Наконец-то попробовал добавить второй GPS модуль в UKF.
Идея заключалась в следующем: имея два модуля имеем трехмерный вектор, а зная расположение модулей на раме коптера, можем корректировать ориентацию по всем трем осям. Плюсом более точные координаты.
Реализовал это в UKF как 2 независимых отдельных датчика. Отличие только в моделях, то есть прогнозируются разные координаты.
Вкратце идея оказалась полным провалом. Координата скакала то к одному модулю, то к другому. А о коррекции ориентации и говорить нечего. Все дело в том, что относительная точность модулей довольно хорошая, но абсолютная - пару метров. Вот они и плавают в радиусе 4 метров, соответственно и вектор плавает.
Идея с несколькими GPS имеет смысл только в случае RTK.

Субтитры включите, там объяснение че за точки
У кого какие новости, кто нибудь поиграл с UKF, портировал к себе? Или Dji все завхатили?

Видели что нить подобное? По-моему крутое применение алгоритмов и всей математики помимо коптеров

norm = __sqrtf(accX*accX + accY*accY + accZ*accZ);

noise = UKF_ACC_N + fabsf(9.81 - norm) * UKF_DIST_N;

Увеличиваю дисперсию шума в модели датчика, и UKF меньше доверяет акселю.

Ориентация ведь из GPS корректируется в том числе, но на самом деле по видео сложно сказать о качестве ориентации. Искажения линзы и подобранные коэффициенты перемщения картинки от угла все портят.

www.dropbox.com/s/…/opencv_test3.zip?dl=0 проект
к нему еще нужно установить опенсв 3.2,
дополнительно нужны последовательности кадров с бортовой камеры в формате 640 на 360 opencv_test3\opencv_test2\seq2
файл .csv где прописаны имена кадров и время opencv_test3\opencv_test2\frames2.csv
и файл с углами и временем opencv_test3\opencv_test2\angles2.csv

Провел тест на отключенном GPS, то есть как работает удержание высоты по барометру

Лог высоты

Еще тест оказания ускорений на ориентацию.

И еще очередной тест новой фичи со стабилизацией.

Есть код, могу скинуть, кому надо.

Монтировал в visual studio с помощью библиотеки opencv

Всем привет.
Записал интересное видео. Хотел проверить качество ориентации, полученной с UKF. А именно как она уплывает на виражах и ускорениях.
Суть такая - ориентация, записанная в логах синхронизируется с видео с камеры. Получаем своеобразную софтовую стабилизацию.
Горизонт не идеально ровный, ибо помимо качества самой ориентации UKF повлияла рассинхронизация видео и логов, искажение линзы, переменный центр вращения, вибрации. Поэтому на резких поворотах горизонт не ровный. Также как выяснилось частота записи логов плавает, из-за чего на видео такие скачки и дергания.
Но суть вроде понятна, что с помощью UKF можно получить абсолютную, привязанную к глобальным осям ориентацию, для использования коррекции подвесов.

12х4,5 - пропы
F4006 KV750 ( www.ebay.com/itm/…/201613540237 )
регули - xrotor 40A hobbywing

да я тоже проделал тест:

Короче , вот видео тестов nvidia shield tablet k1. Вкратце лаг 0,2 секунды, даже при записи экрана. Диагональ в самый раз. На солнце ничерта не видно, только в сильной тени, в машине норм видно.

Всем привет, периодически при включении коптера - выскакивает ошибка компаса, подвес издает звук - бик-бик пауза бик-бик … . При рыскании подвес не следит, а как будто смотрит в одну точку, соответсвенно его передергивает при рыскании. То есть проблема в компасе, раз-через раз, коптер выдает ошибку компаса, при этом на показаниях по нулям. Бывает нормально включится, и компас показывает цифры MOD 1360. Это много? компас намагничен и из-за этого периодически выскакивает ошибка при включении?? Или что-то с контактом, с проводкой? Помогите плиз, первый раз фантом купил, без понятия, что это.

второй датчик не помогает в таких случаях?

нет, на него же тоже действует ускорение

Я что спросил то, при воздействии ускорений - горизонт смещается, настройка в принципе не поможет. Нужна коррекция с полетника, есть такая фича у шторма?

Всем привет, приобрел Nvidia Shield Tablet K1 на амазоне в общей стоимости за 226$ c доставкой.
Покупкой доволен, беглый обзор с DJI GO для p3a показал нормальное качество (относительно).
Вот чтобы быть поболее объективным, какие тесты показать? Какие настройки включать/выключать в приложении (каналы видео, видеозахват и тд)?
1 - с таймером на экране могу сделать
2 - на солнце сфоткать
3 - в полете, но тут нескоро я смогу полетать.

Друзья, первый вопрос - как данный контроллер справляется с резкими ускорениями, как ведет себя горизонт? Второй вопрос - есть ли функция коррекции с полетника? Третий вопрос - код данного контроллера открытый?

Спасибо за ценное замечание. Может в этом есть смысл.
Есть идея получить такую зависимость для своей ВМГ при среднем полетном напряжении аккума. Загнать ее после выхода микшера, перед таймерами с ШИМом.
Возможно получится более линейная отзывчивость. Плюс не надо крутить ПИДы на новом кваде, а достаточно загнать зависимость для нового ВМГ. У кого какие мысли?

Всем привет, кто читает эту тему.
Кто-нибудь пробовал команды от микшера к ESC прогонять через подобную зависимость? только по оси Х не обороты а коэффициент заполнения ШИМа

Или она уже встроена в регулятор оборотов?

Зачем ?? если сразу есть угол на точку…

Так когда остановится надо, если мы прост полетим в данном направлении? Это раз. Во-вторых, как вы будете зная только направление к точке вводить задание на ПИД , в простом случае - надо что-то типа задатчика интенсивности, типа апереодического звена с насыщением. У меня уже кубический интерполятор стоит, тут без знания расстояния не получится кривые разгона задать и скорости.
ошибка во float есть, но она константа и от расстояния не меняется. Можете проверить перевести градусы из дабла во флоат - потом пересчитать в метры, ошибка будет 10-30 см. Для задания точек, это не существенно. Для ОС удержания позиции существенна, поэтому у меня сначала вычитаются координаты в int32, а потом умножаются на коэффициенты пересчета…

В любом случае нужно знать не только азимут, но и расстояние до точки в метрах по двум осям. В том коде, что я привел, расстояния высчитываются, а угол можно узнать через atan2f(GPS_Y, GPS_X).
В моем подходе, ошибка будет от несовпадения элипсоида и геоида, а также как вы правильно заметили, что чем дальше от места старта, тем больше ошибка. Но на практике чтоб ошибка хоть как то повлияла, надо от точки старта перпендикулярно линии экватора двигаться километров 100-200 в моей местности. Если вы делаете совсем универсальный аппарат, и он может за один полет пролететь такое расстояние либо вы будете летать на полюсах, то можно каждый раз при приеме ЖПС сигнала делать пересчет коээфициентов.

короче, упрощенный вариант математики, - приближаем поверхность к плоскости… (я понял).

А я уже не понял. А как иначе?
Я понимаю так: вот например есть у нас две точки, у каждой точки долгота и широта. Нам надо узнать вектор, соединяющий первую точку со второй. Возьмем за начало отсчета первую точку. Находим коэффициент пересчета долготы в метры, он зависит от широты, при этом коэффициент из широты в метры постоянен, вроде (в упрощенном варианте). Далее вычитаем из второй точки первую по градусам. Умножаем полученные коэфициенты на разницу в градусах и получаем разницу в метрах, то есть наш вектор.
Та функция navUkfCalcEarthRadius считает уже не просто сферу, а элипсоид, но принцип тот же.
А как иначе? Или я не о том?

Если вы про курс носа коптера, то он вообще отвязан, я им управляю с пульта.

У меня при первом хорошем приеме ЖПС высчитываются коэффициенты для пересчета из градусов долготы и широты в метры. Далее все считается в метрах от старта

Вот это обработка в прерывании по приему GPS:

	if ((GPS_satellits > 8)&&(GPS_pDop<175))
	    {
		if (flag_start_home == 0)
		    {
			double LAT;
			flag_start_home = 1;
			GPS_height_start = GPS_height;
			GPS_lon_start = GPS_lon;
			GPS_lat_start = GPS_lat;
			LAT = (double)GPS_lat/10000000.0f;
			navUkfCalcEarthRadius(LAT, &KX, &KY);

		    }
		xSemaphoreTake(xGPS_UKF_Mutex, portMAX_DELAY);

		GPS_X = ((float)(GPS_lon-GPS_lon_start))*KX;
		GPS_Y = ((float)(GPS_lat-GPS_lat_start))*KY;
		GPS_alt = ((float)(GPS_height-GPS_height_start))*0.001f;

		xSemaphoreGive(xGPS_UKF_Mutex);

		StateNavUKF &= ~UKF_BAD_GPS;

		flag_get_pvt = 1;
	    }

сама функция персчета, взята у автоквада:

static void navUkfCalcEarthRadius(double lat, float *k_x, float *k_y) {
    double sinLat2;

    sinLat2 = sin(lat * (double)DEG2RAD);
    sinLat2 = sinLat2 * sinLat2;

    *k_y = (double)NAV_EQUATORIAL_RADIUS * (double)DEG2RAD * ((double)1.0 - (double)NAV_E_2) / pow((double)1.0 - ((double)NAV_E_2 * sinLat2), ((double)3.0 / (double)2.0));
    *k_x = (double)NAV_EQUATORIAL_RADIUS * (double)DEG2RAD / sqrt((double)1.0 - ((double)NAV_E_2 * sinLat2)) * cos(lat * (double)DEG2RAD);
    *k_y /=10000000.0f;
    *k_x /=10000000.0f;
}

да, проверяется расстояние от текущего положения коптера до указанной точки, если оно меньше 0,4 м, то переходим в следующую точку. 0,4 м просто взял на глаз.
По идее сфера радиусом 0,4 м получается.

Всем привет! Запилил новые 2 режима для фана.

Еще ко мне Dji Phantom 3 Advanced пришел. Первые впечатления, что довольно продуманы некоторые ньюансы. Векторного управления на движках я не заметил ,по-моему FOC должен себя иначе вести, но я не уверен. У подвеса обратная связь по положению ротора есть, отклонения отрабатывает плавно, без дребезга. Попробовал погазовать без винтов - коптер видит, что винтов нет, выводит сообщения. По яву - реагирует на угловую скорость, а не на положение. Однако в полете возвращается по яву.
Вообщем надо изучать. Удержание позиции работает четко и быстро, не плавает.
Будет время запилю тесты, сравнение.
Еще в планах попробовать отказаться от компаса вовсе и реализовать задумку с 2-мя ЖПС на диагонали для определения ориентации. Но это попозже