Создание собственной системы стабилизации
показываю код арду один раз, и пошел я писать собственную прошивку (
а для непосвященных как это можно использовать?
а, кажись понял - это деление матриц из опенпилота которое сжирает производительность
нет ты не понял - это те же грабли что и в опенпилоте пикссе и ещё чёрт знает где - короче это неправильно!
S-1 = 1/определитель матрицы * ST (транспонированную матрицу S) - вот это так сожрёт производительность, что надо задумываться брать пачку F7
вот что в этом деле будет жрать немерено
а уже транспонирование - это легко столбцы со строками местами поменять…
искал почему инерциалка не рисует коробочку при коротких перемещениях…
путь явно занижен…
и кажись нашел очень большие грабли.
Еще раз спасибо Дмитрию Чернову за идею с коробочкой.
делаем такой эксперимент.
- кладем полетник на большую горизонтальную плоскость
- включаем отображение графика питча
- касаясь дном полетника ровной плоскости водим вперед - назад с размахом метр с периодом в секунду.
я сделал самый минимальный подтяг гироскопа к акселю какой позволяет арду из параметров
и увидел о ужас!
горизонт гуляет отседова искривление эрч фрэйма и ошибки калькуляции
и отсюда же просадка некоторых аппаратов в быстрых пролетах
что думаете товарищи?
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
Лучше привязать к модулю трехмерного вектора ускорения.
Лучше привязать к модулю трехмерного вектора ускорения.
хорошо бы.
github.com/kozinalexey/…/AP_AHRS_DCM.cpp#L678
поменял на единичку, подправил типы - загрузил проверил на апм - ничего не изменилось хотя похоже было на то что нужно
varInnov -это матрица S
уточню - это вообще какая-то хрень
поменял на единичку, подправил типы - загрузил проверил на апм - ничего не изменилось хотя похоже было на то что нужно
это тут не причём
надо учитывать горизонтальные ускорения при расчете надира к которому тянется горизонт ахрс
отдаём доверие гирам (угол который получился) берём за основу вычисления горизонтальных ускорений, вычитаем их из расчёта углов с акселя - задница конечно, но на столе посмотреть можно, и так вот кучу костылей вставляешь в чужее ПО ещё и виноватым останешся (
а вообще надо корректировать аксель по кривому компасу…
это тут не причём
почемуж похоже
float tilt = pythagorous2(GA_e.x, GA_e.y); - это длина вектора ускорений в мсс (хз почему тилт )
float theta = atan2f(GA_b[besti].y, GA_b[besti].x); – наверное это угол приложения ускорений относительно переда рамы
Vector3f GA_e2 = Vector3f(cosf(theta)*tilt, sinf(theta)*tilt, GA_e.z); - тут затрудняюсь
error = GA_b[besti] % GA_e2; – операция хор всегда вводила меня в ступор
но есть дока чего они хотели получить с пунктами и подпунктами …googlecode.com/…/RollPitchDriftCompensation.pdf
Написал таки )) Для того чтобы самостоятельно погонять мою демку нужно:
- Авиасимулятор XPlane 10 (или 9й), скачиваем на оф.сайте демоверсию www.x-plane.com/downloads/landing/
- Плату STM32Discovery, либо F4BY.
- Установить интерпретатор Python 2.7 www.python.org/downloads/release/python-2710/
- Скачать и установить pyserial 2.7 pypi.python.org/pypi/pyserial/
- Скачать и установить vpython 2.7 vpython.org/contents/download_windows.html
- Загрузить в плату прошивку.
- Подключаем в порт GPS (PD8-TX,PD9-RX) через адаптер USART-USB.
- Подключаем терминал через USB , либо адаптер USART-USB через порт телеметрии (PD5-TX,PD6-RX) . Но если подключать визуализацию и терминал будем через USART, то USB подключать нельзя (особенность драйвера USB-).
Порядок запуска: - Запускаем и настраиваем XPlane так же как для HIL Ardupilot github.com/…/X-PLANE-TUTORIAL:-X-Plane-v9.70-with-….
- Подключаем контроллер.
- Правим скрипт «прокладки» AP2Sim.py, прописываем имя компорта, куда подключен GPS- порт контроллера. Запускаем «прокладку», в окне будет показано количество принятых за секунду пакетов XPlane и АП. В ту же директорию положим файл настроек контроллера config.rai. Надо сбросить контроллер для загрузки настроек из файла.
- Исправляем скрипт визуализатора MinIMU-9-test.py, прописываем имя компорта, куда подключен порт терминала контроллера. Запускаем скрипт.
- Сигнал радиоуправления подключается через SPPM либо SBUS как к F4BY . SPPM: перемычка PC6-PC8, сигнал SPPM – PC7. SBUS: перемычка PC9-PC8, инвертированный сигнал SBUS – PC7.
раскачка есть следствие малой и нестабильной частоты опроса “датчиков”, а любой цифровой ПИД-регулятор чрезвычайно критичен к этим цифрам. железки худо-бедно работают на сотнях герц, дорогущие коммерческие модельные IMU уже на килогерцах, а у вас “обычно 25-35”.
Всё верно, это называется устойчивость ПИД по фазе, но в данном случае имеет решающий фактор это скорость ЛА и увеличившаяся эффективность рулей.
Возвращаясь к истокам беседы, мне вот интересно, как в симуляторе отладить с нуля писаную ИНС?
Собственно об этом я и писал, это вполне реально. Можно вообще имитировать датчики АП в адуине используя библиотеки связи с симом, котрые используют симмеры для иммитаций кабин.
это вполне реально.
Чтото я очень сомневаюсь, ктонить уже так успешно делал? Отладить алгоритмы стабилизации, проверить на работоспособность хитрые актуаторы - да, реально.
Чтото я очень сомневаюсь, ктонить уже так успешно делал?
Насчет успешно пока стесняюсь говорить (до испытаний на природе), ну и не “с нуля”, а так см. моё видео. Вообще скажу за себя, “с нуля” лучше конечно в руках покрутить, мотивирует (когда получается) продолжать )). Но вот когда нужно отлаживать алгоритмы в движении связку сима и полетника переоценить сложно.
Кстати, на мой взгляд ахрс и инс не обязательно должны быть единым целым
Мне тоже так кажется, я уже давно отказался от подмешивания компаса в общий вектор положения, теоретически алгоритм AHRS конечно безупречный, но на практике - компас должен быть идеально откалиброван и достаточно точен, а это далеко не так…
Hdop штука загадочная и весьма абстрактная.
Точно-, этот показатель программно рассчитывается в внутри GPS чипа, т.е. сильно зависит от самой прошивки и наглости разработчиков, доверять ему надо с осторожностью…
Написал таки )) Для того чтобы самостоятельно погонять мою демку нужно:
иксплан 9 запустил, настройки как с арду, рабочие
скрипт запустил (пока контроллер не заливал и не подключил к юсб)
скрипт видна консоль в которой вывел мой айпи и пишет что ждет иксплан на порту 49005 и больше ничего
проверил порты
C:\Users\kozin>netstat -a -b
Активные подключения
Имя Локальный адрес Внешний адрес Состояние
UDP 0.0.0.0:48901 *😗 [X-Plane.exe]
UDP 0.0.0.0:49000 *😗 [X-Plane.exe]
UDP 192.168.1.254:49005 *😗 [python.exe]
скрипт видна консоль в которой вывел мой айпи и пишет что ждет иксплан на порту 49005 и больше ничего
Всё правильно, теперь в иксплане пропиши тот ИП, который скрипт показал, ну и порт передачи соответственно
Насчет успешно пока стесняюсь говорить
Замысел и цель понятны, а вот вопрос - в расчетах положения на экране должна учитываться математическая модель самого “испытуемого” аппарата, его физические характеристики, есть ли это ? ,
иначе мы будем видеть как летит не сам аппарат, а как его ИНС…
Всё правильно, теперь в иксплане пропиши тот ИП, который скрипт показал, ну и порт передачи соответственно
так оно и есть, перезагрузился… эффекта нет
так оно и есть, перезагрузился… эффекта нет
Упс… мой косяк (или винды), не может принять на свой же ИП (((( у мну скрипт и иксплан на разных компах… надо локалхост прописывать, щас поправлю… а так хотелось уменьшить кол-во ручных настроек
да все равно компорт настраивать
Вот, указал локалхост, надо компорт поправить. Если иксплан удаленный надо очистить строку host =“”
Вот ведь, хотел ещё автоматом компорт искать (((
Придумал! Всё равно сделаю, при инициализации буду ловить на локалхосте и ип, кто первый поймает, тот останется, другой закроется)))
Ну это сразу с автокомом )
RusINSF4Disc2Sim.hex льем через юсб, через бут и мишен планер?
RusINSF4Disc2Sim.hex льем через юсб, через бут и мишен планер?
Через встроеный загрузчик СТМ, ардушный при этом затрет, так что нужно сохранить его
через dfusedemo ? заливается также как и бут?