OSD на ATmega1281
Лучше туда не лезь…
Я программирую PIC процы. Как посмотрел что там Сергей написал, такое ощущение что инопланетяни писали алгоритм… Страшно стало…
Посмотрим, что дальше будет. Как эта прошивка полетит, и тогда может быть…
Народ, напомните пожалуйста. В конфигураторе в меню “Доп. каналы” выставленные каналы работают как ранее (типа для управления пантилтом камеры с замиранием в центре при отсутствии изменения канального импульса)? Или что то изменилось? Если изменилось, то с какой версии прошивки?
Или что то изменилось? Если изменилось, то с какой версии прошивки?
По моему с ver 2.9, РРМ идёт постоянно. Только у них разрешение по хуже чем у остальных с 1 по 4.
у остальных с 1 по 4
Наверное имелось в виду с 1 по 3? Или я снова что то пропустил? АП управляет 4-м каналом (направлением)?
Да с 1 по 3. И + эти два дополнительные 4 и 5. Которые можно переназначить в конфигураторе. 4 и 5 это условно.
А вот это уже хорошо. У меня приемник РУ в хвостовой балке, я тогда сигнал на машинки пантилта камеры пущу с ОСД. Сильно ниже разрешение на этих двух доп. каналах?
Сергей точнее скажет. Но для камеры пойдёт или для закрылков тем более.
Но для камеры пойдёт
Тут то как раз на камеру хочется, чтобы все плавнее работало. Подожду, что Сергей (msv) скажет.
с замиранием в центре при отсутствии изменения канального импульса
Серва не уходит в центр, а остается в последнем положении без удержания (PWM просто отключается). Мои сервы при удержании, даже от ветровой нагрузки на камеру, давали дрожание, заметное на картинке. Когда игрался с пантилтами, мне нравилось, как это работает. По просьбе Сергея (ubd) будет убрано.
Для оценки достаточности разрешения (мне хватало) воткните серву и сравните с нормальным каналом.
Я думаю там нормальное разрешение канала, если будет 256 квантов (ну или как правильно?), этого достаточно.
Тем более, я хочу закрылки сделать.
Я пришёл к выводу, по поводу пантилта. Летаю на БПЛА уже два года, и ни разу им не пользовался, хотя стоял и азимут и элевация. В этом году, поменял камеру на Pixim и сделал только азимут (на всякий случай, на канал руля поворота), элевация фиксированная. Это если вы хотите использовать Хэд-трекер, то можно попробовать. Но его есть смысл использовать только с очками. Но у меня ноутбук в качестве монитора.
Ещё канал остаётся на закрылки.
если будет 256 квантов (ну или как правильно?), этого достаточно.
В интервале 1-2мсек 78 шагов. Вроде мало… Для хода обычной сервы разрешение получается около 1 град. Вроде бы и не так плохо… На своих сервах разницы практически не замечаю, у них разрешение явно хуже даже этой точности…
Это если вы хотите использовать Хэд-трекер, то можно попробовать. Но его есть смысл использовать только с очками.
Да - летаю в очках. Пользую трекер на ардуинке+ИМУ - прекрасно работает. Без него теперь даже летать немного неудобно.
Да - летаю в очках. Пользую трекер на ардуинке+ИМУ - прекрасно работает. Без него теперь даже летать немного неудобно.
А ссылочку на это можете дать? Или это полностью Ваша разработка?
Приветствую!
Да простят меня авторы прошивок, в которые я запустил свои клешни, а именно, Сергей msv, baychi, kha, но уж очень захотелось проверить качество радиоканала этих прошивок на одном железе.
В общем, началось с того, что сделал я плату передатчика под RFM23BP, залил хекс и на мое удивление прошивка Сергея v11 без проблем заработала. В v13 пришлось поменять значение AFC limiter на приемнике.
rfm_wrch(0x2a, 0x28); // AFC Limiter, rx only 0x0e - у msv //у kha это значения 0x1e 0x24 0x28 для разных скоростей обмена
И тоже нормально запустилось. Но только на одном модуле. Второй передатчик на отрез отказывается нормально работать. Если поставить обе частоты передачи одинаковыми и смотреть в терминале, то флаг valid меняется постоянно с 0 на 1. Если поставить частоты разные, то valid = 1 встречается в 2-3 раза реже (не помню уже). С подстройкой частоты наигрался вдоволь. Ну может до лета разберусь.
Это и породило желание копнуть дальше и адаптировать другие прошивки под проект АП. Адаптация свелась к переназначению ног и конвертации значений по каналам управления с последующей выдачей их в последовательный порт.
Немного затронул этот процесс и железо. Прилепил 16МГц кварц на приемник и передатчик. Само собой, для kha и baychi нужна atmega328.
Итак, прошивка openLRS от kha работает с программой конфигурации, сканер частот тоже, да и остальные функции. Но мапинг выводов приемника не проверял. Так как все равно эксплуатация LRS предполагает подключение к АП по 4м проводам. Замечена такая же проблема - с использованием одного из передающих модулей (того самого) - довольно часто приемник переключается на следующий канал.
Прошивка openExpert от baychi. Пришлось перенести порт подключения к АП на выводы D4 - RX, D2 - TX, чтобы сохранить возможность настройки через терминал и получения статистики. Выводы разведены у Сергея на плате как раз рядом с UART, так что плата без изменений. Эта прошивка запустилась и с проблемным передатчиком и работает вообще без нареканий. Правда пришлось поменять смещение кварца передатчика, так как рекомендовали в теме
Так что, желающие потестировать могут присоединяться. Архив
А ссылочку на это можете дать? Или это полностью Ваша разработка?
Ссылочку можно. Нет разработка не моя. Я только адаптировал формфактор, чтобы в Доминаторы на штатное место вставал. Да простят меня за оффтоп.
Ну и по теме. Народ напомните, в какой версии прошивки был подправлен алгоритм автоматического взлета?
По мануалу в первом подрежиме (отрыв) АП курс не отслеживал до поднятия флага “полет”. Что то в этом плане поменялось? Я почему спрашиваю. Прикорячил я тут стойки шасси к самолету (с носовой стойкой). Интересно как будет работать автоматический взлет. По мануалу получается так, что АП переводит газ в положение «Газ-Макс газ» в момент переключения тумблеров в режим Takeoff. Правильно ли я понимаю?
Эх… писал, писал ответ… Нажал бэкспейс… почему то вместо символа стерлось все произведение… 😦 Попробую повторить…
Константин, очень жаль что не удалось запустить мою прошивку.
Про подстройку частоты кварца Александр (baychi) не совсем правильно написал…
Смотрим datasheet на RFM22B, глава 5.8:
Суммарная емкость конденсаторов, корректирующих частоту, при сброшенном старшем бите равна: 1.8pF+значение в младших 7-разрядов*0.085pF.
При установке старшего разряда, дополнитено подключается 3.7pF, что не является бинарным дополнением к младшим разрядам.
В конфигураторе можно установить соответствующие значения для приемника и передатчика “Cristal calibration Rx/Tx”. Контролировать частоту удобно частотомером, подключенным к тактовой ноге меги и добиваясь ровно 15мГц последовательно на приемнике и передатчике.
У меня получилось для приемника 7A ( 1.8pF+122*0.085pF=12.17pF) и D1 для передатчика ( 1.8pF+81*0.085pF+3.7pF=12.385pF).
Есть одна проблема- если резко изменить где нибудь частоту, перестает работать бинд и изменить значение в приемнике становится невозможно. Поэтому возможно прийдется делать последовательное приближение от исходных 7F (12.595pF).
По мануалу в первом подрежиме (отрыв) АП курс не отслеживал до поднятия флага “полет”. Что то в этом плане поменялось?
Непомню как было, но сейчас это так… Вызвано тем, что используется только GPS-курс, в первые секунды он неопределен.
Для взлета с шасси делайте правильный развал/схождение… 😃
По мануалу получается так, что АП переводит газ в положение «Газ-Макс газ» в момент переключения тумблеров в режим Takeoff.
Было (в опубликованных версиях) так. Сейчас отдельный параметр.
По мануалу получается так, что АП переводит газ в положение «Газ-Макс газ» в момент переключения тумблеров в режим Takeoff.
Да сразу. И сейчас сразу, только сейчас можно, взлётный газ выставить отдельно любой.
И вот по вопросу, что АП даёт сразу макс газ, при включении Takeoff. Для меня это не удобно. Ведь теперь с такой посадкой, нужно отойти от машины, метров на 10, а пульт у меня к LRS на проводке, нет ретранслятора. И получается я буду идти по полю 10 метров с включенным мотором на 100%. Появилась идея, подтверждать автовзлёт, кнопочкой на АП. Там есть свободная одна кнопка, её можно нажать и подтвердить взлёт. т.е. сначала на передатчике включаем тумблерами режим Takeoff, потом отходим в сторону сколько нужно, и по нажатию на кнопочку, начинается собственно сам режим взлёта.
Такая идея. Сергей сказал, что подумаю.
Непомню как было, но сейчас это так… Вызвано тем, что используется только GPS-курс, в первые секунды он неопределен. Для взлета с шасси делайте правильный развал/схождение…
А АП в этот момент не котролирует борт? он должен и подрулить при разгоне… по идее…
А АП в этот момент не котролирует борт?
Руль направления он не контролирует. А на полосе только он эффективен.
АП в момент взлёта, просто держит крен в ноль, а тангаж вверх, но с задержкой.
сначала на передатчике включаем тумблерами режим Takeoff, потом отходим в сторону сколько нужно, и по нажатию на кнопочку, начинается собственно сам режим взлёта.
Ну тут как бы не всем наверное будет удобно. С рук взлетать - понятно. Если речь идет об использовании второй кнопки, то я ее вообще не ставил.
Если такую ф-цию делать, то хорошо бы, если бы была возможность ее отключения.
А АП в этот момент не котролирует борт? он должен и подрулить при разгоне… по идее…
Руль направления он не контролирует. А на полосе только он эффективен.
Тут мои мысли прям сами озвучиваются, но другими пользователями. Хотел предложить задействовать еще и канал курса (направления) - но только для стабилизации (рулить им не обязательно, а вот стабилизировать модель на взлете и FBW - ИМХО актуально).
Тут мои мысли прям сами озвучиваются, но другими пользователями. Хотел предложить задействовать еще и канал курса (направления) - но только для стабилизации (рулить им не обязательно, а вот стабилизировать модель на взлете и FBW - ИМХО актуально).
Об этом и речь:) впринцыпе если оч нада а пока нет такой “фичи” можно гир от вертушки воткнуть;) и рулить им через доп канал… ? хотя как штатную функцию “удержание руля направления” былоб здорово.