Включение/выключене с 1 канала нескольких нагрузок. Возможно-ли?
если мы крутим панораму, а вместо этого выбрасывается парашьют.
Да, эт жестокий облом …
У Козина вполне логичное решение - пока несколько пакетов одной команды не придут - я (как взрослый дешифратор) считаю их провокацией или помехами. Мудро, тем более пилот и подождать может десятую долю секунды, пока ноги начнут срабатывать.
Обратная связь (контроль) - это идеальное решение, но на “стандартно заряженом” копе уже куча сосисек - 2,4 приёмная антенна, 5,8 ФПВ передающая, и 915 телеметрия. В неё, конечно, бы подмешать , но эт уже серьёзная засада … Да и не к чему, наверное :
Переключение камер видно на ФПВ .
Посадку - по ногам и подсветке прожектором зоны посадки.
А вот “готовность к выполнению”, т.е. переключение на критичные исполнительные ус-ва, ПЕРЕД их срабатыванием, можно и подсветить, например.
Камерые повороты - зелёным - да и по камере увижу, куда повернулась. Трансфокацию - быстрое мигание зелёного.
Парашют или маячёк - красным.
Есть ещё синий и жёлтый и их мигание - быстрое и медленное.
Срабатывание стробоскопа и так ночью - вечером видно.
Тогда алгоритм “пилотирования” видится таким -
1многопозиционным переключателем (например) выбираем устройство (а дешифратор ждёт выдавая на “виртуальные каналы” сигналы “по умолчанию-старту”);
2даём контрольное нажатие - выбранный дешифратором “виртуальный свободный канал” моргает своим цветом - “я жду”;
3даём команду, а при необходимости добавить , например приближение или панараму, добавляем команду ещё раз;
4 разбегаемся.
Я тут сегодня думал и пришёл к выводу, что выдавать цифровой код через одно место это не ГУТ (сперва шимом передать напряжение на вход передатчика, потом передатчик должен это передать длиной импульса, потом приёмник принять и декодер декодировать), причём обратной связи нет, для надёжности нужны большие задержки, чтоб все элементы цепочки успели отработать, ещё добавить биты контроля. Получается на одну команду управления около 1 секунды. Включить свет или камеру ещё можно, но управлять движением камеры в реальном времени …
Пока видится такое решение.
Во первых хочется устройство многофункциональное и универсальное, а не заточенное под конкретный пример.
Во вторых сам я в управлении коптерами ни бум-бум и всех возможных задач не знаю, но то что тут набросали уже что-то.
У меня вырисовывается такая загогулина.
Берём 2-а пропорциональных канала на передатчике (2-е крутилки) и вместо них подрубаем Кодер.
На приёмнике к соответствующим каналам подрубаем Декодер.
По одному каналу будет передаваться адресация выхода на декодере, по второму каналу режим работы адресуемого выхода.
По функционалу кодера и декодера кое какие мысли есть. Ещё надо немного подумать и завтра/послезавтра опубликую тут свои соображения. Приветствуется критика и разные советы.
В общих чертах:
Пока кодер и декодер предполагается делать на тиньках 2313 т.к. они широко распространены и они есть у меня 😃.
Кодер ограничен 17 ногами (20 минус 2-питание и 1-reset) 2-ноги выход (U) на управление каналами. Для пропорционального управления каналами на декодере выдающими ШИМ хочу использовать энкодер - ещё 2-е ноги.
Итого 13 ног для подключения кнопок.
На декодере тоже 17 ног минус 2 ноги - входы для подключения каналов с приёмника и минус 2-е ноги для подключения кварца (чтоб выходной ШИМ не плавал).
Итого 13 ног для организации выходных каналов.
(как распределить эти ноги у меня некоторые мысли имеются, но надо ещё подумать над деталями). Позже выложу рисунок и пояснение.
выдавать цифровой код через одно место это не ГУТ
_ _ _ . . . _ _ . . _ _ да это как имея под руками клаву и 33 буквы алфавита писать сообщения в форум пользуясь только " точка- тире", в канале у нас даже не зз буквы, а возможно 1000 букв: 2000 мкс-1000мкс = 1000 позиций .Кстати какую дискретность импульсов в канале нужно предусмотреть, для корректной работы устройства, я пробовал доводить до 50мкс - на каждую команду, тоесть по одному каналу можно прогонять до 20 команд. Например: 1000-1300мкс режимы АП; 1350- 1550 пять переключателей менюшек(камеры, пан-титл, шасси и т.д); 1600- 1850 - пять кнопок управления право-лево-верх-низ-центровка ; 1900-2000 еще 3 команды.
Берём 2-а пропорциональных канала на передатчике (2-е крутилки) и вместо них подрубаем Кодер.
Тут если команды разделять по 50мкс уже будет 20х20=400 команд. Но я бы все же ограничился одним каналом. В плане …на вырост. Если брать два канал то это та же РРМ пачка. А ведь по одному каналу можно вообще управлять носителем. И если у нас все5 команды сидят на одном канале то возможно можно поэкспериментировать с отказоустойчивостью. Например повторяем управляющий сигнал 8 раз, делаем из него РРМ пачку и отправляем, приемник делит это на 8 каналов ШИМ, дешифратор проверяет равны ли между собой все ШИМ, если да то исполняет. Можно соответсвенно регулировать строгость проверки если 6 из 8 одинаковые и т.д.
кодер и декодер предполагается делать на тиньках 2313
А насчет ATmega328 не думали, это позволило бы использовать типовые платки Arduino, да и ног там поболе.
А вот “готовность к выполнению”, т.е. переключение на критичные исполнительные ус-ва, ПЕРЕД их срабатыванием, можно и подсветить, например
Для коптера это может и актуально, хотя сомнительно, а для самолета находящегося за несколько км…
Так , что OSD это единственный приемлемый вариант. Кстати диодики можно поместить в зоне видимости камеры и так ориентироваться по режимам, или поместить в зоне видимости 8-сегментный дисплей.
Тут если команды разделять по 50мкс уже будет 20х20=400 команд. Но я бы все же ограничился одним каналом.
Например повторяем управляющий сигнал 8 раз, делаем из него РРМ пачку и отправляем, приемник делит это на 8 каналов ШИМ, дешифратор проверяет равны ли между собой все ШИМ, если да то исполняет.
Вот в этих местах у меня непонимание, что-то я туплю. 😦
Я ведь сам не формирую PPM пачку. PPM пачку формирует передатчик я только управляю входным напряжением от которого уже формируется длина импульса в канале передатчиком. И что там у него творится я не знаю (скорость реакции на изменение входа).
2-а канала мне нужны чтоб по одному постоянно гнать импульс для управления каналом декодера (если он выдаёт шим) в реальном времени.
1-й кнал коммутирует выход. Второй канал в реальном времени управляет этим выходом, пока не будет скоммутирован другой выход. Состояние прежнего выхода запоминается и остаётся неизменным и начинается управление новым выходом. Коммутация производится вручную кнопками на кодере. Управление если канал дискретный (вкл/выкл) тоже кнопками, если аналоговый (ШИМ) то энкодером (увеличение/уменьшение).
Может тут у меня большое заблуждение и я не вижу какого-то очевидного решения.
А насчет ATmega328 не думали, это позволило бы использовать типовые платки Arduino, да и ног там поболе.
У меня опыта не очень много, и Меги пограммировать ещё не доводилось. Хочу начать с малого и знакомого, отработать технологию, обкатать идеи, а там браться за более масштабный проект.
Я ведь сам не формирую PPM пачку. PPM пачку формирует передатчик я только управляю входным напряжением от которого уже формируется длина импульса в канале передатчиком. И что там у него творится я не знаю (скорость реакции на изменение входа).
А мы коварно подключаем шифратор, в обход МК пульта, напрямую в ВЧ блоку. Ну и соответственно подключаем к ВЧ блоку не ту ногу которая имитирует напряжение переменного резистора, а ногу на которой генерируется РРМ пачка из 8 одинаковых ШИМ импульсов "соответствующих напряжению крутилки (там будут с приемником конечно проблемы, он может в фалсейв уйти, начнет длину синхронизирующей паузы проверять…)
1-й кнал коммутирует выход. Второй канал в реальном времени управляет этим выходом, пока не будет скоммутирован другой выход. Состояние прежнего выхода запоминается и остаётся неизменным и начинается управление новым выходом.
Что мешает впихнуть все в один канал. Допустим 1000-1050…1450-1500мкс переключаем выходы 1-5 ноги соответсвенно ( 1000мкс запоминаем в переменную can=1; 1500мкс - can =5 , каждому значению переменой соответствует свое исполнительное устройство- нога вывод) , 1550 -1600-1650 -1700-1750мкс кнопки управления, верх -вни-право-лево( if (can==1) { 1550- двигаем титл вверх на 10градусов} . ну тут видимо надо еще командочку заложить типа отбой 1550 двинули вверх, 1800мкс - отбой , тоесть готовы воспринимать следующий управляющий сигнал, если 1550 еще на 10 градусов вверх. и т. д.
Напрямую к ВЧ блоку, а куда деть сигнал от передатчика. Если этот сигнал планируется подавать на вход шифратора, а шифратор будет подмешивать туда свой сигнал - мне это не очень нравится. Любой сбой контроллера и мы остаёмся без управления.
По поводу впихивания всё в один канал - реализация несколько сложновата. Я не могу контролировать была получена команда или нет и когда можно посылать другую команду. Надо вставлять паузы. Реакция управления будет с запаздыванием. В моём случае (с использованием 2-х каналов) управление тилтом будет более оперативное и точное.
Напрямую к ВЧ блоку, а куда деть сигнал от передатчика. Если этот сигнал планируется подавать на вход шифратора, а шифратор будет подмешивать туда свой сигнал - мне это не очень нравится. Любой сбой контроллера и мы остаёмся без управления.
ВЧ блок отключается от передатчика (один провод по большому счету) и подключается к соответствующему выходу шифратора, наверное можно реализовать через обычный тумблер. Но это как бы туманная пэрспэктива и аргумент в пользу впихивания всего и вся в один канал.
Я не могу контролировать была получена команда или нет и когда можно посылать другую команду. Надо вставлять паузы. Реакция управления будет с запаздыванием. В моём случае (с использованием 2-х каналов) управление тилтом будет более оперативное и точное.
А по моему проблемы, что с одним, что с двумя абсалютна одни и те же. Что по одному каналу мы не знаем произошло ли переключение управляемого выхода, и вынуждены делать паузы и дублировать команды, что с двумя каналами. Ну переключили мы управляемый выход по второму каналу , а переключился он или не мы не знаем, опять же пока мы одним каналом меняем менюшки, мы же не пользуемся другим каналом в это время для управления выбираемой нагрузкой. Это имеет смысл когда управляются несколько нагрузок одновременно -параллельно как в пульте РУ, а в нашем случае сначала выбираем нагрузку (менюшку) дублируем команду,ждем чтоб переключилось и только потом даем команду на управление выбранной нагрузкой. И хоть мы все восемь каналов в пульте под это дело задействуем проблемы будут те же… (понятно, что я могу и заблуждаться)
С дискретными каналами я согласен, их вполне подходит управлять командами по одному каналу, мне не очень нравится управление каналов с ШИМ такими командами.
Ладно, идея немного вырисовывается. Попробую сделать ради спортивного интереса, а там видно будет.
Бум ждать. А мне все таки интересно, сколько “команд” можно воткнуть в один канал…
мне не очень нравится управление каналов с ШИМ такими командами.
Ну да о плавном изменении параметров нужно забыть. Либо меняем все “рывками” с определенным шагом, либо миримся с тем, что дешифратор слегка тупит и мы отпустили кнопку, а ШИМ в управляемом канале еще меняется, тоесть пан например проскакивает нужную точку. С другой стороны ну поворачивается Пан при каждом нажатии на 10% не совсем удобно но терпимо…
У меня вопрос к Дмитрию про 2-х входовый свитч для лебёдок на ATtiny13.
Все таки есть риск случайно вывести свитч в режим калибровки. Если скажем он будет управляться трех позиционным тумблером, случайно задел или не посмотрел перед включением борта. В вашей прошивке из 86 поста достаточно вывести за 5 процентов и запускается режим калибровки. Еще +/-5% от центра на точной аппаратуре выдерживаются, а если применить аппаратуру с простыми механическими триммерами то после калибровки при следующем включении заново выходит в калибровку, значит немного центр плавает. Тут надо или как вы говорили делать выход в калибровку как на регуляторах хода (стик а 100%), или кнопку выводить для этих целей.
Угу, я что-нибудь придумаю эдакое.
У соседей вычитал совершенно потрясающую идею !
…rcopen.com/forum/f135/topic328344/1870
Т.е. по русски - это клавиша “верхнего регистра” в коптере :
мы получаем “второй пульт” для управления всеми примочками, сколько бы там каналов не было !
Надо только отключить защиту мозга от срабатывания ФС на отсутствие сигнала управления 😃 .
получаем “второй пульт” для управления всеми примочками, сколько бы там каналов не было !
Надо только отключить защиту мозга от срабатывания ФС
Не совсем понятно как реализовано…
На мой взгляд система работает возможно так:
- Ставим на борт дешифратор (если управляемых устройств толька пара то на пульте шифратор не нужен) Arduino;
2.Подключаем ко входам дешифратора на 3 входа 3 канала с приемника, один канал -ключ переключения нагрузок, 2 канала - крутилки
3.к выходам дешифратора например на 2 выхода сервы от пантитл, на другие 2 выхода RU и ELE.
Работает приблуда так : ключ на пульте в 1ом положении - дешифратор коммутирует каналы с крутилками на пан-титл
во 2ом положении на RU и ELE
в общем ничего судьбоносного. За исключением того факта, что отьедаем сразу 3 канала и получаем по ним тормоза. Для управления петардами и всем всем достаточно и одного канала… Чередовать с органами управления самиком как то стремно и неудобно, единственно целесообразный вариант когда на самике стоят 3 камеры с пан-титлами…
Да и совершенно непонятно зачем отключать ФС…
зачем отключать ФС…
Несколько за рамки темы получилось, прикольная мысль.
Если просто “переключать” выходА приёмника - в АРМ, например, сработает ФС на отсутствие управления (сигнала с приёмника, как при потери связи). Но эт чисто техническая-настроечная проблема. Гораздо “стрёмнее” - чем будет заниматься коп, пока я камеру куручЮ… 😁
Если просто “переключать” выходА приёмника - в АРМ, например, сработает ФС на отсутствие управления
В этом случае между приемником и АП все равно будет стоять электронный “ключ”, который при отключении АП и переключении приемника на другие нагрузки, может на входные каналы АП гнать какой то ШИМ, например все в нейтраль, а на вход переключения режим АП гнать “AUTO” для продолжения полета по точкам. В то время как пульт будет работать с другими “нагрузками” . В случае ФС приемник опять подключается к АП и врубает RTL. Другое дело, что промежуточный “ключ-коммутатор” это лишнее звено в цепи управления, увеличивающее шанс отказа как минимум на 30%. Человечество на стало заморачиваться по этому поводу - так появилась 16 канальная аппаратура.
так появилась 16 канальная аппаратура.
Ну… не у всех есть возможность её приобрести. Тем более он НЕ решает проблемы эргономики - например, переключение полётных режимов гораздо удобнее (проверено на столбах) делать “многокнопочником”, чем миксами тумблеров. Даже за “любые деньги” его в ссуппертаранисах нет.
Опять же - управлять камерой “понятнее” джойстиком - и направление и трансфокация, и куча тумблеров тоже себе применение найдут.
И нет необходимости перегружать панель управления пульта дополнительными “коммутационными элементами” - такими же джойстиками, тумблерами, крутилками … (с такой же степенью надёжности на отказ).
А вот проблема надёжности “коммутатора” и его принципа исполнения, действительно серьёзная. По сути, его “полётная часть-регистр” - некий буфер - должен запоминать последнюю команду в ШИМе с пульта и держать её, пока пультом управляют камерой.
Либо поступать, как в ДХ4 - пять секунд на допы, потом автоматом на управление копом. И если за это время коп вышел из зоны управления - ФС по отсутствию связи.
… В обшем-то и в тему мы попадаем - управление-то … одним тумблером ! 😁
У меня вопрос к Дмитрию про 2-х входовый свитч для лебёдок на ATtiny13.
Все таки есть риск случайно вывести свитч в режим калибровки. Если скажем он будет управляться трех позиционным тумблером, случайно задел или не посмотрел перед включением борта. В вашей прошивке из 86 поста достаточно вывести за 5 процентов и запускается режим калибровки. Еще +/-5% от центра на точной аппаратуре выдерживаются, а если применить аппаратуру с простыми механическими триммерами то после калибровки при следующем включении заново выходит в калибровку, значит немного центр плавает. Тут надо или как вы говорили делать выход в калибровку как на регуляторах хода (стик а 100%), или кнопку выводить для этих целей.
Вот, можно сказать, заново переделал предыдущие прошивки (с каждой новой программой постоянно совершенствуешься, появляются новые идеи…)
Схема прежняя.
В одном проекте - несколько прошивок. (есть внутри файл с описанием работы).
Основное отличие в логике запуска калибровки. Она запускается только если, при подаче питания, стик находился в околомаксимальном положении и сразу после подачи питания (в течении 3 сек) им надо активно работать.
Также появилась некоторая защита от случайных помех.
Eщё есть возможность поставить прошивку, откалибровать стики, а потом залить прошивку с залоченой калибровкой (они есть в проекте).
При калибровке, информация запоминается в EEPROM, и при смене прошивки просто не трогаем EEPROM и результат калибровки останется.
Ещё одна новинка - прошивка для 4-х выходов (когда при прошивке программируется фьюз RSTDISBL и ножка Reset становится портом ввода/вывода) и для 3-х теперь одна. Программа сама определяет состояние этого фьюза и работает соответствующим образом.
(ещё раз напоминаю, что фьюз RSTDISBL можно программировать только 1 раз, если у вас нет специального параллельного программатора, в противном случае контроллер больше перепрошить не получится).
Да, проверял только в протеусе (кому интересно в проекте есть файл rc_2IN_ATTINY.DSN), поэтому желательно перед серьёзным применением погонять прошивку на наличие багов.
Здравствуйте Дмитрий!
Протестировал я в железе ваши новые прошивки. Работают не совсем так как в протеусе, дальше по стараюсь вкратце изложить свои наблюдения:
RC_2IN_ATtiny13_4-1 режим работы №1
В калибровку не выходит. При пропадании сигнала загорается 5 пин, при появлении сигнала гаснет 5 пин и сразу загорается 2 пин или 3 пин в зависимости на каком входе появляется сигнал. Причем эти выхода сразу включаются при появлении сигнала в любом положении стика и остаются все время включенными.
RC_2IN_ATtiny13_4-23 режим работы №3
Исправно калибруется только 1 канал, пины 2 и 3 исправно работают. Во время калибровки мигает пин 5. 2 канал входит в калибровку, 5 пин начинает мигать и после остается все время гореть, 1 пин тот что резет молчит. При пропадании сигнала все выходы отключаются.
Еще заметил что вот это математическое вычисление центра на более точном передатчике настраивается, а вот на простом никак не получается, причем в пред идущей версии прошивки на том же передатчике все прекрасно калибровалось и четко видело центр. Так же я заметил что 3х секунд выжидания для входа в калибровку все таки мало, если на футабовском приемнике все проходит быстро, то на таких как карона или фрсай процесс биндинга длится гораздо дольше и не хватает времени вывести в режим калибровки. В некоторых регуляторах в процессе калибровки по мимо крайних положений стика обязательно программируется центральное, может это взять на заметку как вариант? Про железо не котором испытывал, 2 платы которые исправно работали на пред едущей версии прошивки, просто перепаял Новые прошитые контроллеры для чистоты эксперимента.
Попробую сам в железе протестировать.
RC_2IN_ATtiny13_4-1 режим работы №1 - поведение вполне понятное т.к. не было калибровки.
RC_2IN_ATtiny13_4-23 режим работы №3 - Уже лучше, но не понятно со вторым каналом.
Про калибровку - есть нюанс (я это сделал как защита от случайного входа в режим калибровки). Для запуска калибровки мало перед подачей питания установить стик в максимум, после подачи питания надо им активно (читай резко) начать двигать.
Калибровку можно проводить много раз.
И ещё, про 3-и секунды. У меня сделано, что при подаче питания при отсутствии сигнала, происходит ожидание его появления, и только после появления сигнала начинается отсчёт времени.
Хотя может в реале работает немного не так как планировалось.
Всё, теперь должно работать. Там действительно были “грабли” на которые я постоянно наступаю.