Activity

Да есть такой метод захвата фазы - короче попробовать вырезать весь шум?

Врятли получится (навскидку)… Попробуй пять “волшебных” формул от калмана на аксель и гиру по всем осям, раза в два шумы точно уменьшаются… (я себе сделал, доволен)

По сути они теперь константы и их рассчитывать не надо.

Просто реплика: удивительная вещь этот фильтр … Не первый раз встречаю в разных источниках подобные описания принципов его работы типа - “для расчета требуется то то и то то” “с такими то ограничениями и условиями” НО ! потом - “можно это и то не считать… а принять за константу взятую с воздуха” и “ограничениями и условиями можно пренебречь” потому что будет работать и так…(!)
Прям чертовщина какая то… получается что он как бы сам себе противоречит но все равно работает… (для меня, наверно, это самое сложное в процессе понимания его сути, видимо мозг (мой)) не может мыслить настолько абстрактно)…

Ну а как комплексировать данные с GPS?

Да, согласен, у меня просто все примитивно (хотя можно и так))…

Может я отстал от жизни и это прошлый век??

По мне, так это скорей день завтрашний ))) А что дает такой подход ?
У меня примитивно находится пресловутая сфера при нескольких вращениях в “реальном времени” (фактически поиск максимумов и минимумов по осям, с последующим смещением) - в результате те же ~ 2-5 градусов точности обеспечены…
К тому же не понимаю: зачем для компаса нужен расчет магнитного склонения (?) лететь точно на северный полюс ?
как я понимаю для возврата домой можно обойтись и без “честного” севера.

шина не так важна для выборки датчиков

Говорим, по моему, о минимальном времени цикла: чтение датчиков /обсчет данных /выдача управляющего сигнала (?)
В этой цепи шина имеет немалое значение всетаки SPI на порядок шустрее i2c…
А то что эффективней управление шагом или оборотами, это уже другой вопрос. (конечно серва+механика еффективней)

То что мы будем делать выборку раз в час или 200 Раз в секунду - это не имеет никакого значения

Ну “раз в час” это конечно перебор ))), а так, по идее, регулирующее воздействие на аппарат должно соответствовать его физическим свойствам, таких как масса, инерция, другими словами - вряд ли квадрокоптер сможет “колебаться” в пространстве с частотой 100 Гц (ды даже 50) тогда какой смысл иметь данные для стабилизации чаще… к томуж сама винтомоторная группа не сможет эффективно компенсировать положение на таких частотах, опять же из за собственной суммарной инерционности…
Я себе сделал 500 гц цикл только в надежде на то, что сам алгоритм “слияния” будет более шустро корректировать углы по акселерометру и тогда “коэфициент доверия” к акселю можно занизить, и тем самым снизить влияние линейных ускорений на результат.
Вроде как лучше, но не факт, наверно чтоб получить ощутимый результат частоту надо поднять еще на порядок, а это невозможно…

не меняя логики построения

Да видимо так, к тому же, магнитометр вообще довольно низкоскоростное устройство, наверно из-за чисто физических свойств сенсора или его ацп, поэтому подключать его по SPI смысла мало…

В даташите на 9250 вскользь упоминается 200Гц.

Тут ситуация такая: гира и аксель читаются как и у других датчиков с частотой 2000 и 1000 Гц соответсятвенно… т.е. при желании цикл можно смело и килогерц сделать… (у меня работает на 500 гц), а вот с внутренним магнитометром, как всегда маленькая “засада” его чтение организовано очень “оригинально” через мост SPI-I2c,
т.е. физически внутри чипа магнитометр подключен по i2c а обращение к нему идет по SPI через подачу команд (скорость опроса соответственно 20 гц) …
Нафига такие костыли мне не понятно, наверно у производителей есть весские аргументы на этот счет…

Может что-то еще уже ясно.

Судя по рекламному видеоролику (верхняя ссылка от Ильи) быстродействие не очень… и непонятно к тому же на каком железе это крутится, на сайте пишут что желательна видеокарта от Nvidia, но будет работать и без нее. В принципе и так понятно, что для вменяемого результата нужна топовая “обвязка”, видео-есть-видео однако… тут на гнилом железе ничего не выйдет…

С помощью видеокамеры.

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

визуально-инерциальная навигация

