flybrain. передатчик + приемник + автопилот. powered by stm32
Только из компаса, то, что ты в данный момент с компаса снимаешь. Ну ты боишься, что из за кривизны и нелинейности самого компаса будешь каждый раз разную ошибку на направлении севера иметь? Ну тогда только, если диаграмму компаса четко к шарообразному варианту приводить, как это в ДШ ST рекомендует. В принципе процедура у них описана, но больно уж геморная
Ну ты боишься, что из за кривизны и нелинейности самого компаса будешь каждый раз разную ошибку на направлении севера иметь?
Лична я не боюсь. Мой яв всегда показывает чотко. Главное хорошо откалибровать и локальное магнитное поле учесть.
Сейчас как раз удержание направления для квадрика доделал. Вечером испытаю.
Посмотри в любой открытый код любого автопилота. Конечный алгоритм стабилизации всегда опирается на углы Эйлера при оценке положения тела. Так что это не я придумал.
Дык о том и речь- что надо скопировать, а потом - самому подумать. 😃 Если “все так начали делать уже 3 года как” то это не значит что так надо делать, просто так проще…
А если начинать с первоисточников, то есть с с Шмыглевского с Бранцем- то такая мысль и в голову не придет… Изначально БИНС разрабатывались для стабилизации космических аппаратов…
Дринкер уже все объяснил…
Насчет вращения в канале крена при вертикальном положении Х. Дринкер прав, это не проблема, по крайней мере не проблема ИНС, это особенность отображения в углах Эйлера. У себя сменил знак атан2 при переходе в Эйлер вокруг Z, и всё - более не крутится, полная идентичность реальности. Предполагаю что это зависит от порядка вращений в программе-индикаторе, типа дуги крена и курса компенсируют друг друга, хотя имеют место быть. Но если удерживать поворот точно в плоскости XZ, то смена Эйлеров происходит скачком.
то смена Эйлеров происходит скачком
Есть там зона неопределенности Roll, с математикой спорить бесполезно.
Есть там зона неопределенности Roll, с математикой спорить бесполезно.
Я не спорю с математикой, я писал что дуги имеют место быть. Весь вопрос с величиной зоны неопределенности.
Весь вопрос с величиной зоны неопределенности
Алгоритм управления самолетом должен уметь работать внутри такой зоны. Вопрос в том как его этому научить? Каждый разработчик автопилота решает эту проблему индивидуально. Как это в некоторых алгоритмах происходит, я прекрасно вижу в их коде. 😃 А некоторые уже попробовали на практике.
Небольшой отчетец по проблеме OSD.
В принципе я научился делать развертку буфера памяти по весь экран используя аппаратный DMA через SPI порт. Сейчас осталось решить только одну проблему. В условиях многозадачности по прерываниям, когда около 5 задач одновременно хотят быть обработанными возникает задержка неопределенная в пределах 3 мкс на вход в процедуру обработки строчного импульса. Это создает эффект сдвига начала развертки. Если отключить все прерывания и оставить только видео развертку, то все ОК, на экране имеем четкий прямоугольник развертки. SPI запустил на 6Мгц, развертка будет 280 X 240 пикселов. По вертикали удобно получилось использовать одну и туже строку от четного и нечетного полукадра.
Сейчас осталось только решить проблему таймингов в условиях множественных прерываний. Жалко, что в STM не додумались сделать фичу аппаратного старта DMA канала по переполнению таймера. Тогда бы вообще можно было чисто аппаратно развертку организовать, но такого нет. Зато есть аппаратный старт таймера по изменению фронта на внешнем пине. В принципе этого должно быть достаточно, главное сделать правильный абсолютный замер от начала строчного импульса до софтового старта DMA. Это как бы теория. На практике буду бороться с этим делом на следующей неделе.
Ответ один, максимально высоко поднять приоретет прерывания видео. У кортекса прерывания прерываний )) очень жесткие по времени. Насколько я понимаю код в обработчике компактный и невариативный, если так, то на остальных обработчиках это не скажется.
У кортекса прерывания прерываний
Я знаю, и вроде выставил самый высокий на видео синхру. Но результат чего-то не очень. Буду еще дебагить этот момент, мог я накосячить с приоритетами, либо стандартная библа глючная. Запишу логи вызовов прерываний в риал тайме, проанализирую. Займусь этой темой завтра, сейчас рано выводы делать.
Проблема я так понию точно привязанный к ССИ программный запуск СПИ, сам СПИ в ведущем режиме? Тут можно посоветовать использовать СПИ в ведомом режиме, с внешним поточечным тактом на SCK от таймера, запускаемым от ССИ. Нужно только снаружи проца соеденить синхру СПИ и выход меандра от таймера. Работать будет так:
- проц, в обработчике прерывания об окончании ПДП, останавливает таймер и настраивает ПДП для вывода очероедной строки;
- после прихода ССИ с внешней ноги запускается таймер и дает такт на синхру СПИ.
То есть, цепочка “ССИ -> запуск вывода точек -> подгрузка очередной порции точек в СПИ” чисто аппаратная.
Я думал у вас изначально примерно такая схема закладывалась.
Тут можно посоветовать использовать СПИ в ведомом режиме,
Ну вот где ты раньше был, когда я плату разводил а? В то время я не думал, что может такая странная проблема вылезти. Мне внутри прерывания только DMA стартовать нужно, не более того. Ну пару проверок еще, чтобы начало кадра детектировать. Реально сейчас я вижу на экране сдвиг строк на 1,5 - 2 пиксела. И это явно из за множественности и вложенности прерываний. Большие сдвиги я вчера вычистил, а вот эту мелочь не могу никак. Главное я врубиться не могу, откуда такая задержка. Прерывание от синхры идет самым высоким приоритетом, и я вижу в дебаггере, что проц реально кладет на все текущие задачи и прерывания и стартует прерывание от синхры отрабатывать. Если выключаю все прерывания, а оставляю только видео синхру, то сдвига пикселов нет - на экране чистый, идеальный прямоугольник от развертки. (Кстати зазора при переходе от одного байта к другому нет в отличие от атмеги. То есть, имеем засветку 100% без разрыва как по вертикали так и по горизонтали.) Ну не должно оно так долго переходить на прерывания, что разница в 2 пиксела получается, не могу в это поверить. Надеюсь, что сидит где-то мой косяк.
Твою идею я обязательно попробую реализовать. Мысль очень здравая. Ща прикину как там таймеры каскадом засинхронизировать и какие пины у меня свободны по схеме. Никогда не пускал SPI в слэйве, сейчас доку открою. Мне кажется синхры там недостаточно, надо еще NSS сигнал дергать.
хм… Проект - амбициозен. Интересно наблюдать за тем, что сам, год назад, решал такие проблемы). Автор - не здавайся, и у тебя получится!
Ну вот где ты раньше был, когда я плату разводил а?
)) ну дык, я на твою ветку два дня назад наткнулся.
Мне внутри прерывания только DMA стартовать нужно, не более того.
www.gaw.ru/html.cgi/txt/doc/micros/…/2_4_5_2.htm
Вот в чем дело, прерывание прерывания занимает от 7 до 18 циклов, т.е. дрожание фазы в 11 циклов, при 166МГц это ±6.6е-8 сек, как раз примерно разбег в 2.5 точки. Это фича железная, в лоб её не обойти.
Если всё же есть желание удалять аппендицит через нижнее отверстие организма, то можно сделать так:
- на предыдущем ССИ пускаем таймер на длину строки;
- по перегрузу таймера запускается обработчик, в котором есть петля ожидания ССИ следующей строки;
- на конец строки ±6.6е-8 сек гарантировано будет вызвано твоё прерывание с ожиданием ССИ, и по приходу запустит ПДП.
В итоге к приходу ССИ проц готов и код неопределенной длинны выполнятся не будет, но платим мы за это пустыми циклами в петле. Кста, в петле нужно сделать отсечку по времени в случае не прихода ССИ, иначе вся система зависнет в случае сбоя видео.
ps: посмотрел внимательно описание, высокоприоритетное прерывание должно начать обслуживаться гарантированно за 12 циклов , эта хз … Возможно арбитраж на шинах с другими ПДП виноват…
Если всё же есть желание удалять аппендицит через нижнее отверстие организма, то можно сделать так
Я еще раз проштудировал ДШ. Есть решение еще более элегантное.
Берем TIM8, оно у меня на схеме уже имеет вход, на который video sync уже заведен. Настраиваем его в мастер режим one-pulse mode.
Далее берем TIM2. У него есть 4-й канал (pin30), замыкаем его с SPI2_SCK (pin 29). Они рядом, это просто перемычку на плате посадить.
Теперь берем и внутри кристалла подтыкаем выход мастера TIM8 на вход триггера TIM2. TIM2 настраиваем в slave gated mode на входе, и PWM 0.5 на выходе 4-ого канала. TIM8 настраиваем на генерацию положительного импульса от первого восходящего фронта строчного импульса и задержкой в 4мкс(это отрегулируем) и окном в 50 мкс+некоторая дельта(подберем экспериментом). Внутри этого положительного окна будет каскадом запущен TIM2, который начнет генерацию меандра на SPI2_SCK. Количество битов и частоту можно будет вообще плавно регулировать чуть ли не по 10нс. На прерываниях по окончанию DMA останавливаем TIM2 и перезаряжаем DMA до следующего строчного видео импульса.
А в теории, если с точностью до бита подобрать окно для TIM2 можно даже DMA не перезаряжать на каждой строке, а тупо ждать процесса до конца полукадра. Оно само будет на следующем кадре продолжать автоматом буфер дальше выводить. И только вконце всего полукадра, опять включать прерывания от синхры и ловить начало кадра, чтобы DMA и таймеры перезарядить. УРА! УРА! И надо всего лиш две соседние ножки замкнуть, и MOSI с MISO перемкнуть, они тоже соседние. И мы реально можем получить почти 100% аппаратную развертку и только десяток раз прерываться на распознавания начала полукадра.
Блин, у меня у же свербит, до дома не дотерплю, хочу уже попробовать
хм… Проект - амбициозен.
А сколько их было?.. И где они щас?.. Вывод: Миром правит Тимофей!
А сколько их было?.. И где они щас?.. Вывод: Миром правит Тимофей!
Ну это “правление” - недолговечно. Этот сегмент активно развивается, люди он уже строят на ARM процессорах, а Тимофей (со всем уважением), к сожалению, застрял на авр. И я думаю, что пройдет еще немного времени, появится этих автопилотов с осд вкуче - тьма тьмущая, ну, и конечно, китайцы, как всегда сдемпингуют…
Ну это “правление” - недолговечно.
Ну как сказать…Делают-то оно конечно делают.
Но до коммерческих образцов чета не доходят.
Этот проект думаю еще пара лет ждет до первого реального полета.
Ибо пока идет разбирательство с радиолюбительскими штуками, а впереди сначала понимание алгоритмов управления ЛА, навигации, потом реализация и отладка.
Если конечно тупо не сп@#ить с готового проекта.
застрял на авр
Хватает и хорошо.
Это как у геймеров - бесконечная гонка за самым скоростным железом, хотя и так всё тянет.
Ну как сказать…Делают-то оно конечно делают.
Но до коммерческих образцов чета не доходят.
Потому что, это серъезная работа, и на коленке собрать получится, только, что-то отдаленно напоминающее)
Человек научился работать с гироскопом и уже, например, чувствует, что ему до закоченного проекта “рукой подать”. Тот самый Тимофей, свою систему дорабатывает и по сей день…
Хватает и хорошо.
Это как у геймеров - бесконечная гонка за самым скоростным железом, хотя и так всё тянет.
Возможно и так, ну, например, в осд - там надо быстрый проц, да вообще, есть много мест где нада быстрый проц, быстрее авр-ки…
Очень долго подбирал слова, как высказать свое отношение к этому проекту?.. Главный критерий- ни в коем случае не обидеть ТС своими соображениями…
Ну как сказать…
Лучший вариант!.. 😃
Искренне желаю ТС успехов! Но пока отписываюсь от темы…
Искренне желаю ТС успехов!
Присоеденяюсь! Главное, чтоб не остановился на полпути, потому что, будет казаться, что уже “все”, а это, только - полпути…
Этот проект думаю еще пара лет ждет до первого реального полета
Ты в меня не веришь просто. Обещаю, в первой версии все будет работать, летать, стабилизировать, возвращать на базу и иметь OSD информацию на экране телевизора в срок до 1 июля. Выполнение полетного задания по координатам пока не обещаю, эта фишка запланирована на самый конец работ.
Ибо пока идет разбирательство с радиолюбительскими штуками…
Не может один человек владеть всем спектром проблем и видеть с ходу их решение. Все равно что-то неизбежно изучается по ходу дела. Заинтересованные люди, которые разбираются в некоторых аспектах лучше, могут помогать опережающим советом, для этого я и веду эту тему достаточно подробно и бросать это дело пока не собираюсь. Я считаю что прогресс на лицо, и он существенный, учитывая, что кроме этого у меня есть еще основная работа, которой я на жизнь зарабатываю.
Если конечно тупо не сп@#ить с готового проекта.
Пока удается обойтись без копирования чужого кода. Чужой код я использую для изучения принципов решения аналогичных задач, а не для того, чтобы от туда что-то сп@#ить. Запретить мне изучать чужой опыт никто не может.
Тот самый Тимофей
А кто это, о ком речь?
Ты в меня не веришь просто. Обещаю, в первой версии все будет работать, летать, стабилизировать, возвращать на базу и иметь OSD информацию на экране телевизора в срок до 1 июля. Выполнение полетного задания по координатам пока не обещаю, эта фишка запланирована на самый конец работ.
Я в тебя верю. Записывай меня в первые тестеры.
А кто это, о ком речь?
Смаллтим
Записывай меня в первые тестеры
Только во вторые, первый (местный ) уже давно в очереди стоит. и уже даже самолет свой под мои тесты приготовил. Будем тестить на двух еропланах изначально: мой и его.
А тебе, если у тебя серьёзные намерения, советую озадачиться покупкой STMf405RGT6 или 407RGT6 ибо я не верю, что манна небесная от ST долго будет сыпаться нам на голову по 250-300 руб. Как только их маркетинг решит, что замануха сработала, ценники будут по 600 - 1000руб за кристалл.
Смаллтим
Ага, ну теперь понятно.
Ты в меня не веришь просто.
Верю. Но я реалист. И это всё уже проходил. И по времени примерно ориентируюсь.
для изучения принципов решения аналогичных задач
Это и есть сп@#$ть.
А вот если что-то будет оригинальное - то это, да.
сп@#$ть
Ну вот… пошли вольности толкования 😃
Оно, это самое, это когда без спроса, а когда исходники и формулы открыты это называется простым русским словом подсмотреть
Иначе, если по честному, все должны были бы отчислять дивиденды потомкам великих умов прошлых столетий за их выдающиеся… и неоценимый… 😉