Создание собственной системы стабилизации
И тут компас показывает, что его угол начинает медленно отклоняться от угла гироскопа
Я имел ввиду: брать разницу показаний текущего магнитного вектора и предыдущего за определенный период, получится, как бы, мгновенный признак (производная угла) изменения угловой ориентации в пространстве…
Потом из акселя также взять такую же производную, и вычесть одно из другого… по идее, в остатке будет именно производная линейного ускорение акселя, которую можно использовать…
(может это бред конечно, но пока похоже на правду 😃)
Кстати, при наличии подробной карты распределения магнитного поля в пространстве, ее можно использоавть, к примеру для точной навигации внутри помещения.
Ага, у меня в столовой, компас на расстоянии в полметра способен врать на 90 градусов (вот тебе и деревянный дом), я по незнанке откалибровал раз - такой унитаз получил - хорошо яблоня рядом была )))
производная линейного ускорение акселя
стесняюсь спросить, а что есть производная угла и производная ускорения, ну производная угла - угловая скорость, а ускорения?
Кстати, при наличии подробной карты распределения магнитного поля в пространстве, ее можно использоавть, к примеру для точной навигации внутри помещения. Но реализовать ее в любой точке Земли пока что утопия.
одним компасом - врядли, но если рассмотреть куб на вершинах которого стоят компасы, все они откалиброваны по расходам и офсету и нормализованы показания то при наличии хорошего алгоритма, вычитая показания одного из другого можно реализовать магнитное зрение 😃 по крайней мере вычислять внесенный источник магнитного поля, направление на источник, направление магнитных линий, силу и удаление
а если рассматривать подобный кластер из идеальных акселерометров то получаем гравитационное зрение, причем если акселерометры будут идеально малошумны то из наблюдений можно построить гравитационную модель солнечной системы (например луна создает весьма ошутимое влияние на гравитацию - вспоминаем про приливы и отливы)
отсюда мистика.
если вы откалибровали аксель в полнолуние … ))))
а ускорения?
😃 у меня получилось - “ускорение в степени 2”, почти как “интеграция интеграций” (простой вопрос, а ставит в тупик…)
почти как “интеграция интеграций”
дифференцирование - обратный процесс…
мысль то я понял, угол там и угол там - получаем угловые скорости, только шумный алгоритм, при условии, что угловые скорости и так известны…
тогда уж лучще угол акселя “доворачивать” до угла компаса и сравнивать…
тогда уж лучще угол акселя “доворачивать” до угла компаса и сравнивать…
о!
как раз моделирую в аксессе -экселе на полетных логах вычисление расхождения компаса и акселя
VxpY это интегратор ошибки velocity_X_positive to Y accel
R!gpsspdx = R!spd * Cos(R!gcrs / 180 * PI) жпс скорость по икс (на север)
R!gpsspdy = R!spd * Sin(R!gcrs / 180 * PI) жпс скорость по игрек (на восток)
Dim LAT As Double, ILAT As Double
LAT = R!LAT * LatLonScale нормализация масштаба широты к долготе
ILAT = R!la * LatLonScale в логе сделал параметр широта по инерциалке
If R!gpsspdx > 0 Then интегрирую влияние положительной скорости по икс на ошибку по иксу и игреку
R!VXPY = R!Lng - R!LN 'gps - inav lon влияние положительной скорости по икс на игрек аксель возможно имеет смысл множить на абс от скорости
R!vxpx = LAT - ILAT положительная скорость по икс на икс аксель (чтобы расчитать множитель акселя - gain и скомпенсировать ошибку калибровки)
Else
R!VXNY = R!Lng - R!LN 'gps - inav lon влияние отрицательной скорости по иксу (на юг) на игрек аксель
R!vxNx = LAT - ILAT
End If
If R!gpsspdy > 0 Then аналогично влияние скорости на восток на аксели
R!VyPY = R!Lng - R!LN 'gps - inav lon
R!vypx = LAT - ILAT
Else
R!VyNY = R!Lng - R!LN 'gps - inav lon
R!vyNx = LAT - ILAT
End If
в результате
нужен ли доворот компаса по часовой стрелке =(-vxpy+vxny+vypx-vynx > 0)
в этом случае в медленном цикле добавляем переменную на полградуса в секунду, впоследствии ее передаем в модуль компаса где прибавляем вместе с деклинейшеном преобразовав в радианы
тогда уж лучще угол акселя “доворачивать” до угла компаса
Вообще то даже и не думал, пока, как и что можно сделать, просто в голове давно крутилась мыслишка (где то в подсознании)) , я б сказал - пока что это концепт… и не факт что стОящий…
Щас сижу вот копаюсь с RPi, пытаюсь найти ему применение… пока что особо ничего в его “применимости” не радует… , правда нашёл способ выводить картинку OSD поверх видео (оказавается можно),
ещё вот покопаюсь и брошу наверно, займусь делом…
как раз моделирую в аксессе -экселе
Это очень интересно, Алексей, читаю вашу с Тимуром ветку на апмкоптере, но никак не пойму, откуда берете данные инерциалки?
Ещё вопрос к знатокам ТауЛабс (Серега SergDoc, вроде ты картинки показывал?), как выдать телеметрию во флексипорт? По USB всё работает нормально, в настройках платы выбираю FlexyPort->Telemetry, сохраняю, но не работает зараза((( Хотел три платки на карусельке покатать )))
Это очень интересно, Алексей, читаю вашу с Тимуром ветку на апмкоптере, но никак не пойму, откуда берете данные инерциалки?
для последующего анализа?
из датафлешь лога, нужные но отсутствующие логируемые параметры достаточно просто добавить, но как показала практика лучше добавлять свой тип данных а не дополнять существующий т.к. в случае модификации существующих не работают сторонние анализаторы логов
для последующего анализа?
Нет, я не это имел ввиду) Как контроллер эти данные считает\получает? Интеграцией акселя и без коррекции?
Нет, я не это имел ввиду) Как контроллер эти данные считает\получает? Интеграцией акселя и без коррекции?
весь функционал инерциалки заключен в класс AP_InertialNav github.com/diydrones/ardupilot/…/AP_InertialNav
он берет из класса ahrs готовые данные 3д вектор акселерометра повернутый в системе координат земли где ось икс - на север игрек на восток (в случае если компас не врет)
это тут github.com/diydrones/…/AP_InertialNav.cpp#L53
ну а дальше - дело техники посчитать из ускорений скорость и перемещение
ну а дальше - дело техники посчитать из ускорений скорость и перемещение
Понятно, там получается есть коррекция по ГНСС задержанных на полсекунды отсчетов ИНС. Так получается, что ты расхождения ИНС и ГНСС считаешь именно за эти полсекунды?
Понятно, там получается есть коррекция по ГНСС задержанных на полсекунды отсчетов ИНС. Так получается, что ты расхождения ИНС и ГНСС считаешь именно за эти полсекунды?
я пока точно не измерял задержки свойственные жпс модулям разных производителей, рассчитывал по логам, но данные противоречивые, нужен стенд. катапульта. включить запись акселераций и вычислить время между рывком и началом изменения координат.
т.к. нет точного времени задержки нет кусочка компенсации задержки жпс данных.
планирую в 100гц цикле сохранять в массив статистику акселя а по мере поступления данных жпс интегрировать кусочек истории за время задержки полученной экспериментально.
Махови проверял задержку времени получаемую от медиатека 3333 в сопоставлении с атомными часами, он утверждает что время почти не запаздывает, но это не говорит о том что не запаздывают координаты или курс
FlexyPort->Telemetry, сохраняю, но не работает зараза
х.з. может он вообще нерабочий, я хотел его проверить, но руки до него не дошли, там ещё косяков на параход, покатай опенпилот: github.com/openpilot/OpenPilot , HAL почти тот же самый… на flexi в опенпилоте я вешал gps - работал…
тут HAL rcopen.com/blogs/74247/19886
Махови проверял задержку времени получаемую от медиатека 3333 в сопоставлении с атомными часами, он утверждает что время почти не запаздывает, но это не говорит о том что не запаздывают координаты или курс
Алексей чем отличается протокол в 3329 и 3333 - беда в том что 3329 ловит 6 спутников но фикс и hdop есть, а 3333 - показывает у меня координаты и 12 спутников дома, но нет ни фикса, ни hdop, ни vdop нету (
Гироскоп нужно корректировать всегда, и даже если коррекция будет с плавающим весом, угадать когда понижать вес, гарантированно точно нельзя.
в приснопамятном CC когда-то существовала ветка с банальной коррекцией в пару строк: чем ближе длина вектора акселя к единице (ну или к нулю, после вычета G), тем больше его вес. и наоборот, чем больше текущее ускорение, тем меньше он “корректирует” гироскопы. если в полете наблюдалось совсем уж неприятное уплывание, то самолет достаточно было вывести в прямолинейный полет на пару секунд, а коптер ручками завесить.
дополнительно пытались ввести коррекцию по смещению акселя от центра масс аппарата (т. е. из акселя вычитались угловые ускорения). для полного счастья нужны были пара датчиков симметрично равноудаленных от ЦМ, но все уперлось в быстродействие. или в появление CC3D, не помню уже 😉
тем больше его вес. и наоборот, чем больше текущее ускорение, тем меньше он “корректирует”
там оно есть, но как-то странно - я не понял, там сделан ПИД-регулятор веса акселя, плюс тоже что и в арду - при арме вес акселя в 10 раз уменьшается…
- при арме вес акселя в 10 раз уменьшается…
наверно это как раз включается “полетный рабочий вес”, а на земле для ускорения процесса выравнивания горизонта вес завышенный… что логично.
в настройках платы выбираю FlexyPort->Telemetry
тут подумалось - сделай HAL из AQ32 борды, там вроде порты обозваны не майн и флекси, а усарт такой-то и их там больше…
тут подумалось - сделай HAL из AQ32 борды, там вроде порты обозваны не майн и флекси, а усарт такой-то и их там больше…
Серег у меня плата уже прошитая, Sparky на Ф3м, переделывать особо не зачем, я её брал под свое ПО. Просто хотел посмотреть какой там алго в плане реакции на боковые ускорения. Было бы интересно последнюю калманутую прошивку пиксхавка тоже покатать.
просто я думал ты делал на ф4бы, а aq32 похожа ну порты переписать только, я собирался хал сделать, но сейчас есть другие задачи…
Пиши, спрашивай, что смогу отвечу.
Александр, у меня вопрос: как в питоне можно <структуру> данных создать, аналогичную СИ ??
Замысел такой: передавать по указателю массив байт, по SPI, из структуры STM (Си) в аналогичную структуру RPi под питоном…
Короче - реализовать синхронизацию разнотипных переменных за одну транзакцию (?)…