Суть в чем ? (если не секрет конечно)

какой-то кот в мешке?

Ну как же, - внутри сенсора ядро АРМ, которое на выходе выдает (по желанию) готовые углы эйлера или кватернионы…
Правда делает это с частотой 100 Гц максимум, короче аппаратный IMU…
Насколько это в реале работает надо проверять, по опыту работы с изделиями от BOSH могут возникнуть проблемы, связанные с “секретными” регистрами, не освещенными в даташите… Ды и нужно ли это в принципе - вопрос… Тогда что будет основной микроконтроллер делать непонятно, концепция полетника меняется в принципе…

Во что нашел интересное(?)
www.bosch-sensortec.com/bst/products/…/bno055

кто нибудь поиграл с UKF

Где найти доходчивую инфу по UKF ? (не на английском)

относительная точность модулей довольно хорошая

У абсолютного датчика относительная точность , это как ?

Тогда stm32 не хватит. Вообще насколько перспективно пытаться создать полетник на этом камне, или на 2017-2018 год лучше сразу смотреть другие процы?

Ответ на этот вопрос зависит от желаемого функционала (очевидно)…
Мне видится на данный момент следующее:
для “классической” стабилизации/полета по точкам со всеми наворотами, включая “ужасные алгоритмы” типа калмана, stm32 - за глаза (например у меня он еще и OSD успевает обсчитывать), а если замахиваться на экзотику (пока еще) типа стабилизации на основе видеокартинки или еще чего в этом направлении, то конечно надо более мощный проц…
Кстати, для вменяемой обработки видеосигнала процессоры линейки “малинки” или ее даже более мощных аналогов, все равно не годятся, слабоваты, не говоря уже о значительных проблемах с разработкой собственного ПО по них ввиду закрытости средств разработки и документации…
Отсюда делаю вывод: пока что stm32 - оптимальное решение…

Если в полетник добавить:

Все эти задачи, по моему, stm обсчитает без проблем…

По нему видны итоги перемещения которые можно сравнить с интгралом акселя

А ведь да, - факт…, надо пробовать, спасибо (!). Хотя, помню, давно еще пробовал интегрировать линейные ускорения, это ж сразу интеграл “в небо” улетает, их как то надо корректировать тем же ЖПС чтоль (?)
(сразу скажу что Калмана так и не осилил, - слабО…))

вносить коррекцию в ориентацию

Под “ориентацией” что подразумевается (?), (я конкретно - крен и тангаж имел ввиду), вот, судя по видео от Ильи, смотрю что при затяжных виражах по кругу, после отпускания стиков, его аппарат сразу “находит” правильный горизонт, хотя по идее должен лететь вбок, так как вектор гравитации акселя уплывает при центробежном ускорении. у меня к сожалению пока так… Еще не испытывал, но сделал, полное отключение акселя, при превышении некоторого порога лин.ускорений (а у Ильи динамичекое регулирование по факту). Видимо надо тоже так сделать, иначе от вибраций кульбит может произойти)))
тут, как бы, ГНСС не помощник(?) или я че туплю…

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

Как реализована компенсация линейных ускорений ? (в общих словах, сама идея, так сказать) или просто коэффициент влияния акселя сильно мал ?

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

Вопрос не в тему - на каком винте dt-750 полтора килограмма тяги дает?(жесть)

а если ОСД данные слать отдельным потоком по тому-же wifibroadcast

Да, один из возможных вариантов, тем более что информация OSD, по факту, немного байт займет…
(даже в аналоговое видео подмешивается телетекст)

Что то своё на их базе хотите сделать?

Конечно. В идеале, хотелось бы на базе малины (а еще лучше ее более мощных аналогов) реализовать управление моделью + Hd video + OSD, что б всё это было в одном wi-fi канале, а не “с пятью антеннами”, короче полный фарш для FPV…
Что то вроде известного проекта “виртурилка”, только на вышеуказанной новой платформе. (Кстати, реализовать OSD не такая уж простая задача, как может показаться, опять же из-за ограниченных программных средств, приходится работать непосредственно с OpenGL-Es, а это весьма непросто)
По моим оценкам, само “железо” вполне, даже - за глаза, пригодно для реализации, весь вопрос упирается в борьбу с операционной системой…

введите “ez wifibroadcast source”

