Единый протокол
Добрый день. Я пишу диссертацию по теме инерциальной навигации, за счёт “сложных алгоритмов” добиваюсь чтобы показания на выходе с инерциальных mems датчиков были менее шумными и т.д. Вообщем это не суть, я просто описал чем занимаюсь, чтобы потом не было вопросов. И так результат моих двухгодичных исследований это плата stm32f4discovery на борту которой 4 инерциальных датчика и вот недавно допилил GPS. Ничего особенного, но всё это чудо спроектировано и запрограммированно в Matlab Simulink. На выходе платы по uart “стримится” 2 координаты (c gps), и 12 измерений с IMU (в будущем будет 3 угла и 2 координаты). Да это всё классно такие циферки бегут по экранчику, могу писать на карту, но хочется online и чтобы красиво. Начал хотеть красиво и параллельно искать, что так может. Вывод GCS. Но как я понял они принимают данные по какому-то протоколу. Оказался mavlink. А теперь внимание вопрос.
Из всего вышеописанного многие уже поняли, что програмить я особо не умею. Но мне нужно чтобы моя платка могла общаться с другими gcs системами. Внедрять mavlink протокол в свою плату задача для меня не посильная, сроки поджимают, а я могу потрать много времени на его реализацию. Я просто начал читать, а там стока букавок. Самое быстрое не спортивное решение это наверное, взять какой-то APM, и на него уже подавать значения с моей плата, а он уже будет это всё конвертировать в mavlink.
Как мою плату научить выдавать сигнала на понятном языке для всех gcs?
Хм… Вы точно этим занимаетесь? Или только изучаете почву? Как бы гугл по фразе Cortex Mavlink дает ссылки на нужные библиотеки и примеры использования. Вобще-то это несложная типовая задача Тот же ардупилот именно так и делает. Он как раз на кортексе. И, кстати, причем тут онлайн?
Я вот и написал, что сделано всё в Simulink, тоесть 80 процентов кода, написал Matlab 😒
Поскольку не особо умею программировать, вот и спрашиваю тех кто это знает или сталкивался с этим. Под online имею ввиду вывод телеметрии на экран ноутбука в время полёта/езды/проведения экспериментов.
Насчёт ссылок, читал. Понял что для интеграции данного протокола не обязательно его как бы программировать, а достаточно header библиотеку подцепить вот здесь это написано.
Я пишу диссертацию по теме инерциальной навигации. И так результат моих двухгодичных исследований.
Да… Не споро… Я так понял за оставшийся год нужно сделать “прорыв”? Тяжко будет. Я примерно на вашем же месте топчусь пол года. Но да меня никто не стегает. Сам для себя делаю.
12 измерений с IMU (в будущем будет 3 угла и 2 координаты).
Можете сказать, что именно измеряете? По моим подсчетам – 3 цифры угловых скоростей с Гироскопа и 3 цифры с ДЛУ. (еще максимум 3 цифры с электронного компаса)
Да это всё классно такие циферки бегут по экранчику, могу писать на карту, но хочется online и чтобы красиво.
Из всего вышеописанного многие уже поняли, что програмить я особо не умею. Но мне нужно чтобы моя платка могла общаться с другими gcs системами. Внедрять mavlink протокол в свою плату задача для меня не посильная, сроки поджимают, а я могу потрать много времени на его реализацию. Я просто начал читать, а там стока букавок.
Да. Диссер – не диплом. И если уж связались с микроконтроллером, то придется букафки учить, аднака… 😃 Хотя бы язык C для МК.
Самое быстрое не спортивное решение это наверное, взять какой-то APM, и на него уже подавать значения с моей плата, а он уже будет это всё конвертировать в mavlink. Как мою плату научить выдавать сигнала на понятном языке для всех gcs?
Не знаю, даже, помогут ли вам тут… А что за зверь-то такой GCS? А то мож я уже свою поделку под нее перетачивать начну.
Под online имею ввиду вывод телеметрии на экран ноутбука в время полёта/езды/проведения экспериментов.
Хм… вариантов - куча. Последовательный интерфейс, последовательный интерфейс через USB, USB Host, Bluetooth, Wifi. Это то, что навскидку
Я, например, в своих поделках на блютус подсел. Плата около полутора грамм весит и пару долларов. И проводов не нужно к компьютеру, голова не болит, подключай хоть к планшету хоть к буку. И дальность в несколько метров как раз. Из “ничего не нужно кроме кабеля” - USB, либо последовательный интерфейс через USB.
Как бы с этого обычно вообще начинают знакомство с МК. Меня смущает то, что с гироскопа Вы осилили снять показания, а на компьютер передать - нет. Как-бы задачи несоизмеримые по сложности.
2Yahen, всё верно говорите насчёт bluetooth и съёма данных с гироскопа. Данная проблема решена. Я вывожу по uart, а там через xbee и меня всё устраивало до поры. Пока мне не попались приложения GCS, подал туда свои циферки, но он то их не понимает. Тут и встал вопрос о унифицированном протоколе вывода. Чтобы все понимали мои показания. Вот и спрашиваю.
2 Mikele_P
Можете сказать, что именно измеряете? По моим подсчетам – 3 цифры угловых скоростей с Гироскопа и 3 цифры с ДЛУ. (еще максимум 3 цифры с электронного компаса)
у меня на борту:
4 акселерометра, 2 гироскопа, 3 магнитометра и gps=)) Каждый ДУС, аксель имеют свою полосу пропускания и масштабные коэффициенты, характеристики. Поскольку плата будет использоваться в разных условиях, хочу посмотреть как каждый датчик будет себя вести и по прицепу избыточности уже фильтровать.
Вот здесь лежат сырцы первого Ардупилота. В файле GCS_Standard_text.pde прописан интерфейс для наземной станции. Вот здесь лежит сама наземная станция. Читайте документацию и аккуратно настраивайте - все заведется. Внимательно посмотрите, в каких единицах передаются данные.
Удачи !
4 акселерометра, 2 гироскопа, 3 магнитометра
Одноосевых или трехосевых? По-моему для самолета маловато будет 2 гира. Осей-то три. Читал про систему фильтрации (что-то на английском языке. исследования проводили). Для серьезного приложения гироскопов (ДУС) должно быть не менее чем по 2 группы на ось в разных масштабах измерений с перекрытием в рабочей зоне, чтоб охватывать диапазон по-шире. И для уменьшения искожений не менее чем по два в группе в одном масштабе. Даже от двух погрешность по дрейфу падает, если не изменяет память, в 4-8 раз. (синергетический эффект)
А фильтровать ИМХО лучше уже разработанным алгоритмом.(не помню как звать на вскидку. найду – отпишусь. или тут подскажут.) там идет преобразование не из углов, а из векторов. Данные от гироскопа (угловые скорости по 3-м осям) помножаются на время между замерами и дают приблизительное смещение вектора направленного на землю. данные этого вектора весово смешиваются с данными от 3-х осевого акселерометра – корректируют. Пробовал. Если точно измерить ДУС, то при резких скачках угловой скорости достаточно точно определяет крен и тангаж. А вот курс – “плывет” по шуму ДУСа. Еще по той же схеме туда можно (опционально) замешивать данные от 3-х осевого компаса. Тогда и курс держать будет на ура. Данные вектора легко преобразуются в углы.
У меня один трехосевой ГИР и ДЛУ в одном флаконе. Компаса нет. Но мне пока крен-тангажа хватает чтоб помучиться и курс, скорее всего, я буду ровнять по ГПСу.
2 Mikele_P
все датчики 3-x осевые. Широко используется фильтр Калмана (ну про него наверно только ленивый не знает) и сейчас стал популярен альфа-бета фильтр (комплиментарный фильтр). Но это так сказать не мой путь, у меня должна быть новизна😁
Для серьезного приложения гироскопов (ДУС) должно быть не менее чем по 2 группы на ось в разных масштабах измерений с перекрытием в рабочей зоне, чтоб охватывать диапазон по-шире. И для уменьшения искожений не менее чем по два в группе в одном масштабе. Даже от двух погрешность по дрейфу падает, если не изменяет память, в 4-8 раз. (синергетический эффект)
ну вот это так сказать и пытаюсь реализовать, если дадите источники, где такое было написано, буду благодарен.
А фильтровать ИМХО лучше уже разработанным алгоритмом.(не помню как звать на вскидку. найду – отпишусь. или тут подскажут.) там идет преобразование не из углов, а из векторов.
это похоже на алгоритмы расчёта углов через кватернионы, но это не алгоритмы фильтрации, а расчёт углов.
данные этого вектора весово смешиваются с данными от 3-х осевого акселерометра – корректируют. Пробовал. Если точно измерить ДУС, то при резких скачках угловой скорости достаточно точно определяет крен и тангаж. А вот курс – “плывет” по шуму ДУСа. Еще по той же схеме туда можно (опционально) замешивать данные от 3-х осевого компаса. Тогда и курс держать будет на ура. Данные вектора легко преобразуются в углы.
а это в простом варианте и есть альфа-бетта фильтр, в сложном “какой-то” фильтр Калмана.
2RedSun
Я почитал Вашу ссылку и смотрю есть много протоколов
- Supported Auto-Pilot Protocols
- ArduPilot Legacy (ASCII)
- ArduPilot Mega Binary
- MatrixPilot (UavDevBoard)
- AttoPilot
- MAVlink
- FY21AP II
- Gluonpilot
Какой из них максимально востребованный?
похоже на алгоритмы расчёта углов через кватернионы
Точно так. Просто слово это умное забыл.
Широко используется фильтр Калмана и сейчас стал популярен альфа-бета фильтр
Альфа-бета – ИМХО туповат. Идея, конечно хорошая, но это попытка сгладить значения за счет статистики. А в нашем случае, когда оно должно жить сейчас, т.е. он-лайн – оно не канает. Сглаживая оно угробляет точность. Да и Кальман не безгрешен. И его пробовал. Коррекция одних данных через другие – более эффективна.
Уж лучше делать массивы датчиков. И по данным большого массива получать более точные данные по угловым скоростям. А значит, интегрируя по времени (время между замерами считать) получать данные по углам. (хотя уж лучше получать вектора)
Или, как вариант “совмещать ужа с ежом”. У вас куча ДЛУ. В одной из книг читал, что если их разнести от ЦТ на некоторое расстояние, то можно с некоторой точностью по разности сил вычислять углы смещения. Конечно это было писано для кораблей. Но если усложнить, то и для систем вращающихся в трехмере покатит. А значит смешав их через кватернионы с данными простого ДЛУ и ГИРов можно добиться усреднения и устранения “плывунов”. Хотя, думаю, идея уже не нова.
если дадите источники, где такое было написано
Извините. Я-то диссер на эту тему не пишу… Источники, увы, не сохранил. Просто принял к сведению и держу в голове.
Кватернионы - слово то какое хитрое. Сейчас давно не выпендриваются, говорят: матрицы, вектора…
Сейчас давно не выпендриваются, говорят: матрицы, вектора…
Хм… как бы матрицы это одно, векторы - другое а кватернион - третье. 😃
Все - частный случай матрицы, такшто нефик. 😃
Все - частный случай матрицы, такшто нефик
Так можно и натуральные числа к матрицам свести. Тоже типа частный случай 😃
Ну совсем уж в крайности я думаю не стоит бросаться.
А про то, о чем речь - там матричная математика. Перемножение матриц, сложение матриц, транспонирование, нормализация и т.п. И для краткости весь этот зоопарк матрицами зовут, и классы (в языках программирования) - сплошь обзывают matrix.
Или, как вариант “совмещать ужа с ежом”. У вас куча ДЛУ. В одной из книг читал, что если их разнести от ЦТ на некоторое расстояние, то можно с некоторой точностью по разности сил вычислять углы смещения. Конечно это было писано для кораблей. Но если усложнить, то и для систем вращающихся в трехмере покатит.
Подозреваю, что речь шла не про измерение углов, а про измерение угловых ускорений, из которых углы получаются двойным интегрированием. Уж лучше честный ДУС, благо их есть и незадорого 😃
2RedSun
Я почитал Вашу ссылку и смотрю есть много протоколов
Какой из них максимально востребованный?
Вам оно для чего ? Если хочется получать красивые картинки из наземки, то достаточно любого, который эта самая наземка понимает. Творение ХеппиКилмора понимает почти все из Вашего списка. Родной для нее ArduPilot Legacy (ASCII). Я Вам прислал ссылку на код, который этот протокол реализует. Вполне достаточно для экспериментов…
Сырцы, реализующие другие протоколы, придется выковыривать из других проектов. Это вполне реально, я как-то приживил к ардупилоту глюоновскую наземку. Требует аккуратности и понимания того, что делаешь.