Activity

Ога, польщен.

😉

Где есть?

Я имел ввиду что единственная ресурсоемкая задача для которой нужен FPU это какой-нибудь большой Калман.

За фриртос респект. Однако код местами кажется очень знакомым. Ну и ладно.

Да, и еще, чем обусловлен выбор пик32? Неужто он сделает стм32ф4?

Это сложилось исторически. Делали с коллегой мелкий модуль на ARM Cortex M3 Stellaris www.oshec.org/projects/ucpumod-v1/wiki потратили на него кучу времени и денег, а потом внезапно выясняется что проц снимают с производства хотя ему от силы 3 года. На форуме TI был эпичнейший срач по этому поводу. Поэтому стал смотреть в сторону микроконтроллерных фирм которые выпускают свои МК оооочень длительное время. А тут еще платку на попробовать подарили на этом проце, вот и начал.

ПИК мы вроде уже начали обсуждать. МИПС это конечно хорошо , но плавучий вычислитель на борту ИМЕННО экспериментальной платформы нужен обязательно, ибо пока ещё не известен объём вычислений, да и было бы не правильно, если хорошая идея (но тяжелая вычислительно) не сможет быть опробована сразу.

Из тяжелых задач именно полетного контроллера пока есть только Калман, думаю что для этого текущего МК хватит. Если не хватит ничего не мешает перейти на новую серию PIC32MZ, там уже 200МГц проц.

Про датчики СергДок уже писал, аксель в ЛСМ гмо-шный, лучше ставить MPU6xxx или 9xxx. Как только будут первые полёты убедитесь сами.

Текущий вариант будет на том что есть, новый вариант с новым процом датчики буду выбирать, может MPU будет, может MAX.

а где в описании самое главное, на чем основано “без участия человека”? уже имеется скриптовый язык, набор жестко заданных состояний, полный искусственный интеллект или что-то еще?

Это цель к которой я иду, когда он будет хорошо летать можно подумать и про скриптовый язык внутре и пр. вещи.

Завершил чтение этой длинююющей темы и предлагаю к обсуждения свой проект по созданию автопилота. Предназначен для робосамолетов, робокоптеров и пр. роботов т.е. передвижение без участия человека.

Немного опишу состав и текущее состояние дел:

• Захват 8 каналов PPM от приемника радиоуправления (работает 4 из 8)
• Выдача управляющего PWM сигнала 12 каналов, 4 аппаратных и 8 программных (работает 11 из 12)
• PID регуляторы на крен и тангаж (работает)
• Датчики МЕМС 3D акселерометр, магнитометр, гироскоп (работает, данные обновляются с частотой 100Гц)
• Барометрический высотомер (работает)
• Последовательный порт для подключения радиомодуля и передачи телеметрии протокол MAVLink(работает)
• Последовательный порт для GPS/GLONASS приемника (еще не работает)
• Последовательный порт для доп.устройств (еще не работает)
• 13 каналов для УЗ и ИК дальномеров (еще не работает)
• Локальное хранилище “черный ящик” на базе microSD карты (еще не работает)
• Габариты 80х55мм
• Питание +5В от USB, +5В от внешнего источника, +8…+22 от внешнего источника

Описание и тех. информация по проекту живет здесь

www.oshec.org/projects/pi-pilot/wiki

Персонально Drinker-у полностью свой проект автопилота на своем железе.

Давно ПИКи в руках не держал, раньше их использовали только там где нужно было низкое энергопотребление и устойчивость к помехам. Ну а система команд и архитектура для программера просто дикая…

Это вы о старых PIC-ах говорите, которые PIC8, PIC16, PIC24. Новые PIC32 архитектура правильная - MIPS с кучей плюшек и прочего. Предлагаю обсуждение перенести в тему по про свою систему стабилизации, здесь все же основное про конкурс. Я как оставшиеся 70 страниц ее прочитаю чтобы быть в теме отпишу там и обсудим.

Аксель и барометр меняйте сразу… проц…, а чем чёрт не шутит… FPU там есть?

Схему буду немного переделывать менять акселерометр на LSM303D и барометр на MS5611. Процессор пока менять не планирую. Нет, FPU там нет.

Это все очень печально и чтобы результат работы за 1.5 года не выбрасывать в корзину, открываю свой вариант автопилота как OpenHardware: схема, код, прошивка и выкладываю у себя: www.oshec.org/projects/pi-pilot Автопилот по прежнему продолжаю делать, это вызов: хватит ли мозгов и упорства сделать хороший автопилот. Некоторые в горы идут покорять 9-ти тысячники, моя гора вот такая.

Поддержу идеи WETErok и boris_notkin. Надеюсь организаторы не бросят затею с конкурсом.

Побеждает команда телезрителей

Приз уходит в зрительский зал?? 😉

Поэтому мы и не стали жестко смотреть на презентационные полеты. Если бы команд было больше, картина была бы другой.

Я это и имел ввиду, все кто участвовал и прочитал новые правила, реально оценили свои силы и отказались подавать заявку. Внезапно конкурс стал под угрозой провала, поэтому такое резкое смягчение. ИМХО лучше было продлить срок регистрации и объявить о смягчении публично, было бы больше команд.

