Предисловие В 2013 году с целью популяризации робототехники в России и создания среды программистов и инженеров, ориентированных на эту тему, компания КРОК (Москва) организовала конкурс «Летающие роботы».
Наша команда «iКар» (3 человека из Барнаула и 1 из Москвы) участвовала в 2013 году (конкурс «Улететь и вернуться») и 2014 году («Догони и перегони Крок») и не победила, но добилась хороших результатов.
1. Как все начиналось или условия конкурса
Будучи по профессии программистом 1С, мне часто приходится пользоваться форумом forum.mista.ru. Один из моих друзей-коллег первым заметил объявление на тему «Кому лимон» и предложил поучаствовать.Условия конкурса выглядели заманчиво: нужно было построить или купить летающего робота и научить его передвигаться/ориентироваться на полигоне, автоматически взлетать и приземляться, распознавать ориентиры приземления.
Продолжительность всей работы — 1 год, премия — 1 миллион рублей.
У меня был опыт сборки вертолетов и квадрокоптеров, как для хобби, так и для профессионального использования в аэрофотосъемке.
Было много вопросов по различным настройкам, коэффициентам ПИД, коду и алгоритмам полетных контроллеров.
Используя мотивацию конкурса, можно было все глубоко понять.
С детства у меня была мечта изучать робототехнику, и участие в соревнованиях позволило мне сделать первые шаги в этом направлении.
Вера в свои силы, «правое» дело и «вкусный» приз сделали свое дело; Весь семейный бюджет плюс свободные кредитные средства ушли на постройку «бюджетного» робота-дрона и поездку в Москву на соревнования.
2. Выбор платформы самолета
В качестве самолета можно было использовать: 1) готовый дрон, например "AR.Drone", который уже умеет летать и имеет много вкусностей, из минусов: - низкая производительность железа; - низкая грузоподъемность.
2) Постройте собственный самолет с необходимой грузоподъемностью и необходимым временем полета.
Второй пункт не вызывал сомнений; отличным вариантом был гексакоптер (6-моторный коптер) с расчетной грузоподъемностью 2 кг и расчетным временем работы 20 минут под нагрузкой с камерой и необходимой электроникой.
Для испытаний было решено сделать небольшой квадрокоптер – «мальчика для битья».
Гексакоптер на основе рамки Таро-680 
Квадрокоптер для «избиения»
Особое внимание было уделено вопросу безопасности – все коптеры были оснащены защитой пропеллера.
Таким образом, после столкновения со стеной или падения все оставалось целым.
Это сэкономило деньги и время на ремонт.
3. Электрическая схема дрона 2013 г.
Чтобы быстрее решить проблему и снизить трудозатраты, было решено строить дрон из готовых модулей, а не, например, делать все на базе одноплатного компьютера, который бы выполнял все расчеты.
Так, например, можно купить полетный контроллер, способный удерживать самолет на горизонте и стабилизировать полет, а управлять им с помощью другого устройства (микроконтроллера, компьютера) — автопилота, получающего данные от датчиков и радиомодема (подробнее о об этом позже) и передает команды полетному контроллеру на движение вперед, назад и т. д. Автопилот также выполняет всю интеллектуальную работу (навигацию и т. д.).
Поскольку анализ изображения (определение маркеров посадки) является достаточно ресурсоемкой задачей, расчеты необходимо проводить либо на борту на достаточно мощном микрокомпьютере, либо анализ проводить вне дрона на базовой станции (ноутбуке), и изображение с дрона необходимо передать на базовую станцию по Wi-Fi или через аналоговый видеопередатчик.
Таким образом, путём распознавания маркеров получилась следующая схема (с аналоговым видеопередатчиком): 1) изображение с видеокамеры на борту дрона передавалось через видеопередатчик; 2) принимается видеоприемником на базовой станции; 3) аналоговый видеосигнал подавался на ноутбук через видеозахват (ВИДЕО-> USB); 4) на ноутбуке изображение распозналось с помощью программы (OpenCV); 5) экранные координаты «увиденного» маркера (X,Y) передавались на автопилот через радиомодем; 6) на основании полученных экранных координат автопилот определял местоположение маркера посадочной площадки относительно дрона и принимал решение о посадке или навигации для посадки.
Электрическая схема дрона 2013 года
4. Выберите полетный контроллер.
В наличии был полетный контроллер — MultiWii ALL-IN-ONE; был взят из существующего FPV квадрокоптера: 
По летным характеристикам этот полетный контроллер неплох с ручным управлением, но по качеству стабилизации существенно уступает профессиональным контроллерам с более мощным аппаратным обеспечением и математикой.
При использовании для робота со стандартной прошивкой настроить MultiWii не удалось, поэтому прошивка была скорректирована.
Использование для проекта профессиональных контроллеров с открытой прошивкой, таких как OpenPilot или PixHawk, имело бы больше смысла, но в то время это было невозможно.
5. Выберите датчики
Для ориентации в пространстве необходимо было подобрать для дрона датчики.
Список выбора: 
Доступные с точки зрения бюджета и простоты использования датчики включали ультразвуковые гидролокаторы и ИК-датчики.
Поскольку бюджетный ультразвук имел большую дальность измерения (до 4,5 метров), чем ИК (до 1,5 метра), именно его выбрали в качестве основных датчиков для дрона.
Всего потребовалось 5 штук: 1 гидролокатор был направлен вниз для поддержания высоты, и 4 штуки.
по периметру для ориентирования от стен.
Пришлось хорошо изучить ультразвуковые датчики, чтобы заставить их работать корректно.
Для более глубокого и безопасного исследования был построен наземный робот-танк с установленным гидролокатором.
Танк держал заданную дистанцию до препятствия, например, листа бумаги, который можно было сдвинуть, а робот сам следовал за ним.
Данные протоколировались и потом их не составило труда проанализировать и определить нюансы.
Ультразвуковые гидролокаторы можно классифицировать по различным характеристикам, таким как эффективный угол (диаграмма луча), диапазон измерения расстояний и так далее.
Более того, качество измерения сильно зависит от различных характеристик датчиков.
Например, широколучевые гидролокаторы хорошо работают при больших углах отклонения от поверхности, до которой измеряется расстояние, а узколучевые гидролокаторы теряют свою эффективность.
Также широконаправленные «бьют» дальше (в зависимости от модели) и измеряют расстояние практически от любой поверхности (асфальт, ткань и т. д.).
Но у них есть небольшой недостаток – результаты измерений слегка «скачут» в отличие от узконаправленных, и соответственно приходится фильтровать полученные значения.
Любые гидролокаторы требовали «качественного» питания, иначе их показания «скакали» и ориентироваться по ним было невозможно.
Для качественного электропитания необходимо использовать сетевые фильтры или иметь отдельный DC-DC, полные рекомендации можно прочитать Здесь .
После того как танк стал не нужен, он превратился в игрушку.
С установленной на борту камерой (гидролокатор был снят) можно было кататься по квартире с помощью FPV. 
Подробнее о танке: forum.rcdesign.ru/blogs/45616
6. Выбираем автопилот, а точнее немного паяем
Для считывания данных с гидролокаторов, принятия навигационных решений и отправки данных на контроллер полета нужен был отдельный компьютер – автопилот. Так как я имел представление о контроллерах семейства Atmega, то за 2 вечера впаял плату опроса на Atmega162 (единственный контроллер в DIP корпусе и имеющий 2 порта UART, который можно было купить в местном радиомагазине), который позже был заменен на Atmega128 (прошивка разрослась и уже не помещается в память контроллера).
Пины на плате являются разъемами для подключения эхолотов.
Главным преимуществом использования этих контроллеров по сравнению с контроллерами на Arduino было то, что код можно было отлаживать (отлаживать) отладчиком через JTAG! То есть в любой момент вы можете остановить программу и посмотреть все, что вас интересует — значения переменных, счетчиков и т. д., а также, в случае возникновения ошибки, найти пошагово, где она произошла.
7. Учимся сохранять высоту
Чтобы ускорить разработку/тестирование в сжатые сроки, было решено проводить тесты в квартире, а не куда-то ездить и тратить драгоценное время.Недолго думая, в помещении площадью 12 квадратных метров был создан испытательный стенд. метры.
В потолок и в поле были вкручены крюки, а между ними натянута прочная парапланерная веревка.
В раме дрона была установлена вертикальная направляющая — карбоновая трубка.
Сверху имелся ограничитель, не позволяющий коптеру упираться в потолок.
В результате коптер мог двигаться только вертикально, что было необходимо для безопасной регулировки коэффициентов ПИД удержания высоты для себя и коптера.
Более подробно о полигоне тестирования можно посмотреть на видео:
На настройку ПИДов было потрачено немало времени, но на личном опыте и практике нам удалось хорошо понять механизм управления.
Еще я остановился на модели гидролокатора для поддержания высоты, которая работала приемлемо – это широколучевой DYP-ME 007 v1.0. Популярный HC-SR04 показал себя хуже — «застрял» на плохой поверхности.
Благодаря работе «вживую» на стенде нам удалось добиться хорошего результата; коптер прекрасно выдерживал заданную высоту.
8. Удержание курса или немного о компасе
Одной из следующих проблем было поддержание курса (ось Yaw), то есть чтобы коптер не крутился вокруг своей оси.Решение использовать компас, находившийся на борту контроллера полета, оказалось на первый взгляд простым, но впоследствии неприемлемым, поскольку компас отказался работать в Москве на полигоне организаторов (линии электропередач и т.п.
).
Однако такое решение позволило нам продолжить тестирование в нашей квартире и перейти к следующим задачам – двигаться дальше.
В Москве, выяснив в ходе теста, что с помощью компаса ориентироваться невозможно, мне удалось отключить компас и написать собственный алгоритм удержания оси рыскания.
Для этого я ввел значение расчетного угла Yaw (кстати, на полетных контроллерах Open Pilot CCD3 этот угол тоже рассчитывается, так как компаса на борту вообще нет, а угол поворота можно посмотреть в настройке программа).
Значение угла рассчитывалось по данным гироскопа (угловое ускорение по оси рыскания), формула подбиралась опытным путем.
Далее в стационарном состоянии я измерял, насколько это значение уходит за 5 минут (был небольшой дрейф в одну сторону), и через определенные промежутки времени корректировал этот угол, чтобы свести результирующий дрейф к нулю.
На столе все работало идеально; на коптере при отсутствии сильных вибраций тоже должно работать.
9. Соблюдение дистанции от одной стены
Один эхолот (узколучевой HY-SRF-05) я прикрепил перед коптером для автоматического удержания положения в направлении вперед-назад (вдоль оси тангажа).С пульта управления я вручную управлял движением коптера вправо и влево (вдоль оси Roll), а в случае неудачной настройки ПИД-регулятора корректировал смещение коптера вперед-назад; при отклонении стика пульта от центра на 10% коптер переходил в ручное управление по осям вперед-назад (Шаг).
Изрядно помучавшись с настройкой ПИД-регулятора и перебрав его коэффициенты, я получил 3 коэффициента управления, при которых устройство почти сносно «держалось» на стене:
Положение P, когда ошибка управления рассчитывается как разница между желаемым расстоянием от стены и текущим по данным гидролокатора.
D – положение (Dposition), скорость движения от/к стене.
D по скорости (D-velocity), ускорению движения от/к стене.
И (I) - не учитывался коэффициент не за положение и не за скорость = 0. Дальнейшие поиски истины я уже перевел на код полетного контроллера.
Как оказалось в коде MultiWii, многие настройки в коде были выбраны эмпирически.
Руками летать можно, но для робота всё получилось не очень.
Я решил переписать ПИД-регулятор и сделать то же самое: положение P и D + скорость D, поколдовал с фильтрами, которые позаимствовал из кода полетного контроллера ArduPilot и получил «хороший» результат, но такого, конечно, быть не может. по сравнению с профессиональными контроллерами.
Когда я все совместил, то впервые получил хороший результат: удержание в пределах 1 метра по горизонтали на высоте 50 см.
Попробовал сделать высоту повыше, размах тряски тоже увеличился.
10. Подключение других сонаров и настройка сонаров для совместной работы
Поскольку звук имеет свойство отражаться, чтобы отраженный сигнал от одного сонара не улавливался другим, я опрашиваю сонары последовательно.Максимальная частота опроса используемых гидролокаторов – 20 Гц; получается, что если опрашивать сонары последовательно по очереди (а их 5), то каждый будет опрашиваться с частотой 4 Гц.
Короче говоря, благодаря хитроумному алгоритму, суть которого заключалась в том, чтобы реже опрашивать «неинтересные» сонары (например, задние при движении вперед) — я получил 5 Гц (5 раз в секунду — это в принципе неплохо!)
По поводу стабильности были следующие мысли: 
Очевидно, что чем чаще опрашиваются сонары (чем выше частота опроса), тем точнее можно позиционировать коптер, но важна не только частота, но и время отклика системы (время отклика) или задержка между прямыми измерение, например, расстояния до стены и воздействия на двигатели с учетом измеренного расстояния.
Насколько быстро текущая система реагирует на полученные значения, как быстро (за какое время) дрон отреагирует на измерение - подает управляющий сигнал двигателям, после расчетов ПИД отправляет данные с автопилота на полетный контроллер и считывает расстояние от датчика? 
Нетрудно представить такую ситуацию, например, если бы информация с видеокамеры поступала в наши глаза (через монитор или очки) с задержкой в 1-2 секунды, легко ли было бы двигаться, несмотря на то, что частота осталась бы 25 кадров в секунду? Вам придется идти очень медленно, чтобы не упасть.
Ну, а что, если попробовать пройтись таким образом, например, по канату? Вот еще пример: сигнал лунохода с Луны приходит с задержкой в 3 секунды, а с Марса это время измеряется минутами, и управлять им с земли просто невозможно (иначе скорость марсохода была бы очень , очень медленно).
Рассчитаем время отклика получившейся системы дронов: 
ОБЩАЯ задержка предварительная: 3.29+0+25+2+14=44.70 мс.
Подробное описание: 1) После того, как на эхолот подается сигнал измерения расстояния (триг), ультразвуковой модуль излучает ультразвуковой сигнал, проходит определенное время, пока звуковой сигнал не вернется после отражения от препятствия.
Это время фиксируется в датчике эхолота и выводится через аналоговый или цифровой выход датчика.
2) Так как я использовал цифровой выход (Эхо) гидролокатора, на котором формируется сигнал (+) путем приема отраженного эха, то он регистрируется сразу на контроллере автопилота (по прерыванию) - по сути, передача сигнала измеренное расстояние происходит без задержки, в отличие, например, от варианта передачи по UART или I2C, когда при получении эха контроллер гидролокатора должен был бы передавать данные последовательно, а контроллер автопилота должен был бы их принимать.
3) Значение, полученное контроллером автопилота, рассчитывается и фильтруется.
Рассчитанное расстояние до стены или пола «подается» на ПИД-регулятор автопилота для удержания от стены или пола.
В результате он получает новое значение для управления коптером по крену (Roll), тангажу (Pitch) и газу (Throttle).
4) Полученные значения управления (Крен, Тангаж, Дроссель) передаются через порт UART на полетный контроллер (MultiWii).
5) Контроллер полета считывает данные в кольцевой буфер и через определенное время (50 раз в секунду) «скармливает» их ПИД-регулятору (который, по сути, является системой стабилизации multi wii), после чего новые значения Управляющие воздействия являются смешанными (в зависимости от схемы летательного аппарата (квадрокоптер, гексакоптер и т.п.
) и подаются на контроллеры двигателей.
Поскольку последовательный цикл опроса гидролокатора составляет 20 Гц, время, которое можно потратить на каждый гидролокатор, составляет не более 50 мс.
На определение расстояния эхолотом уходит до 29 мс, что оставляет 21 мс на расчеты (фильтры, алгоритмы ПИД и выбора пути).
Этого времени (21 мс) оказалось недостаточно для медленного 8-битного контроллера, поэтому был придуман вариант, где управляющие воздействия от предыдущего значения сонара рассчитываются с интервалом 50 мс, а значение текущего сонара просто прочитайте текущий цикл.
Такое решение увеличило время отклика системы на 50 мс, но позволило ей существовать в такой низкопроизводительной аппаратной конфигурации.
ОБЩАЯ задержка (лаг) = 44.70 мс + 50 мс = 94.120 мс, по сути эта задержка является реакцией текущей системы на измеренное расстояние.
Очевидно, что чем медленнее отклик, тем менее стабильно устройство будет вести себя при любой частоте дискретизации ПИД-регулятора и датчика.
То есть стабильность работы устройства зависит не только от частоты опроса датчиков, но и от «реакции» системы самолета на измеренное расстояние (значения задержки или время срабатывания).
11. Возможная оптимизация
Как можно уменьшить значение лага в нынешней системе? Варианты оптимизации:
1) Использование более быстрого контроллера для автопилота, например AWP (172 МГц 32 бита) значение составляет 25 мс – оно включает расчет расстояния и ПИД-регулятор с передачей может быть уменьшено до 2 мс (-23 мс).
Благодаря этому можно было бы читать и производить вычисления за один цикл опроса, а это за другой (- 50 мс) ОБЩАЯ задержка (лаг) при оптимизации = 94.120 мс – 23 мс – 50 мс = 21.47 мс 
2) Еще более выгодное решение, если полетный контроллер и автопилот будут одним быстрым контроллером или компьютером, схема будет еще быстрее, так как можно будет сэкономить время на передаче информации от автопилота к полетному контроллеру, а также увеличить частоту работы системы стабилизации полетного контроллера (в MultiWii эта частота составляет около 300 Гц)
12. Автономное подвешивание (расстояние удержания от стен + высота удержания)
После того, как вам удалось выдержать высоту по сонару и более-менее выдержать дистанцию от одной из стен, можно было прикрепить 3-й эхолот к левой или правой стороне коптера и научиться висеть в помещении в автоматическом режиме.
Но коптер болтался на каждой оси и в итоге закрутился против часовой стрелки, набирая амплитуду.
Минусом было также то, что дрон «вяло» сохранял свой курс (ось Yaw), особенно сильно аппарат крутился возле стены.
Также, переходя от одной стены к другой, аппарат немного терял высоту, затем тормозя перед стеной, пытался набрать высоту, тем самым почти стреляя в противоположную сторону.
При установке больших значений ПИД для рыскания прибор старался максимально выровняться в момент вращения возле стены, работая таким образом почти на двух диагональных моторах (особенность управления многороторными системами по оси рыскания).
), он потерял управляемость (так как по факту в квадрокоптере крутилось только 2 мотора из 4-х) и влетел в стену.
Много времени было потрачено на стабилизацию аппарата по курсу (ось рыскания), выбор ПИДов автопилота и контроллера полета.
Нам также пришлось придумать пару приемов поведения устройства, чтобы предотвратить раскачивание.
Результатом стало более-менее стабильное поведение:
13. Навигация по лабиринту
Для прохождения конкурсной площадки не нужно было использовать сложные алгоритмы и строить карты; Подошел простейший алгоритм прохождения лабиринта — «правило правой руки».Я его немного модифицировал и сделал на конечном автомате.
Если кратко, суть заключается в нескольких простых правилах движения: 
Чтобы переместить дрон вперед/назад/вправо/влево, автопилот посылает полетному контроллеру соответствующие команды, чтобы наклонить платформу в нужном направлении.
Если стены по направлению движения не «видны» с сонара, то платформа наклоняется на 5 градусов (угол я подбирал вручную).
Чтобы дрон не ускорялся, он через определенные промежутки времени принимает горизонтальное положение и движется по инерции (не наклоняясь ни в какую сторону).
Кроме того, для грубого контроля скорости я использовал GPS-приемник; при обнаружении скорости, превышающей критическую скорость (она также была выбрана опытным путем), дрон замедляется, то есть отклоняется в противоположную от направления движения сторону.
Чтобы двигаться в радиусе действия датчика расстояния – эхолота, просто измените расстояние удержания от стены.
14. Обнаружение маркеров точки приземления.
На дрон была установлена камера, а изображение через видеопередатчик передавалось на ноутбук.
И далее, если маркер был идентифицирован (распознан), то данные об экранных координатах маркера передавались на автопилот через радиомодем.
На основании полученных данных автопилот рассчитал расстояние до «цели» относительно коптера и видимых стен (подробно описано в пункте 3).
Затем он попытался удержать эту дистанцию, и была активирована программа приземления, заключавшаяся в медленном снижении высоты висения.
В финальной версии робота удалось реализовать механизм поворота камеры (камера вращалась вверх и вниз по оси Pitch).
Таким образом был организован механизм сопровождения цели, и при подлете к крестовине камера поворачивалась вниз, удерживая в фокусе камеры центр посадочной площадки.
Таким образом, увеличивалось время «сопровождения цели», а, следовательно, и точность приземления.
Распознавание перекрестного маркера в круге осуществлялось с помощью Open CV, использовался алгоритм поиска пересечения прямых, эту работу проводил отдельный человек в команде, который подключился к работе на последних этапах проекта, поэтому не мог быть включен в список участников (по правилам организаторов конкурса).
15. Поездка в Москву.
Пройдя все контрольные пункты для участия в соревнованиях, наша команда была допущена к участию в финале.
На момент поездки в новой платформе на базе гексакоптера еще не все было готово, поэтому последние приготовления было решено провести в Москве на полигоне.
В ходе испытаний был завершен испытательный полигон.
Соревнования были разделены на 2 дня, некоторые фотографии можно посмотреть на сайте организаторов .
Перед стартом: 
Место ожидания на стоянке.
Первая попытка нашей команды оказалась неудачной; робот пролетел, но зацепился за забор и задел пол, но взлетел и смело вернулся обратно.
Во второй попытке с навигацией все прошло хорошо, робот не задел стены, но и не приземлился на посадочные маркеры, хотя на базовой станции на ноутбуке маркеры хорошо распознавались.
И после конкурса у нас получился почти идеальный вариант полета, с посадкой туда-обратно.
Полученные результаты
В нашей команде над проектом летающего робота работали 4 человека.Один человек отвечал за распознавание, один был отличным специалистом по языку C и хорошо разбирался в AVR-контроллерах, консультировал в трудные моменты проекта.
Я, как капитан команды, проектировал дроны, программировал и тестировал их; моя жена взяла на себя организационные вопросы во время поездки в Москву.
Также для тестирования робота необходимы помещения – испытательные полигоны.
Спасибо друзьям, предоставившим свои дома, гаражи и офисы.
Несмотря на, казалось бы, небольшой результат, работы было проделано очень много.
90% времени было потрачено на изучение чего-то нового, организационных вопросов, тестирования и преодоления трудностей, без которых проект не продвинулся бы вперед. Конкурс 2013 года привлек множество Теги: #роботы #летающие роботы #сделай сам #Алгоритмы
-
Что Вам Нужно Знать О Сетевом Тестировании
19 Oct, 24 -
Анализ Отчета Сергея Куксенко С Jpoint 2016
19 Oct, 24 -
Нет, Ваш Мозг Работает Совсем Не Так.
19 Oct, 24 -
Эпоха Плоских Потолочных Микрофонов
19 Oct, 24 -
Команда Автоматизации Тестирования Unity 3D
19 Oct, 24
