flybrain. передатчик + приемник + автопилот. powered by stm32
Кстати, именно описание этих преимуществ я и жду.
Так ведь AlexSneg на предыдущей странице именно эти преимущества и описал, я просто перевел технические термины на понятный простым людям язык 😃
- Cortex - не дорогой
- Меньше проводов и модулей - проще установить
- Не нужны специальные приспособления для обслуживания - проще пользоваться
- Мощнее контроллер и больше памяти для ПО - приятнее и безопаснее летать
Мне лично, мотивация понятна, осталось только доделать, а я не сомневаюсь, что автор сможет это 😃
Мне лично, мотивация понятна, осталось только доделать, а я не сомневаюсь, что автор сможет это
Да я ж не против. Пусть занимаеццо. Главное - чтобы не приумножилось количество жертв-морководов, клюнувших на красивые и непонятные рассказы о светлом будущем.
Надеюсь это не тот случай.
Случай неизменно всегда именно тот! Так было, так есть и так будет 😃
Слава, деньги, женщины! Плох тот солдат, который не мечтает стать генералом (с) Суворов
Быть непревзойденным в чем то - не стыдно… лишь бы другим не во вред.
STM32- отличный процессор.
Одноплатный вариант- единственно разумный на сегодняшний день.
Автор сможет… Уже летает.
//-------
А давайте теперь обсудим собственно проект… (Его функциональность, алгоритмы, инженерные находки итп.).
Посоветовал бы увеличить масштаб отрисовки, все, шрифты, линии и т.д. Ну и расширить границы, до боков кадра ещё куча места 😃
поддерживаю, удобно когда по краям раскидано, нету скученности, в данном случае неудобно. опять же на вкус и цвет…
а если еще будет счастье что бы самому раскидать по экрану данные то вообще будет гуууудддддд.
Да, похоже ты прав, я тоже вчера к этому выводу пришел. Хотя попробовал ее пальчиком вчера потаскать, гнется плохо, но других причин явно нет. Буду ставить распорку сверху и крепить дополнительно. В выходные проверим в Бурцево, если погода не подведет.
для однозначности надо было направить камеру, чтоб было видно чуток фюзеляжа.
А давайте теперь обсудим собственно проект
Я только за. Разумные идеи я всегда одобряю, если только по сложности это не выглядит полетом в другую галактику.
поддерживаю, удобно когда по краям раскидано
Разрешение сейчас искусственно зажато до 256Х192.
родилось оно не случайно, а из нежелания на тот момент разгребать четный-нечетный полукадр. А так же по причине неясности сколь еще я скушаю оперативки. Чисто программным апгрейдом я могу увеличить разрешение по горизонтали в 1,5 раза и в 2 раза по вертикали. Увеличение по горизонтали более чем в 1,5 раза возможно, но не перебор ли это?
Кроме того надо принять во внимание следующее, что развертка белого буфера и черного идет аппаратно и одновременно. То есть их нужно иметь всегда 2 выделенных.
Считаем сколько памяти это употребляет: 256 / 8 * 192 = 6144 байт на 1 буфер. Их 2, соответственно сейчас расход 13кб. Если мы разгоним разрешение до 512х384, то израсходуем на это дело в целом 49152 байт. Мне кажется это до фига.
Думаю, что правильным вариантом будет на половину увеличить разрешение по горизонтали, скажем до 336 и немного по вертикали, так чтобы не замарачиваться с полукадрами. NTSC у нас 480 по вертикали, вот можно поднять до 220 я считаю. Тогда памяти на 2 буфера будет надо 18480 байт. Вполне приемлемо. В этом случае можно будет выделить еще 18480, чтобы отвязаться окончательно от обратного хода КСИ и рисовать в экран вообще в любое время. Тогда и тетрис можно на экран забабахать, пока самолет сам домой летит.
Интересно, сколько Олег себе поставил разрешение?
а если еще будет счастье что бы самому раскидать по экрану данные то вообще будет гуууудддддд.
Будет, только скорее всего не для горизонта. Его как-бэ приходится фиксировать в предсказуемых границах для облегчения графических процедур. Все остальные надписи и шкалы можно в принципе двигать. Они у меня и сейчас фактически просто дефайнами определяются, где начало области отсчета для отрисовки. Если вывести в константы, то оно и сейчас можно будет двигать, только опять же не налезая на горизонт. Он отрисовывается самым последним и все равно затрет под собой все, что туда залезает.
чтоб было видно чуток фюзеляжа.
Опа, вот в точку. А ведь точно, так сразу все понятно станет. Спасибо за наводку. Сделаем, проверим.
Если на пепелаце стоит 2 камеры.? Одна ходовая другая для записи hd(гоупроха) обе в PALe . Переключаюсь между ними через видео свитч. Если ходовая поддерживает pal и ntsc и может между режимами переключаться достаточно шустро то гоупроха изначально ставиться в какой то режим. Не будет здесь гемора если вы в ntsc переведете?
PAL и NTSC с точки зрения ОСД сейчас ничем не отличаются. Оба работают без проблем. Единственное, что нужно - центровку для картинки подбирать какую-то среднюю. Сейчас это делается через консоль коэффициентами. Можно влево-вправо, вверх вниз подвигать картинку в разумных пределах.
Вчера проводил очередные испытания. Проверялись доработанные алгоритмы по крену. По результатам испытаний видно, что все получилось. Повороты плавные и оно само вычисляет до куда максимальные крены давать в зависимости от текущей ситуации по высоте, скорости разворота и удаления от цели. Максимумы конечно задаются, чтобы оно не выходило за край, но до максимумов дело не доходит. В принципе на видео видно как оно работает рулями.
Также чуть интенсивней заставил сбрасывать высоту. В принципе работает на стадии удержания курса.
На этой неделе доведу дальние виражные развороты, чтобы не переруливало и чуть резче скорость разворота сбрасывало при приближении к нужному курсу и подружу левый и правый виражный развороты с одновременным набором и сбросом высоты. Еще раз испытаю по мере готовности.
Комментирую видео.
Ветер был устойчивый 6-7м/с параллельно взлетке.
1:05 - взлет
4:50 - отлет на 700м и автовозврат
6:40 - еще на 700 в сторону и автовозврат. В принципе видно как оно развернулось и держит курс. В принципе, вполне достойно. Периодически снижает высоту. Сейчас коридор высотный возле дома установлен на 50-60м
08:17 - Начал тестировать автоматический полет миссии. Мозголет перебирает КТ автоматически. Я не участвую.
08:46 - КТ0 достигнута, выбрана КТ1
09:15 - КТ1 достигнута, выбрана КТ2
09:30 - КТ2 достигнута, выбран возврат на базу
09:55 - база достигнута. Мозголет оставлен на базе. Летал и колбасился сам пока мы ходили в кусты доставали обломки яка-52 12кг, который мужики только-что раздолбали при посадке. На ролике он в начале иногда в кадр еще целым попадает 😦
12:30 - посадка, чуть в себя любимого не залетел, пришлось отпрыгивать. Ёёёё, ну какой-же кайф на стабе садиться!
Итак. Цели испытаний достигнуты. Делаем правки нед ошибками на этой неделе и снова в небо по готовности.
Крепление камеры не менял, хотя все винты протянул. В результате есть отрезки вообще без тряски. Значит все-таки камера трясется.
Только что заметил, гугл, зараза, времена исказил.
вообщем временные отсечки для просмотра вот такие
01:30 - взлет
06:40 - 700м, возврат
09:05 - еще 700м, возврат
11:20 - старт на КТ0
12:04 - старт на КТ1
12:45 - старт на КТ2
13:00 - RTH
13:37 - окончание миссии, вернулся на базу
17:11 - посадка
OSD- фликует, лечится?
В ИМУ крен после длительных поворотов неточен. Моя реализация DCM так работала при неточном расчете центробежки (вместо реальной линейной скорости на первых порах считал по фиксированной средней).
Повороты плавные и оно само вычисляет до куда максимальные крены давать в зависимости от текущей ситуации по высоте, скорости разворота и удаления от цели.
Хотелось бы оценить преимущества перед ПИД-ами… но без подробного описания алгоритма, формул или хотя-бы подробной постановки задачи это сложно сделать. Может есть графики логов, на которых можно оценить переходные характеристики, например:
курс- целевой/текущий/ошибка,
крен- целевой/текущий/ошибка.
OSD- фликует, лечится?
Да, еще не лечил. Надо пооптимизить отрисовку, чтобы не так в лоб. Сейчас вылезает за пределы кадрового имульса. Навигатор отлажу, займусь этим делом.
В ИМУ крен после длительных поворотов неточен
Да, я в этом тесте проверял физическую модель расчета критериев (мне нужно в реале оценить как они работают, прежде чем их применять), оно сейчас чисто на свободном ходе тормозит. Сейчас в логах можно будет посмотреть реальные временные характеристики выхода из виражей. Я проанализирую и сделаю динамические демпферы. Это задача для следующих тестов.
Может есть графики логов, на которых можно оценить переходные характеристики
Раскрывать свои алгоритмы я сейчас не буду.
Вот лог, там все есть, можно посмотреть и построить графики если хочешь.
Надо же уже 27-ой полет!
В ИМУ крен после длительных поворотов неточен Да, я в этом тесте проверял физическую модель расчета критериев (мне нужно в реале оценить как они работают, прежде чем их применять), оно сейчас чисто на свободном ходе тормозит.
Т.е. сейчас коррекции центростремительного ускореня нет?
Вот лог, там все есть,
А “сырой” аксель можешь выложить в логи?
Т.е. сейчас коррекции центростремительного ускореня нет?
Я может неточно выразился. Отвечал на вопрос по рулению, а не по IMU. Сорри.
В IMU крутится Кальман, ему не надо специально ничего компенсировать, если все правильно настроить, оно работает без костылей. Это относится и к центробежке. При длинном развороте - да, возникает временная ошибка, но она ограничена моими настройками и более чем некоторая величина превысить не может, вот хоть ты кругами облетайся. В том числе это плата за виброустойчивость. Матрицы подобраны так, чтобы гарантировано иметь сходимость, пусть даже за счет допущения небольших временных неточностей. Кроме того сейчас компас откалиброван как попало, можно даже сказать совсем никак. На видео может это не сильно заметно, но если платку провернуть вокруг своей оси ролл за счет кривого компаса может показывать 0 на север и +3 на юг, затем по мере поворота опять в 0 приходит. Это четко видно когда я лечу к лесу оно ровно показывает, а когда от леса к взлетке, его слегка уводит. Надо бы конечно заново и гиру и маг перекалибровать, но лень мне этим заниматься, потому как я конфиги время от времени переписываю в дефолт и калибровка сбрасывается. А заниматься этим в поле нет никакого желания, сейчас есть гораздо более важные задачи.
А “сырой” аксель можешь выложить в логи?
С полета никак, у меня флешка 2мега, а аксель фигачит с частотой под 100 герц(если память не изменяет)
его можно спихнуть только в USB, но usb в полете нет, сам понимаешь.
В IMU крутится Кальман, ему не надо специально ничего компенсировать, если все правильно настроить, оно работает без костылей. Это относится и к центробежке. При длинном развороте - да, возникает временная ошибка, но она ограничена моими настройками и более чем некоторая величина превысить не может, вот хоть ты кругами облетайся. В том числе это плата за виброустойчивость. Матрицы подобраны так, чтобы гарантировано иметь сходимость, пусть даже за счет допущения небольших временных неточностей.
мда… Я с калманом не дружу, для меня это волшебство… Не понимаю я, от куда берётся достоверная информация о векторе G, если он длительное время смещён за счёт центростремительного ускорения, и как внести поправки, если нет данных для вычисления базиса? Где можно по русски и доходчиво про калмана почитать?
А вообще, впечатлён результатами, за столь короткое время. Поздравляю!
А по-моему все супер!!!
Респект разрабу!
давно читаю тему (с самого основания…) - скептикам ПРИВЕТ!!!
сам не прогер, поэтому судить не могу…
Но Алекс - просто молодец…
Чуствую сейчас кто-то подтянется критиковать…
Чуствую сейчас кто-то подтянется критиковать…
С чего? Всё путем, разве что центробежку надо таки учитывать. Если дать модели кругами полетать над базой, то за минуту без коррекции любого калмана сшибет.
Ну и ПИДЫ. Чем не угодили? Весь мир их уже лет 50 как их использует везде, и пока альтернатив особых нету. Или я ошибаюсь?
С Кальманом на самом деле все очень просто, если реально вникнуть. Никаких шаманств там нет. А с кватернионами, как оказалось, еще проще чем с эйлером. Я вчера глянул в свой код, чтобы освежить в памяти, что я там делал. Так вот на вопрос об учете ЦСУ, ответ простой.
У меня стоит некоторый зазор достоверности вектора G. Если он по модулю вылезает за заданные рамки, достоверность его снижается при корректировке кватерниона, а достоверность мага нарастает. Соответственно, отсюда все результаты. Компас не калиброван + есть лаг по корректировке акселем в недостоверной зоне. Но расти ошибка будет только до пределов пока аксель совсем не исключается из цепочки корректировки. Ну собственно это мы и видим. До определенной ошибки оно растет, а дальше хоть уповорачивайся. Но в этот момент на передний план выходит компас и он должен показывать правильно. Ну короче, все эти эффекты, это вопрос испытаний и более качественных подборов границ вариативности, шумов и достоверности. Можно, наверное, и точнее будет подобрать. Но сейчас я не хочу в это дело влезать. Практика показывает, что кривизна геометрии самой модели + небольшие порывы ветра сносят и качают горизонт сильнее, чем любые развороты с ЦСУ.
Если дать модели кругами полетать над базой, то за минуту без коррекции любого калмана сшибет.
Нет, аксель отбросится, компас его задавит. Кроме того достаточно выпрямить модель и тут же аксель включится и снимет дельту по крену.
Единственное, чего надо бы добавить в мою модель горизонта это критерии вранья компаса. В принципе понятно как это реализовать, но мне реально лень сейчас это делать. Для нормальных полетов, того, что есть по горизонту, за глаза хватает.
Ну и ПИДЫ. Чем не угодили?
Просто я хочу попробовать что-то другое. Пиды всегда можно прикрутить, этот вариант я держу на про запас. В больших самолетах и веса больше, и крены там маленькие. Медленное нарастание I особо не достает. А на модели, от нее либо толка нет, либо за реакцией модели не успевает. Сегодня ветер такой, завтра сякой. принятие решения должно быть быстрее. Получится у меня или нет что-то хорошее, я пока не знаю. Но в конце концов, это мой проект и у меня есть возможность потратить немного усилий для выяснения своих заблуждений. Никто не может мне запретить это дело. Ты кстати тогда был прав, у меня алгоритм if() else уже за сотню кейсов переваливает. Но ведь маневрирует! 😃
Сообщение от alex-ber Чуствую сейчас кто-то подтянется критиковать… С чего?
Тимофей, эта фраза никоим случаем к тебе не относилась… К кому она была обращена и так знает…
Алекс, а на видео какой из вариантов твоего АП: с подключением в обычному РС каналу или с твоим приемником-передатчиком!
Спасибо!
У меня стоит некоторый зазор достоверности вектора G. Если он по модулю вылезает за заданные рамки, достоверность его снижается при корректировке кватерниона, а достоверность мага нарастает. Соответственно, отсюда все результаты. Компас не калиброван + есть лаг по корректировке акселем в недостоверной зоне. Но расти ошибка будет только до пределов пока аксель совсем не исключается из цепочки корректировки. Ну собственно это мы и видим. До определенной ошибки оно растет, а дальше хоть уповорачивайся. Но в этот момент на передний план выходит компас и он должен показывать правильно.
У меня похожий алгоритм, только полной отсечки коррекции нет:
/* определяем длину дуги между G и ИНС */
qAcc.normalize();
float delta = inner_product(qIMU, qAcc);
if (abs(1 - AccMag) < 0.05f) {
q = (qIMU * (1.0f-omega))+(qAcc*delta*omega);
/* устраняем вырождение кватерниона */
if ((q.w!=0)||(q.x!=0)||(q.y!=0)||(q.z!=0)) qIMU = q;
}
точнее она будет при длине дуги равной Пи.