Будем думать, да.

Придумался еще один вариант конкурса, то же самое разбиение, только не три отдельных, а три этапа одного конкурса. Первый этап, задание предыдущего года, второй этого, третий максимальный. Прошедшие этап переходят к следующему, призы так же за этапы, первой тройке. Плюсы такого варианты, дроны должны уметь выполнять задания от самого простого к сложному, команды пройдя один этап и провалив второй увидят в чем у них проблемы.

Правильно запиленая телеметрия выглядит как-то так:

Правильный вариант конечно слить zip архив и построить новый. А вообще надо зайти в просмотр hex файла, когда он полностью прогрузится, выбрать справа вид raw, на экране останется только прошивка, нажать Ctrl+S и сохранить все в файле.

Уважаемый WETErok прав, ни один из роликов не демонстрирует выполнения граничных условий участия. Думаю причина в том, что на конкурс заявилось катастрофически малое количество. Если в прошлый раз было около 500 команд. то сейчас 5. Усложнение условий и уменьшение приза сыграли свою роль. Предлагаю на следующий раз немого изменить конкурс:

Разбить его по сложности на две части.
Часть 1 легкая. аналогично прошлогоднему конкурсу, но засчитывается время меньшее чем у предыдущего финалиста. Финалисты прошлых конкурсов до него не допускаются.
Часть 2 средняя. условия текущего и следующих годов
Часть 3. невыполнимая, задание максимальной сложности

Этим можно добиться притекание свежих кадров и идей в более легкую часть и постепенной ее миграции в более сложные. Приз поделить например 30/70

Сделал специальный проект под IDE MPLABX 2.0 и дев.борду chipkitMax32. В нем интегрированы FreeRTOS и MAVLINK.

gitlab.com/pitman/chipkitmax32-mavlink/…/master

Может кому пригодится.

В этом году не участвуем, но и не бросаем. Т.к. изначально собирались делать свой автопилот, то и продолжаем его делать. Уже пробуем летать, но пока только на безмоторном планере, для отладки алгоритмов и пр. Надеемся успеть к конкурсу следующего года.

P.S. Уважаемый организатор изменив сумму награды отобрал мечту (это образно). Останутся самые упертые.

Фух, как камень с души сняли. А то я уже самое страшное подумал.

Больше велосипедов хороших и разных? Нее, использовал хорошую либу, сэкономил себе кучу времени. С протоколом поразбирался, считать CRC научился, нормально.

Дмитрий, ты сам что ли имплементируешь Mavlink?

Сначало хотел сам, потом попробовал и стандартная библиотеке С mavlink нормальна собралась и заработала на моем контроллере. Поэтому использую готовую библиотеку, даже ничего переделывать не пришлось. Контроллер у меня PIC32MX795F512L

Интеграция MAVLINK оказалась не такой уж и сложной. На тестовой системе сделал отправку пока 9 сообщений протокола, наземная часть - программа QGroundControl их нормально воспринимает и отображает.

Сдвинулся с мертвой точки. Запустил передачу данных через последовательный порт, подключил устройство к ПК, скачал программу QGroundControl, нашел дамп самого простого пакета heartbead, сделал чтобы этот дамп отправлялся раз в секунду в последовательный порт. QGroundControl пакет опознал, считает что связь с автопилотом установлена. Сейчас разбираюсь почему у меня не получается контрольную сумму правильно посчитать.

Народ, кто-нибудь пробовал добавить поддержку протокола Mavlink в свои самоделки?? Сейчас занялся этим и есть несколько вопросов.

Сделал захват и декодирование 4-х PPM каналов. Период и правда не стал считать.

че то сомневаюсь в целесообразности сих извратов при футабъем приемнике…

1. Приемники будут любые, не только Futaba
2. Сам в некоторых сомнениях поэтому и затеял это обсуждение

Еще один вариант делать калибровку аппаратуры РУ при ее смене. Выставлять минимум, максимум длительности импульса и период.

А что кодируется периодом? По моим понятиям длины импульса вполне достаточно чтобы понять, что идет на серву… Некоторые коптероводы и 400 Hz запихивают на регулятор - и вполне щасливы…

Ну вот примерно для такого случая, чтобы можно было декодировать и 400Гц управление, опять же уплыла частота приемника от температуры - поплыли длительности импульса и периода пропорционально, подсчет периода решит эту проблему.

А зачем кадр то, все каналы как бы независимы…

Это нюанс реализации декодера. Можно решить задачу в лоб, сделать перывание от таймера 100кГц и с разрешением 100мкс считать длительность импульсов, результат счета будет где-то от 0 до 127-150 в зависимости от ширины. Минус такого подхода, жрет 20% ресурсов контроллера. Поэтому решил взять другой вариант. Обработка прерывания от портов ввода-вывода при изменении состояния. Прерывание от портов сработало, таймер запущен. Таймер тикает 4 МГц, с разрешением 250нс, полный период 26мс. Сработало второй раз прерывание на том же порту, считываем показание счетчика таймера и получаем искомую длину. Но помимо длинны надо еще период, поэтому счетчик таймера продолжает тикать дальше. Снова прерывание, закончили считать период. Вроде бы и можно обнулить счетчик таймера, но беда в том, что на другом канале может идти импульс в это время и надо искать когда данные всех каналов прошли. Это вызывает некоторую сложность в реализации декодера, пока этого хочу избежать.

