GO63

Не только к калибровке относится. При работе тоже будет сильно влиять. Нужно избавится от подголовника с металлом. У меня вообще деревянный стул, поэтому и проблем никаких нет.

Вот - вот, именно в подголовнике проблема. Массивные металлические предметы должны быть не ближе полметра от магнитометра. И я уже об этом говорил, даже в этой ветке:

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

Отклоняется где - в калибраторе или только в Opentrack? Это очень похоже на неправильный выбор метода центровки. В калибраторе для Head нужно выбрать [Center Y,P] , а не [Center YPR]. В Opentrack нужно выбрать Options - Shortcuts - Centering method [Roll compensated]. Или иногда лучше Centering method [Point]. Теперь крепление модуля на голове с поворотом по Roll не будет вызывать влияние осей Yaw и Pitch друг на друга. Для датчика на GY-521 + GY-273 ещё важно, чтобы платы обоих модулей были закреплены строго параллельно друг другу. При плохой калибровке магнитометра такое тоже может быть. Нужно выложить файл измерений fltM, тогда можно точнее сказать.

Гироскоп точнее отслеживают поворот. Показания гироскопа приходится интегрировать и это ещё больше снижает шум. Самый большой недостаток гироскопа в том, что интегрируется и смещение гироскопа, что приводит к неустранимому дрейфу, второй недостаток - накопление ошибок из за численного интегрирования. У магнитометра и акселерометра показания в среднем не имеют смещения, если мы говорим о поворотах, но сильно зашумлены. Можно сделать трекер и без гироскопа, но тогда придётся на выходе включать фильтр низких частот, это не позволит отслеживать мелкие быстрые повороты. В 5DOF трекере это можно проверить, отключив гироскоп в калибраторе [G ---]. Отслеживание будет таким замедленным, как будто трекер в воду погрузили или в масло. Digital Motion Processor (DMP) есть во многих модулях сенсоров, он по показаниям датчиков строит кватернион поворота в реальном времени, который можно считывать извне. Проблема в том, как калибровать при этом датчики. И ещё тогда трекер будет привязан к одному типу модуля, нельзя будет в трекере использовать разные модули сенсоров.

Видеокамеры в шлеме или базовые станции: https://habr.com/ru/companies/droider/articles/538748/ Без магнитометра неизбежен дрейф по Yaw. И дрейф по Yaw виден в предыдущем видео - траектория прохода по длинному прямому коридору слегка изогнута. Дрейф это не "пружина", дрейф - поворот с постоянной скоростью. Без акселерометра ещё добавится дрейф по Roll и Pitch. С одним гироскопом будет дрейф по всем трём осям. Его можно только уменьшить повышением частоты опроса гироскопа и его калибровкой. Полностью устранить дрейф гироскопа нельзя.

Ну тогда ещё одно совсем уж впечатляющее видео от SebMadgwickResearch: Но не стоит рекламные ролики принимать на веру. Я уже давно проверил их файл с данными в проге на Делфи, и получил те же самые графики. И это действительно работает, но с такими ограничениями, что для трекинга головы совершенно не годится. Обратите внимание, во всех видео используется анимация из MathLab. Но MathLab не выводит графики в реальном времени, умеет строить только анимацию, предварительно рассчитав все выходные координаты в виде таблицы. И по алгоритму требуется сразу весь массив координат от гироскопа и акселерометра, за всё время от начала движения и до полной остановки. Для коррекции дрейфа используется определение моментов, когда датчик совершенно неподвижен, поэтому его и закрепили на носке ботинка. Если на ботинке это ещё кое как работает, то определить что голова стала неподвижной не удаётся. Да и не бывает голова полностью неподвижна. Следующий, самый скользкий момент - это использование для определения положения вектора акселерометра, преобразованного в систему координат Земли, из которого вычтен вектор гравитации. Если этот сигнал дважды проинтегрировать, то после первого интегрирования получим мгновенную скорость плюс линейно возрастающую ошибку из-за смещения центра акселерометра. После второго интегрирования получим положение датчика плюс равноускоренное движение из за интегрирования возрастающей ошибки. Ошибку можно сбросить в 0 после полной остановки датчика, когда ботинок окажется на полу. При начале движения ошибка опять начнёт накапливаться. В общем, не тратьте свои лучшие годы на этот метод. С помощью двойного интегрирования ускорения невозможно получить положение датчика без чудовищного дрейфа. Это неоднократно проверено и давно бы уже было сделано, если бы было возможно. Необходимо кроме IMU использовать ещё два опорных 3D вектора с нулевым смещением, которые будут устранять дрейф. Например, это могут быть три дальномера или пара видеокамер. Ничего не напоминает?