Там готовые образы SD (судя по размеру архивов)… (?), много видео, болтовни, исходников не нашел…(плохо искал?)

Исходники есть.

Где ? (ссылочку…)

Всё запускал на одноплатнике Raspberry Pi 2B+

А на стороне приема что ? (тоже Pi ?)

Что то Вы делали сильно неправильно.

Я, в принципе, только пробовал общедоступные и открытые давно программные средства типа socat, netcat (gstreamer запустить на orangepi так и не удалось…).

На Wi-Fi broadcast лаг ~120-150

Дык это уже не “нахаляву”, люди, насколько я понял, как раз, смогли “распотрошить” wifi-евский протокол и оптимизировать его… , и заметьте, исходников на этот проект вы не получите, только “как есть”.
(могу ошибаться, сильно не вникал).

что-то серьезное, то на голом железе?

Однозначно - да, идеальный вариант.
По большому счету, все что надо железу - это передавать без задержек и лишних заморочек пакетики от видеоядра (той же малинки) на wifi модуль… Но что то я не встречал на просторах инета желающих/могущих переписать заново линукс со всеми драйверами, или сделать ему реалтайм-альтернативу… максимум попадаются сомнительные попытки “пропатчить” его… Очевидно что такая работа требует сотен (тысяч?) человекочасов и заниматься этим ради такой узкой задачи никого не заставишь…))
А “нахаляву” можно конечно попробовать и как я, (и не только) и получить: лаг ~0.4 сек. при 720p, небольшую дальность, плюс непредсказуемую отказоустойчивость…

Raspberry Pi - какой брать (2, 3 или Zero)?

Мое мнение - чем меньше тем лучше, никакой выгоды от “мощности” PI2 или PI3 Вы не получите, лаги не от процессора, а от самого линукса…

Что можете порекомендовать из антенн?

По большому счету разницы никакой, все равно 100 мвт передатчик (при 2.4 Ггц и и ширине полосы в ~5 Мгц) даст вам радиус метров 200-300 стабильной картинки, не больше… Клевер дает только более шарообразное поле, но и немного излучаемой мощности он тоже как-бы скушает, чем скажем однобоко вытянутое поле “сосиски”…
А вообще, считаю, что делать HDвидеолинк на платформе Raspberry - скорей забава “на поиграться” добиться маленькой задержки видео, а главное стабильности работы будет весьма проблематично (недавние собственные эксперименты привели меня к такому мнению)…

Так когда остановится надо

Согласен, расстояние также желательно (но не обязательно)…

Можете проверить перевести градусы из дабла во флоат - потом пересчитать в метры

Верю на слово. (скорей на выложенное видео полетов…, нет вопросов…)

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

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

надо от точки старта перпендикулярно линии экватора двигаться километров 100-200

учитывая разрядность <float>, предположу, что ошибка будет видна на гораздо меньших расстояниях… (хотя, что спорить, проверять надо…)

А как иначе?

Моя функция принимает координаты двух точек по GPS в радианах (текущая позиция и целевая позиция) а на выходе выдает честный азимут в градусах (угол от направления на север) из текущей точки на целевую… математика была взята мной давно с какого то геодезического сайта (уже не помню) там как бы всё с учетом тонкостей “большой сферы”…
На практике еще не испытывал, потому и интересуюсь - как другие люди делают…
Есть просто мое предположение, что при упрощенном подходе ошибка расчетов будет расти с увеличением дальности…
(Надо в поле походить и посмотреть на практике…)

Если вы про курс носа коптера

Я про нахождение вектора движения от одной точки к другой (его же надо считать, независимо от “носа” аппарата) или я че туплю ?

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

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

0,4 м, то переходим в следующую точку.

А курс на точку, я так понимаю, считается и корректируется постоянно в течении следования (?)…
Вообще, нельзя ли подсмотреть функцию пересчета положения по GPS в азимут точки ?? Для сравнения со своей:

