Симулятор для автопилота SmallTim
Для более понимаемой ориентации в происходящем добавил к отображению коптера фон. Серые кружочки жестко привязаны к воздуху. Единственно только, масштаб фиксированный для отображения (под параметр “точек/метр”=50). Пробовал с реальным масштабом, но на больших скоростях “обман зрения” возникает (не знаю как правильно называется эффект подобный съемки вращающихся тел, когда частота кадров кратна частоте вращения). Тут то же самое, только по перемещению… Но не суть важно… Считайте, что если “точек/метр”>50, то кружочки располагаются вдали от модели, а при “точек/метр”<50? то ближе…
Уф… Подкосили меня местные уральские морозы под самый корешок!.. Провалялся в трупообразном состоянии (с температурой 38…40) всю неделю!.. Не ел, не курил, не вставал, не думал… Только антибиотики килограммами пожирал… Соответственно и подвижек никаких не было…
Ну вроде бы начинаю отходить… Сегодня ночью добавил к самолетному симу мониторинг некоторых параметров и стабилизацию по крену и тангажу.
В общем самые обычные независимые контуры (ПИД). Газ в режиме СТ работает следующим образом: Положение стика - это задание регулятору скорости (ПИ) от Vmin до Vmax (в настройках стабилизации). Решил сделать так во-первых для того, чтобы не терялась робастность, а во-вторых, чтобы при наборе высоты ненароком не подвесить модель…
Константы (для прилагаемой модели Ская) подобрал так, чтобы был максимально быстрый выход на заданное значение с минимальным перерегулированием, была максимальная устойчивость к порывам ветра, почти что под предел возникновения автоколебаний на полном газу…
Добавил набросок автонастройки, пока не автономный, другими словами перед автонастройкой надо в штиль дать модели “успокоиться”. Завершение вручную (дать хотя бы пол минутки понастраиваться).
Коптер удалять?! А то вроде бы просили сделать, а никаких советов по поведению не даете! Еще раз оговорюсь - я на коптерах не летал и как они себя ведут не представляю… Если надо интерфейс для обмена организовать, то какие именно параметры в каком виде и на какой запрос передавать? У меня все в real (float по Сишному) все единицы системе СИ. Всякие там км/ч с градусами для простоты понимания отображаю…😃
Автовозврат (АВ) пока не делал, т.ч в него пока не тычте! 😒
Если надо интерфейс для обмена организовать, то какие именно параметры в каком виде и на какой запрос передавать? У меня все в real (float по Сишному) все единицы системе СИ. Всякие там км/ч с градусами для простоты понимания отображаю…
float это 4 байта. Вот их в чистом виде и можно гнать на выход. Меня флоат устраивает полностью, Олега, думаю, тоже. Тима - не факт, что устроит в меге с флоатами хужее.
Гнать на выход нужно:
- маркер начала пакета (2байта)
- длина пакета (1 байт)
- крен
- тангаж
- рыск
- скорость по земле
- скорость по ветру
- высота по барометру
- широта
- долгота
- курс по ГПС
- CRC32 (2 байта)
От нас пакет с каналами (я думаю по 2 байта на канал, значение длины импульса 1000мс - 2000мс, середина 1500мс):
- маркер начала пакета (2 байта)
- длина пакета (1 байт)
- джой крена
- джой тангажа
- джой курса
- джой газа
- сервисный канал (тут надо договориться, что будем передавать, либо на будущее зарезервировать)
- CRC32
Передавать FS я думаю смысла вообще никакого нет.
Обманул!.. Real в дельфи - это double в C#… Тобишь 8 байт. Конечно нафиг такая точность не нужна, и все же, как нам лучше “совместиться”?
вычисленное значение делфы real умножить на 100 и засунуть в integer (4 байта)
Для угловых скоростей, к примеру (если гира на модели стоит), хреновенькая точность будет…
Ну точность ты на своей стороне загрубишь. Надо настройку какую-нибудь сделать на эту тему.
Реальность сейчас снимать с IMU углы с точностью не менее 0,5 градусов. Точность по высоте 0,5 метра. Ну про ГПС, ты и сам знаешь.
Для универсальности и тупого однообразия предлагаю все же умножать float на 100 и откидывать все, что после точки.
А как приеду смогу тебе пример сокета организовать в Делфе, если хочешь.
Сбрось если не трудно, чтобы я не кустарничал… С Integer нефига заморачиваться, я передаваемые параметры в Single переведу (типа float 4-хбайтовый)…
Вот такую последовательность (4 байта float) 79 E9 F6 42 как расшифрушь?
Вот такую последовательность (4 байта float) 79 E9 F6 42 как расшифрушь?
Если обратный порядок, то 1.23456001E+2
Если прямой , то 1.51849983E+35
Какой правильно?
Могли бы и сами догадаться! 😁
Или верите в случайное попадание в натуральный ряд чисел?
Обратный!.. Все верно!..
123,456
Ну тогда я сваяю обмен и попробуем приконнектиться…
сим - сервер, настройки подключения в “главное меню”-“connect”
при получении от клиента запроса:
AA // маркер начала пакета
EE // маркер начала пакета
11 // длина пакета 17 байт (включая CRC)
4 байта // тип integer начиная с младшего элероны в мс. (1000…2000)
4 байта // тип integer начиная с младшего РВ в мс. (1000…2000)
4 байта // тип integer начиная с младшего рудер в мс. (1000…2000)
4 байта // тип integer начиная с младшего газ в мс. (1000…2000)
СС // пока не CRC, а просто маркер конца
Кидает в ответ:
AA // маркер начала пакета
EE // маркер начала пакета
21 // длина пакета 33 байта (8 параметров*4 + CRC)
4 байта // тип float начиная с младшего - текущий крен в радианах
4 байта // тип float начиная с младшего - текущий тангаж в радианах
4 байта // тип float начиная с младшего - текущий курс в радианах (0-север)
4 байта // тип float начиная с младшего - текущая скорость в м/с относительно планеты
4 байта // тип float начиная с младшего - текущая скорость в м/с относительно воздуха (бароскорость)
4 байта // тип float начиная с младшего - высота в метрах
4 байта // тип float начиная с младшего - расстояние до модели на север в метрах
4 байта // тип float начиная с младшего - расстояние до модели на восток в метрах
СС // пока не CRC, а просто маркер конца
При этом ставит свои джойстики в соответствии с данными пришедшими в запросе.
Иные запросы игнорирует…
Посмотрел обзорно, попробовал подконнектиться. Вроде на первый взгляд все пучком. Железку раньше конца недели не смогу попробовать, ибо сейчас решаю проблему с s-bus реализацией для одного из форумчан. Сразу после этого попробую.
CRC32 (2 байта)
CRC32 оверкилл здесь, не? Я не смогу CRC32 быстро считать.
Намеренно ничего не ввожу, дабы отработать идеальное поведение.
Люфт серв (гистерезис) и скорость отработки (град/сек) надо сразу вводить.
Тима - не факт, что устроит в меге с флоатами хужее.
Я флоат тоже съем, нивапрос.
Поигрался с моделью. Всё очень правдоподобно для Ская, но почему-то он у меня не валится с СТ и минимальным газом - так и прет с углом тангажа градусов 30…
Про обмен данными - я, может быть, сейчас глупость спрошу, а с чем вообще предполагается обмен данными от сима и в сим? С железкой? С контрольной панелью либо клиентской частью АП на ПК?
Люфт серв (гистерезис) и скорость отработки (град/сек) надо сразу вводить.
не сложно… только мне надо будет доделать управляющие элементы по человечески (зависимость от углов). В данный момент я просто добавляю к Y элемента добавочную силу, пропорциональную ро V квадрат, площади элемента, управляющему сигналу и эффективности руля (упрощенка).
но почему-то он у меня не валится с СТ и минимальным газом
Я же написал, что сделал газ в режиме СТ по ПИ закону на поддержание скорости. Сделал это как раз с целью защиты от сваливания… Если посмотрите на значения выходов, то увидете, что газ в режиме СТ меняется так, чтобы удержать заданную скорость. Например на пикировании он совсем в ноль может уйти…
Задание скорости - это положение стика газа (от минимальной до максимальной, которые задаются в настройках СТ). Эт я так… Просто эксперементирую…
Кстати, про люфт… Его реально люфтом делать? В том плане, что руль под действием аэродинамической силы должен отклониться на заданную дельту от задания в сторону этой самой силы?
Тогда этот эффект почти не заметен будет… Больший раскордаж даст введение дискрета серв…
Я завтра домой еду на новогодние каникулы. До 14-го вряд ли получится что то сильно поваять…
Начал автовозврат прикидывать.
Режимы напрашиваются такие:
- по курсу (элеронами или рудером) разворот по необходимости в нужную сторону, далее удержание траектории по прямой (не направления). Т.е. даже при боковом ветре идти по прямой. Правда ось самолета не будет в точку возврата направлена в этом случае…
- по высоте два варианта. Первый - сразу занять целевую высоту и удерживать ее. Второй как и с курсом идти по прямой от точки включения АВ, до заданной точки…
таких режимов достаточно?
Я же написал, что сделал газ в режиме СТ по ПИ закону на поддержание скорости. Сделал это как раз с целью защиты от сваливания… Если посмотрите на значения выходов, то увидете, что газ в режиме СТ меняется так, чтобы удержать заданную скорость. Например на пикировании он совсем в ноль может уйти…
Виноват, недоглядел.
Кстати, про люфт… Его реально люфтом делать? В том плане, что руль под действием аэродинамической силы должен отклониться на заданную дельту от задания в сторону этой самой силы?
Я вижу это примерно так: есть люфт механики и гистерезис элеетроники.
Люфт сервы и механизмов - Х процентов от полного хода, если он нормализован в пределах от -1 до 1 или Х радиан, если не нормализован.
Опишу для простоты для нормализованного случая.
Приходя из -1 в положение А, серва остается в положении А, диапазон нечувствительности сервы становится от А-Х до А. Если серву просят подвинуться до положения А+В (В меньше Х), то она идет в А+В, а вот если просят придти в А-В, то серва стоит на месте.
В итоге, серва, перемещая качалку, “тащит” за собой окно нечувствительности величиной Х.
Аэродинамические силы могут прижать это окно к положению А, а могут и не прижать, тут уже надо думать…
Это про люфт.
Гистерезис - сама электроника сервы обычно не поддерживает заданное положение с идеальной точностью. Думаю, нужно ввести величину Y - процент от полного хода сервы, она будет задавать окно, в пределах которого серва не реагирует на входной сигнал и вообще ведет себя некрасиво.
Эта Y очень маленькая, но она есть.
Алгоритм учета Y, думаю, такой:
- Получая команду придти в положение А, серва приходит в случайное положение в диапазоне от А-Y до А+Y c равномерным или гауссовским распределением.
- Получив команду придти в положение В, серва не реагирует, если abs(B-A)<Y.
Расскажите подробнее по подключению сима к нашему софту-железкам. Я не до конца вкурил 😦
Может быть, не имеет смысла имитировать АП, а кормить реальный АП смоделированными симом командами и данными (пульт, ветер, ГПС, упрощенно ИМУ и т.д.), получать сервокоманды от АП и рисовать, что будет в таком случае с самиком?
Я к чему про люфты и прочее - самая сложная задача, по крайней мере, для меня, это вести модель идеально ровно, парируя все отклонения в зародыше.
В итоге модель быстро или медленно “дрожит” или “колышется” вокруг идеального положения, и это можно увидеть.
С “идеальными” сервами и идеальной ИМУ это можно сделать, а вот с неидеальными - большой вопрос. Шумы ИМУ и прочее мы задавили, надо будет - еще придавим. А вот что как делать с сервами - непонятно. Очень интересно, что вообще принципиально можно сделать на эту тему на маленьких модельках.
Мысли есть, но пока держу при себе, опять начнут требовать - вынь да положь сразу прямо сейчас 😃
CRC32 оверкилл здесь, не? Я не смогу CRC32 быстро считать.
вроде сошлись на CRC8 - 1 байт, но сейчас вообще любое значение.
а с чем вообще предполагается обмен данными от сима и в сим? С железкой? С контрольной панелью либо клиентской частью АП на ПК?
С железкой конечно. Для отработки автоматических режимов полета, сидя дома и попивая пиво, а не бегая на поле ради каждой новой закорючки в коде.
А бы дальнейшее и целевое развитие предложил бы вообще в сторону ActiveX, чтобы можно было эту штуку прямо в КП встроить как чать софта.
Расскажите подробнее по подключению сима к нашему софту-железкам. Я не до конца вкурил
Запускаешь СИМ, выбираешь там порт прослушки, жмешь коннект.
Дописываешь себе небольшую софтинку, которая шлет в этот порт положения джойстиков, которые твоя железка выставляет. В ответ получаешь параметры IMU. Подсовываешь эти параметры в свою железку, она думает, что летит, а на самом деле лежит рядом с тобой на столе.
Сегодня (хотя уже вчера) немного поделал прогу…
Добавил дискрет и скорость серв (в настройках модели). Если сильно загрубить, то весьма сложноуправляемая раскарячка получается. 😁
И немного поваял логику автовозврата…
Положение (относительно точки старта) отображаю на форме параметров автопилота (может не совсем удобно, но просто места другого пока не придумал, слишком много всего на главной форме натыкано).
Автовозврат следующий:
Сразу занимает целевую высоту и держит целевую скорость (по бародатчику).
С курсом разные варианты в голову приходят. Решил пока остановится на направлении скорости (GPS). Т.е. удержание направления скорости на точку старта. Если включить боковой ветер, то ось модели будет направленна под углом к точке возврата. Курс удерживает элеронами.
На картинке:
крест в центре - точка старта
Красный кружок - положение модели
красная линия - скорость GPS
пункрирная - направление оси модели
Желтая - ветер (если есть).
Север вверху…
Возможно прога совсем малопонятная становится!.. Т.ч. принимаю пожелания по внешнему виду. Расположение, меню, настройки и т.п…
Кирилл, в существующем варианте прога, скорее, очень удобный инструмент для разработчика. Конечный пользователь ужаснется и тут же нажмет крестик в правом верхнем углу.
Думается мне, надо хоть какую-никакую графику и гаджеты прикрутить, чтоб оно не смотрелось как пульт управления синхрофазотрона.
Земля - плоскость с текстурой, моделька - 3Д, небо, и т.д. Не надо особенных уж изысков, горы, джунгли и города, но надо землю, небо, модель и привычные хотя бы, например, по AFPD, положения камеры и т.д.
У меня, к сожалению, просто ноль времени на графические изыски, чтоб заниматься ими самостоятельно, но могу поделиться исходниками и помочь любыми советами для отрисовки не слишком сложных 3Д сцен хоть в OpenGL, хоть в DX11. Вот это - моё, двухлетней давности…
Тимофей, я графикой никогда не занимался. Отображение сделал лишь бы понятно было что происходит.
Пользователям вообще не стоит запускать отдельную прогу без железа. Смысла нет! Красивые симуляторы и так уже существуют. Нам нужен не столько красивый, сколько полезный!..
Напрашивается следующее:
Компильнуть его в DLL и подключаться по необходимости из КП.
Можешь сбросить мне исходники КП дабы я с интерфейсами поиграл?
И еще:
На сколько сложно сделать в автопилоте (в мозгах самой железки) отладочный режим? По принципу:
- включение этого режима возможно только из КП. При отключении КП, АП переходит в обычный режим.
- показания датчиков (всех) считываются не с железок, а с КП (в саму КП я их передам из сима в любом удобном виде).
- Значения всех выходов (уже смикшированные) передаются в КП (по принципу мониторинга параметров). Физические PWM-ы в этом режиме можно даже и отключить…
Суть такая:
В контрольной панеле будет раздел “Симулятор”. Подключаешься к плате автопилота (можно ее даже на модель не ставить и вообще никаких датчиков не подключать). Заходишь в этот раздел, запускаешь симуляцию и тебе прямо в КП показывается как твой автопилот (прямо сама железка) управляет моделью (виртуальной).
Думаю так будет наиболее правильно! Во всяком случае не наколишься с версией АП (соответствие логик сима и платы) и настройками. Что зашито в плату - то и управляет…
А визуализация уже есть (прямо твоим самолетиком из КП можно все показывать). А уж если захочетмся большего, то можно какого нибудь спеца по 3D графике попросить написать графический модуль.
Совсем все тут заглохло… 😦
На работе запарка полнейшая, поэтому некогда было заниматься… Вот выбрал время поигрался с OpenGL-ем… Рядом с окном “вид с камеры” добавил галочку 3D. Можно ткнуть и посмотреть что получилось. Это первый опыт с 3Д, т.ч. не пинайте сильно… Не паханное поле для оптимизации, т.ч. когда включаешь притормаживает немного (может у меня ноутбук еще слабоват)…
Но это все баловство!.. Не для этого прогу задумывал!..