Ну так найдите в Мониторе строку Razor AHRS 5DOF [20191019] и дальше за ней следующие. Эти строки появляются во время быстрого мигания СД после ресета. Можно скопировать весь вывод в блокнот и искать в нём через поиск. Этих строк просто не может не быть, после нажатия [Reset] на Wemos.

Ну, понятно! Это окно загрузки скетча в Wemos. А я говорю об окне "Монитор порта": Инструменты - Монитор порта [Ctrl + Shift + M]. В нём внизу выбрать скорость 115200. Нажать [Reset] и искать протокол загрузки.

Хорошо, будем считать, что скетч прошивается правильно. Но я не понимаю, откуда у вас в Мониторе порта берутся такие строки: ets Jan 8 2013,rst cause:2, boot mode:(3,6) load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d Ничего подобного в скетче трекера нет. Тогда должны быть заданы: #define LEDpin 2 #define UseVibro 0 Попробуйте прошить ещё раз. В мониторе порта на скорости 115200 ищите строки похожие на эти: ... Razor AHRS 5DOF [20191019] SensorVariant 12 Bluetooth 0 BaudRate 115200 BatteryControl 0 UseWiFi 1 (EEprom) SSID: ?? (EEprom) Port: ?? ------------- Connecting to ??: ............

Картинку прошивки я показал со страницы https://sites.google.com/site/diyheadtracking/home/5dof-tracker/esp8266-wifi-version-of-the-tracker/esp8266-sketch-setup-and-firmware Вывод во время прошивки у меня отличается от ваших скринов. На скринах не видно нижнюю строку. Там написано, какая плата выбрана. Я для прошивки выбираю Wemos D1 R1. Сейчас ни вы ни я не уверены, что скетч прошит правильно. Попробуйте прошить пример для моргания светодиодом отсюда: https://arduinomaster.ru/datchiki-arduino/esp8266-wemos-d1-mini-raspinovka/ void setup() { pinMode(3, OUTPUT); // инициализация контакта GPIO3 с подключенным светодиодом } void loop() { digitalWrite(2, HIGH); // светодиод загорается delay(2000); // ожидание в течение двух секунд digitalWrite(2, LOW); // светодиод гаснет delay(2000); // ожидание в течение двух секунд } Нужно быть уверенным, что скетч прошивается правильно.

У меня подозрение, что это какой то посторонний скетч. Вы уверены, что вам удалось прошить Wemos? Можете показать скриншот Arduino IDE сразу после прошивки? Только расширьте нижнее окно с красным текстом, где показан результат прошивки. Должно быть примерно так:

Это что и откуда? Что было сделано?

Тогда давайте настраивать по шагам. 1. Редактируем: В Menu.h: #define OUTPUT__BAUD_RATE 115200 В ESP8266.h: #define UseWiFi 1 #define BATTERY_CONTROL 0 #define LEDpin 2 #define UseVibro 0 Не забываем записать каждый файл кнопкой [Ctrl+S]. 2. Прошиваем Wemos. 3. Открываем Монитор порта и проверяем скорость в нижней строке. Должно быть 115200 бод. Если не так, исправляем скорость, затем нужно закрыть и заново открыть монитор. 4. Нажимаем и отпускаем [Reset] на Wemos. Когда Wemos начнёт моргать с периодом 4 (или 2.5 сек) отключаем трекер и ищем в Мониторе полосами прокрутки протокол загрузки. Теперь то уж протокол точно есть и в правильном виде. Получилось?

С резистором 41k измеренное напряжение будет в разы завышено. Скорее всего, трекер будет "думать", что питается от USB. Если нет резистора 120k, лучше указать #define BATTERY_CONTROL 0. Это чтобы можно было зарядку в разъём BLS3 без ключа подключать любой стороной. Для разъёма с ключом хватит и 2х контактов. Это странно. Период должен быть около 4 сек. Версия скетча и калибратора одинаковая? Должна быть [20191019]. Одна из возможных причин - недостаточное питание от USB. WiFi трекер потребляет около 100мА. Попробуйте другое USB гнездо, отключите от парного USB устройства, если подключены, используйте короткий и толстый кабель MicroUSB. Значит, скорость Монитора порта отличается от скорости в самом трекере. Нужно проверить. Можно попробовать при открытом Мониторе порта нажать кнопку Reset на Wemos. Тогда загрузка пойдёт сначала и можно перехватить текст. Остановить поток ещё можно, отключив трекер.