Теперь декодеры на МК даже для аналогового SUM-PPM дают выход так, как удобно программеру… Никаких стандартов тут нет, лишь бы машинки шевелились.

Ясно, спасибо за помощь. Самая большая сложность на мой взгляд, это определение начала кадра, если нет устоявшегося стандарта с какого канала начинается кадр управления, то или автоматическое определение по каким-то критериям или ручной выбор какого-то канала начало импульса на котором будет означать начало кадра. У себя сделаю выбор ручной.

Для футаб и цифры может прощще SBUS декодировать?

Надо работать с тем что есть, почитал про SBUS дорогое удовольствие да и в общем не нужное. РУ будет чем-то вроде джойстика показывающего направление движения. Все руление плоскостями и моторами будет делать автопилот.

а никто не гарантирует, что из выходных импульсов удастся собрать суммарный РРМ сигнал.

Собирать его и не планировал, хотя и в этом проблем нет если использовать микроконтроллер. Надо перевести ШИМ от импульсов в цифровую величину. Просто в случае когда импульсы лесенкой и с первого канала начинаются парсер получается попроще.

Наш автопилот понемногу начинает летать, правда пока только на безмоторном планере. Добрался до декодирования PPM сигнала. В наличии РУ Futaba T6EX с приемником R617FS. Почитал теорию, вроде все понятно, приемник 7 канальный, значит параллельно 7 каналов импульсы будут идти начиная с 1-го канала и лесенкой. Подключаю логический анализатор и что же видим? Кадр начинается с 7-го канала, импульс на 6-м канале идет с перекрытием в начале с 7-ым и в конце с 1-ым. Вопрос, кто знает почему так? Как у остальных приемников, кто виноват?

Строю автопилот для полностью автоматического БПЛА, добрался до декодирования PPM сигнала. В наличии РУ Futaba T6EX с приемником R617FS. Почитал теорию, вроде все понятно, приемник 7 канальный, значит параллельно 7 каналов импульсы будут идти начиная с 1-го канала и лесенкой. Подключаю логический анализатор и что же видим? Кадр начинается с 7-го канала, импульс на 6-м канале идет с перекрытием в начале с 7-ым и в конце с 1-ым. Вопрос, кто знает почему так? Как у остальных приемников, кто виноват?

В таком случае эта помеха должна быть из чего-то покрепче мяса и костей.

А камера на что? Будет чем отбиваться от спятившего дрона. Опять же экшен и интрига, кто и кого…

Оператор, безусловно, позволит улучшить картинку. Но он сам будет передвигающейся помехой.

Вполне возможно что новое задание содержит в себе такое условие выполнения, т.е. обходить движущиеся помехи.

Поздравляем победителей!!! Молодцы!!!

Большое спасибо всем участникам и организаторам за кучу положительных эмоций и развитие своего проф.уровня.

Ждем видеозаписи конкурса и условия конкурса на следующий год.

С уважением, Дмитрий.

Или вообще никто…

Вопрос как раз по этому пункту. Если вдруг ни одна команда не сможет выполнить задание в полном объеме, будет ли усложнение задания на следующий год как планировалось?

Не очень понятно, зачем вертолету 32 PWM на базе pic32… по идее 6-8 это предел. И как сервоконтроллер не очень и как полетный контроллер тоже… ну поговорка ни рыба ни мясо тут прямо в кассу…

Ну читайте же внимательней, я же написал что в пределе и что можно разбить под задачи на нужное. Как можно понять из фото, для захвата выделено 8, аппаратный ШИМ отдельные 4, ШИМ через мультипликатор еще 8, остальные 11 для аналоговых и цифровых дальномеров. Дополнительно 3 аппаратных UART с сигналами #RTC/#CTS для подключения любого передаткика, ГПС и т.п.

Просто применение его может не ограничиваться только ветролетаси, можно и робо-паука собрать и т.п.

Если нравятся пики, то типа такой платы www.sparkfun.com/products/11115 можно было сразу взять и прошивать ее

Не спорю, можете взять что угодно и использовать. У нас свои мысли по этому поводу.

Добрый день всем!

Наша команда тоже выбыла, в процессе отладки ПИД регулятора и подбора коэффициентов для него доломали последние винты. В городе таким никто не торгует, ждать долго 😦.

Из результатов, забацали полетный контроллер на базе PIC32MX, в пределе может рулить 33 сервами либо разбить нужное под задачи. Прямо сейчас он работает только в режиме наездника, будем допиливать до полноценного автопилота.

Может кому-нибудь будет интересно.

С уважением, команда Baraholko75RU, Дмитрий.