int16_t get_azimut( float lat1,  float long1,  float lat2,  float long2)
{
float dlon_W, dlon_E,dphi, atn2,tc;
int16_t az;
int8_t sign;

	    dlon_W = (long2 - long1) - (2*PI*(floor((long2 - long1)/(2*PI))));
	    dlon_E = (long1 - long2) - (2*PI*(floor((long1 - long2)/(2*PI))));
	    dphi = log((tan((lat2/2) + (PI/4)))/(tan((lat1/2) + (PI/4))));

	    if (dlon_W < dlon_E) {
	        dlon_W = -1*dlon_W;


	        if (dlon_W >= 0)
	            sign = 1;
	        else
	            sign = -1;

	        if (abs(dlon_W) >= abs(dphi)) {
	            atn2 = (sign * PI/2) - atan(dphi / dlon_W);
	        }
	        else {
	            if (dphi > 0) {
	                atn2 = atan(dlon_W / dphi);
	            }
	            else {
	                if ((-1*dlon_W) >= 0) {
	                    atn2 = PI + atan(dlon_W / dphi);
	                }
	                else {
	                    atn2 = (-1*PI) + atan(dlon_W / dphi);
	                }
	            }
	        }
	    }
	    else {

	        if (dlon_W >= 0)
	            sign = 1;
	        else
	            sign = -1;

	        if (abs(dlon_E) >= abs(dphi)) {
	            if (dlon_E > 0)
	                atn2 = sign * PI/2 - atan(dphi / (dlon_E));
	            else
	                atn2 = 0;
	        }
	        else {
	            if (dphi > 0) {
	                atn2 = atan((dlon_E) / dphi);
	            }
	            else {
	                if ((dlon_E) >= 0) {
	                    atn2 = PI + atan((dlon_E) / dphi);
	                }
	                else {
	                    atn2 = (-1*PI) + atan((dlon_E) / dphi);
	                }
	            }
	        }

	    }


tc = atn2 - (2*PI*(floor((atn2)/(2*PI))));


az=tc*toGRAD;
if(az<0){az+=360;}
if(az>359){az=0;}
return az;
}

новые 2 режима

Как выглядят критерии “попадания” в заданную точку ?
Проверяется попадание текущего положения в некий квадрат или радиус ??

да, но если малина где-то 50мс задержит, это будет приемлимо для меня.

С малиной всё не просто…, пытаться запустить на ней перекодировку - идея тупиковая… не хватит мощщи.
Лучший результат, достигнутый мной, не влезая в дебри ОС, ~300 мс задержки при 720p, и это при использовании штатной камеры (считай вся кодировка аппаратная) а все остальные варианты будут в разы хуже, практически не приемлимы…

А, то есть wi-fi broadcast - это отдельный термин.

Автор этой работы двигается в правильном направлении, а именно - “копает” сам линукс в сторону оптимизации задачи под цели FPV…
Но пока что (ИМХО) результат выглядит как “полумеры”, что в принципе не отрицает и сам автор…

ещё одна бредовая мысль - с акселя взять центростремительное ускорение? оно ж вдоль осей…

Везде шумы шумы и шумы, я не знаю как с ними бороться, а начинаешь бороться, все быстродействие насмАрку…

в качестве пропорции самую точную часть показаний - угловую скорость,

Ну это скорей к ПИД-у, как таковому, отношения не имеет, это просто замена одной величины регулирования на другую…,
, если я правильно понял идею - конечно, если углы из уг.скоростей не считать, то быстродействие регулятора растет.

вроде как из ТАУ вспоминаю

Коллега…

поэтому 20 процентов сигнала задания я подмешиваю в дифференциальную составляющую.

Мне ТАУ вспомнить в два раза сложнее )), но попробую тоже высказаться на этот счет - классический ПИД самодостаточен, все желаемые характеристики типа “скорости реакции” и т.п. достигаются тупо коэффициентами, а всякого рода “подмешивания” это скорей самообман… (ИМХО), т.е. у нас есть классическая “уставка” и “данные сенсора”, ладно, если подмешивать “нечто - третье”, а так - ходьба по кругу…
(возможно мой тезис можно было бы математически расписать, но уже слабо…)))

первый раз сталкиваюсь c оператором caps

Я тут пол интернета перечитал на эту тему)))… в основном все примеры от авторов статей выглядят по разному, тут еще разные версии самого стриммера, разные платформы,…
Вещь похоже мощная и гибкая но разобраться в этой каше очень сложно…
По факту, у меня щас передача пакетов идет, а на приеме потока что то не клеится (mplayer отказывается понимать входящий формат)…