Включение/выключене с 1 канала нескольких нагрузок. Возможно-ли?
Да то же самое что и трансфокатором и всем прочим. необходимо два выхода на дешифраторе один пан второй титл. сначала задали ШИМ в одном канале потом переключились на второй
О том и речь. Вопрос чем задавать ШИМ в канале. Если переменным резистором - будет то, что я написал. Если 2-я кнопками - неудобно. Можно энкодер поставить. Но по моему проще 2-я крутилками по 2-м каналам (тут же можно использовать управление на гироскопах по положению головы).
Наш “бортовой дешифратор” по сути должен эмитировать свободный канал АПы т.е уже готовые стандартные устройства никак НЕ меняются, а покупаются, подключаются и настраиваются поЛзователями в соответствии с инструкциями к ним. Например:
Собственно я это от Вас и добиваюсь. Не общих слов, типа хочу чтоб было хорошо 😃 , а конкретно что должен выдавать дешифратор в том или ином случае (ШИМ (какой), уровень сигнала (какой)…). Я поэтому и сказал, что не в теме коптероводства, и тех приблуд, которые используются, и нет никакого желания погружаться в эту тему.
по логике, в “простом случае” - шифратор имеет два физических переменных резистора,
На Аппе есть 2-е крутилки (на моей Турниге их целых 3-и)(это и есть два физических переменных резистора)? так и крутите ими по очереди, зачем переключалка.
Тогда шесть частот с земли могли бы образовывать шестибитное слово.
Главный вопрос - как передать это слово в 6 бит по одному каналу. В принципе получается последовательный канал, нужно разработать протокол для передачи данных. Можно будет и не только 6 бит передавать. Надо подумать.
Собственно я это от Вас и добиваюсь. Не общих слов, типа хочу чтоб было хорошо
Я сам ещё как Ёжик в тумане - хочется пойти в лес, разбудить медведя и бежать, бежать куда-то в даль, задыхаясь от чюв-вства восторга ! 😂
… Счаз, после 8марта мозГ восстановиться, а то мысли никак спутники не найдут…😃
Ещё немного, и я подумаю, что мы пульт от телевизора изобретаем - там и крутики и тумблеры и всё по одному каналу … 😁
Сейчас только одно в головку приходит - дешифратор должен иметь столько каналов на выходе, сколько подключаемых устройств управляются свободным каналом. Он же должен “запоминать” последнее своё значение ШИМ, пока ему на вход не поступила команда поменять его. Тогда все “внешние” , подключаемые устройства будут думать, что подключены к свободному каналу приёмника и работать “в штатном” режиме.
А на пульте - выбрал (хоть много позиционником) № устройства на борту и изменил по одному каналу его свойства. 😃
Главный вопрос - как передать это слово в 6 бит по одному каналу. В принципе получается последовательный канал, нужно разработать протокол для передачи данных. Можно будет и не только 6 бит передавать. Надо подумать.
В принципе все придумано - это модем, тут кстати решается сразу и второй вопрос , если связь двусторонняя то модем может докладывать какая нагрузка (нога дешифратора) подключена и что мы регулируем( с другой стороны модем это не наш путь). Хотя в принципе оригинально- подмешать в РРМ пачку, вместо одного из импульсов, сигналы “модема”, но тут врпрос в частоте обновления, хватит нам такой скорости, чтоб передать, без критичных задержек команды на дешифратор, у Козина кстати в алгоритме заложена проверка , перед исполнением сигнал нужной длины должен повторится несколько раз, if нет то выполняется предыдущая.
А можно световую иллюминацию в ряде случаев добавить - вместе или перед опусканием ног свет вниз или камеру нижнюю - на ФПВ пилот увидит , как ноги опускаются…
Это ладно если мы увидим, что не включилась эллюминация, а если мы крутим панораму, а вместо этого выбрасывается парашьют…Можно в принципе запрограммировать одну из ног выдавать напряжение (для МК это тот же ШИМ) а напряжение с этой ноги подавать на OSD (у многих OSD имеются свободные входы для подобных целей) - 1v -пнорама, 2v- титл, 3v - мы в меню камер и т.д. коряво конечно, но лезть в протокол OSD это уже из другой оперы .
Сейчас только одно в головку приходит - дешифратор должен иметь столько каналов на выходе, сколько подключаемых устройств управляются свободным каналом. Он же должен “запоминать” последнее своё значение ШИМ, пока ему на вход не поступила команда поменять его.
Иначе ни как - отключился от устройство, а у него сразу крышу снесло, или оно в нейтраль ушло.
если мы крутим панораму, а вместо этого выбрасывается парашьют.
Да, эт жестокий облом …
У Козина вполне логичное решение - пока несколько пакетов одной команды не придут - я (как взрослый дешифратор) считаю их провокацией или помехами. Мудро, тем более пилот и подождать может десятую долю секунды, пока ноги начнут срабатывать.
Обратная связь (контроль) - это идеальное решение, но на “стандартно заряженом” копе уже куча сосисек - 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), поэтому желательно перед серьёзным применением погонять прошивку на наличие багов.