Изображение взято, и слегка отредактировано, из блога Антона Лопатина©. Ну очень вдохновляет.
Добрый день, уважаемое сообщество!
В прошлом топике я постарался сделать вводной экскурс в модельно-ориентированное проектирование встраиваемых систем с использованием ARM микропроцессоров Cortex M3 и MATLAB/Simulink. Продолжаем погружение, усложняем задачу. Жаль до концепта на заглавной иллюстрации еще далеко, но процесс разработки одного из важнейших его узлов, а именно системы самонаведения турели, я попытаюсь показать.Ниже довольно много изображений, но без них скучновато и не наглядно.
Аппаратное обеспечение
В отличии от первого топика теперь у нас в руках имеются:Отладочная плата FiO Std от таиландских друзей из aimagin. Без нее работа с библиотекой RapidSTM32 для Simulink слегка затруднительна. Используется и как hardware key для rapidSTM32, и как управляющий модуль. На борту имеет камень STM32F103RET6.
2 простецких сервомотора SG-5010
WEB камера Logitech HD Webcam C270. Но не настолько гламурная, как в обзоре и на фото.
Пара резисторов, проводки, коннекторы, макетная плата, блок питания от старого принтера, резиночки для ватмана, медная проволока, кабель mini USB, ноутбук, и, главное, самодельный держатель для паяльника из седла предохранителя (сделан дядей Сашей©, используется в качестве станины).
Еще одним отличием от красивого концепта будет то, что для нашей поделки понятие «собранная на коленке» максимально приближено к действительности. Яркий пример рапид разработки. Быстро, дешево, работоспособно.
Постановка задачи и подзадач
Главной задачей является реализация функций захвата и сопровождения цели. Для достижения намеченного нам предстоит:Организовать связь с ПК.
Устройство наше будет распознаваться как HID, и будет слушать мой ноутбук через USB.
Механизировать головку самонаведения.
Хватит мигать диодами, переходим на сервы. Классика жанра постигания премудростей работы с мехатроникой.
Создать систему управления на стороне железа.
Мех. составляющая + HIL влечет за собой более сложные алгоритмы управления на стороне железа. Как минимум применение PID регулятора. ТАУ наше все!
Реализовать алгоритм распознавания видео и выдачи управляющих сигналов на стороне хоста.
Для слежения за объектом необходимо этот объект идентифицировать. Пока этим будет заниматься мой ноутбук, но в будущем можно переложить и эту задачу на крепкие плечи ARM. Здесь, возможно, стоит присмотреться к bigle board на процессоре TI OMAP3530. То ли еще будет.
Модель на стороне хоста
Свернутая модель, на которую возлагаются функции обработки видео и выдачи управляющих сигналов выглядит так:
Видеосигнал разделенный на каналы передается на подсистемы детектирования и обработки. После них выходные сигналы передаются через USB на плату управления.
Допустим объект у нас подсвечивается лазером с определенной длиной волны. Главной задачей подсистемы распознавания видео будет выделение заданного цветового оттенка, фильтрация возможных помех и выдача лаконичного сигнала о расположении объекта. Для нашего «быка» мы будем использовать не красный платок, а зеленый, что опять-таки не столь важно. Можно и движение сюда подвязать…
Подсистемы детектирования выглядят так:
Подсистемы фильтрации выглядят так
С распознаванием видео я знакомился в процессе разработки, потому и алгоритм выбрал самый простой. Расщепленный видеосигнал проходит через ветви условий, которые возвращают true или false (вместо процентовки RGB) в зависимости от заданных условий. Как видно из числовых значений, я ориентировался на зеленый цвет.
На выходе систем мы вместо видео получаем матрицу из поля нулей и замкнутых островков из единиц. Подсистема обработки полученной информации определяет площади и центры полученных «островков», обрисовывает их границами и эквивалентными окружностями, а так же определяет расстояние центра объекта от центра матрицы. На сторону железа передается ошибка с строках и колонках для наибольшего островка, и количество островков. Если этот самый num==0, то турель переходит в дежурный режим и выполняет плановое сканирование местности по горизонтали. Отсчет ошибок ведется не от абсолютного центра изображения, а от границ прямоугольной «нулевой зоны». Внутри этой зоны объект считается «захваченным» и камера фиксирует свое положение. Все дополнительные построения налаживаются на оригинальное видео, дополняя серую и невеселую стену моей комнатыреальность нашу бодрыми прямоугольничками и кружочками.
Подсистемы черчения дополнительной графики и определения ошибки выглядят так:Simulink учтиво и заранее напоминает нам, что блоки клейменные пометкой «Reglace» следует заменить до выхода новой версии программы. Иначе модель будет не совместима с ней.
Следует отметить, что привязка к запущенному Simulink не обязательна. Используя тот же Simulink Coder можно сгенерить С++ код для сборки самостоятельного приложения как для Windows, так и для Linux. Я в этом пока не силен, поэтому ограничился работающей Simulink моделью в режиме Accelerator, то есть в режиме частичной компиляции для увеличения скорости выполнения:
Модель на стороне железа
Модель Simulink из которой генерится код для заливки в микроконтроллер выглядит как показано на иллюстрации ниже: Выполнена в едином тактировании, что и видно по одинаковой цветовой подсветке для всех блоков модели после обновления. Как и упоминалось ранее, помимо элементарных блоков типа сложения или умножения, модель содержит два PID регулятора. Скорее даже PI, потому как коэффициент дифференцирующей составляющей равен нулю.
Параметры подбирались вручную опытным путем. Но для более серьезных систем у MATLAB есть специальный инструмент Control System Toolbox для «тюнинга» линейных систем управления на основе экспериментальных данных с возможностью задания требуемых параметров регулирования.
Малый пропорциональный коэффициент и нулевой дифференциальный обусловлены довольно ощутимой задержкой по времени, в которую каждый элемент системы вносит свою лепту.
Назначения блоков Saturation и Dead Zone думаю ясны из графиков на их пиктограммах.
Вначале реализация «дежурного» и «боевого» режимов задумывалась с использованием конечных автоматов, но потом оказалось, что вопрос можно решить проще. Поэтому FSM еще впереди. Реализуется эта концепция внутри Simulink с помощью изящного инструмента Stateflow, и так же легко заливается внутрь МК.
Генерация, компиляция и заливка кода выполняется полностью из под MATLAB. Keil даже запускать отдельно нет нужды.
Собственно процесс разработки
Все перечисленное выше является большей частью уже результатами нежели этапами разработки.
Пока не было серв (читай отсутствие аппаратной составляющей как таковой) алгоритмы работы системы отрабатывались на вот такой некрасивой, монстрообразной черновой модели:
Потом она стала вот такой:
Главной отличительной частью этих моделей является механическая подсистема (выделено синим цветом на предыдущей иллюстрации), которая позволяла оценить работу системы исключительно с помощью ПК. В моем случае важно было оптимизировать угловую скорость вращения серв, и коэффициенты PI регуляторов, но возможен и полный механический анализ системы.
Так выглядела сборка в Solidworks:
А так выглядит симуляция движения сборки уже внутри модели Simulink:
Очень серьезный инструмент симуляции динамики и статики есть и внутри Solidworks, но мне работа с MATLAB пока роднее. Экспортируется сборка с помощью утилиты SimMechanics Link. Здесь про нее много чего написано.
Одним словом, когда приехало «железо», у меня уже было почти все готово. Я просто удалил все лишнее и разделил модель на две составляющие: Host и Target.
Результаты испытаний
Ну и наконец видео полевых испытаний:
Да, довольно страшненькая сборка. На премию супер прямых рук точно не претендует.
На экране ноутбука творится следующее:
Выводы
Позитив:Разработка заняла минимум времени и ресурсов. Все работает удовлетворительно, и легко поддается модернизации. Реализация «спускового крючка» — нет ничего легче. На плате осталось еще 100500много свободный портов. Нужно всего лишь добавить ветвь условия при нахождении центра объекта в зоне захвата, которая будет подавать лог. 1 в определенный порт и спускать с цепи рейл ган имитировать выстрел.
Поучительный негатив:Использовать кота в качестве мишени не получилось. Серый камуфляж не поддается обнаружению, а попытка нацепить на него метку увенчалась провалом. К тому же он еще и ужасно боится жужжания серв. Пришлось испытывать все на себе.
Для увеличения быстродействия и стабильности работы нужно еще много чего совершенствовать. Механическая часть оказалась самой капризной. Калибровка серв заняла большую часть времени отведенной на пусконаладку. При дальнейшем развитии проекта нужно будет обязательно переходить на более качественные девайсы, возможно с последующей доработкой и введением собственной обратной связи.
Я не смог совладать с автоматическим изменением настроек яркости камеры в зависимости от освещения и окружающего фона. Понятно, что это влияло на селективность системы распознавания. В дальнейшем планируется использовать отдельный модуль камеры (возможно с упором на ИК диапазон с соответствующей подсветкой) с прямым присоединением к управляющей плате.
С превеликим удовольствием и безграничной благодарностью приму к сведению разумную критику в комментариях. И здесь же допишу!
