Телеметрия (часть 2)
Обижаете: я на двух транзисторах ССИ для телеметрии сделал. 9 лет назад еще 😃
Или вы имеете в виду “звоны” порожденные неустойчивостью выходного видеоусилителя некоторых камер?, но и они по длительности менее 100 нс, их практически не видно…
Насчёт физики процесса- сказать не могу, не вникал. Поскольку кодировка цвета в ПАЛ- фазовая, то дрыганье уровня белого ,возможно вызывает изменение фазы вспышки (pal-burst)
Но то, что цвета (именно цвета) искажаются- видел на собственном опыте.
Поскольку есть друг, производящий много лет профессиональные транскодеры и знающий про в-сигнал всё, я просто пошёл к нему, обрисовал проблему…
Он мне долго что то объяснял, выкладки писАл… ☕
После просьбы не мудрить, а пальцем ткнуть : нарисовал схему на трёх (опять я тут перерасходовал 😃 ) транзисторах- и всё отлично заработало 😛
Причём от типа камеры- абсолютно не зависит.
Было это- лет 12 назад 😊
BOB-4 хоть поставили что ли.
А кто такой ВОВ -4?
А кто такой ВОВ -4?
это вот такой вот плат))))))
www.decadenet.com/bob4/bob4.html
используется в DragonOSD, не требует внешнего видеосигнала, сам все генерит
это вот такой вот плат))))))
генерит
Ну, ни фига себе “плат”- бабла стОит немеряно, электричества жрёт (судя по двум процессорам) тоже.
А “не требует видеосигнала”- это как?
Не.
Я за три транзистора и 1881 такой “плат” не променяю 😃
Нам надо не ВОВ-4 использовать, а самим реализацию на ПЛИСе делать, тогда хоть 2D хоть 3D, хоть разноцветное, хоть чернобелое. ВОВ-4 конечно хороша, но большая, это модуль, а нам нужна компактная, легкая девайсина.
2blade Поделитесь схемкой модулятора трех транзисторах, пожалуйта… Или это было давно и …
Ну, ни фига себе “плат”- бабла стОит немеряно, электричества жрёт (судя по двум процессорам) тоже.
А “не требует видеосигнала”- это как?
Не.
Я за три транзистора и 1881 такой “плат” не променяю 😃
Это значит, что большинство OSD показывают что-либо только при наличии на их входе сигнала с видеокамеры, иначе черный кран, по приборам не полетишь в случае сгорания-отпадывания камеры))))))))))))))))))))) Это и понятно из принципа формирования буковок-цифирок телеметрией.
Боб сам генерит стандартный видеосигнал
Цена конечно 100 бакинских - это да, только для полного счастья ей надо всего лишь платку с той же мегой, AT90USBKEY например, от которой не требуется особой производительности и изощренного ума кодера для вывода чего-либо))))))))
Можно на ней же гонять код автопилота.
Почему я не взял DragonOSD спросите? Пирогоризонт к ней прикручивать надо.
Автор отказывается.
Да и подорожала она.
Лучше поддержу отечественного производителя)))))) Только он вот не торопится чего-й-то отдавать продукт своего труда)))))
ЗЫ: кушает он 0.5 Вт на 5В
Тимофей!
Проанализировал видео сегодняшних полетов.
-
Стабилизация работает нормально. Но небольшая раскачка имеет место. Думаю, Ваши слова про дифф. составляющую в алгоритме регулятора справедливы - нужно вводить.
Управление в режиме стабилизации вялое - но это и понятно. Хуже, что триммировать полет практически невозможно. То есть если пирометры стоят чуть криво или самолет немного перекошен - стабилизация будет с наклоном. Мой Изя в режиме стабилизации ходит кругами диаметром метров 200-250. -
Автопилот.
Высота удержания для автопилота у меня стоит 60 м. Включал возврат на базу обычно на 100-150 м. В результате получал более менее крутой доворот на базу и очень резкое снижение. По достижении 60 м Изик проскавал дальше - иногда до 30-40 м, затем резко вверх - вплоть до петли и так далее, медленно (очень медленно) сокращая амплитуду колебаний. Понятно что нужно уменьшить расход руля высоты в настройках. Но хочу спросить - как построена логика удержания высоты? Уменьшается ли угол РВ при приближении к заданной высоте? И не стоит ли ввести коридор удержания высоты вместо жесткого значения?
А в остальном - кайф! Автопилот работает. Изя реально летит назад.
Это значит, что большинство OSD показывают что-либо только при наличии на их входе сигнала
Утверждение аксиоматичное (о, как ввернул!)
Однако же- перегореть может любой элемент ОСД, чаще всего- это случается с передатчиком.
В этом случае “генерированный видеосигнал”- точнее, синхросмесь, (кстати- тоже довольно простой продукт- есть в любом “тестере телемастера”), ничего не даст- про самолёт то всё равно не видно…
И тут уважающий себя (и хозяина) автопилот- обязан включить “возврат домой”
А выход из строя камеры- наименее вероятная поломка из возможных: у меня в косяке двери- 10 лет молотит без перерыва- единственно, на матрице слегка “пейзаж” отпечатался 😍
И насчёт “отечественного производителя”: Тимофей и так работает, как дизель в Заполярье…
А ещё К.Маркс изрёк: “даже 9 беременных, собранных вместе- не родят за месяц”.
Не дышите ему в спину- и всё родится в срок 😃
>Но хочу спросить - как построена логика удержания высоты? Уменьшается ли угол РВ при приближении к заданной высоте? И не стоит ли ввести коридор удержания высоты вместо жесткого значения?
Работает просто, как моск поросенка.
Требуемый тангаж = К*(ЦЕЛЕВАЯВЫСОТА-ТЕКУЩАЯВЫСОТА). Разумеется, макс и мин значения тангажа задаются с компука.
К не задается, и его как раз надо раз в 10 уменьшить. А в новой программке-прошивке - позволить настраивать с компука.
Дальше всё просто: требуемый тангаж поддерживается той же логикой, что делает стабилизацию.
А ещё К.Маркс изрёк: “даже 9 беременных, собранных вместе- не родят за месяц”.
Не дышите ему в спину- и всё родится в срок 😃
Надеюсь не в девятимесячный)))))))))))))))))))))))
Тим, пока все еще в состоянии отладки, позволю предложить кой чего.
А именно, установка пироголов.
Сейчас политика такова что плоскость платы должна быть в плоскости непонятно чего…
И вот почему. в разных режимах самолет имеет разные значения тангажа и если по крену проблем нет, то тангаж вызывает недоумение… Допустим хочу что бы самик стабильно планировал, тогда в режиме ассистента придется вручную подстраивать плоскость пироголов по тангажу что бы самик имел нужный угол планирования!!! Я уже представляю какой это будет гимор… Нельзя ли внести некий режим обучения?
Алгоритм скажем такой.
Устанавливаем пироголовы как получилось. (естесно как можно ровнее)
Далее в тихую погоду (понимаю что иногда это сложно) запускаем самик, тримируем его на планирование, стараемся летать плавно, пишем лог. Далее просматриваем лог, смотрим углы на планировании и вводим попровочный угол, который автопилот будет держать относительно плоскости пироголов…
Надеюсь идею изложил понятно.
Что скажет уважаемая общественность?
Зер гут ! Вообще пока не представляю, как можно “точно” относительно правильного полета и соотв. осей изи установить пироголову. Хорошо, а если не изик,более капризный самолет, тогда как ? В любом случае надо вводить режим триммирования пироголовы. Боком только пилотажки летать могут, да вертолеты.
Да, согласен. Сейчас смотрел логи полетов kulikof, обнаружил неприятную вещь: самик идет с набором высоты, а угол тангажа с логов примерно градусов на 10 косит: нос смотрит вниз от траектории полета 😦
Но не всегда.
То ли это теплый винт в поле зрения пирометров попадает, то ли неровности местности, то ли неточная установка пироголовы, но факт есть факт.
Введу поправки. И по крену тоже.
И вот почему. в разных режимах самолет имеет разные значения тангажа и если по крену проблем нет, то тангаж вызывает недоумение… Допустим хочу что бы самик стабильно планировал, тогда в режиме ассистента придется вручную подстраивать плоскость пироголов по тангажу что бы самик имел нужный угол планирования!!!
Может, каких нибудь предустановок сделать, типа: Стар, Глайдер и т.д.?
Не может быть никаких предустановок, неудастся выставить пироголовы с нужными углами. Каждый самолет будет летать со своим углом в зависимости от веса, центровки, пожеланий пилота… Поэтому реально проще установить в предполагаемую позицию, подлетнуть оттримить самолет, а потом оттримить плоскость пироголовы исходя из лога.
По поводу ассиста. Сейчас он борется с пилотом 😃 А что если пилот с ручки будет задавать углы, которые ассист будет отрабатывать и поддерживать? Скажем крен +\-45 тангаж +\-20 (задается с компа) И самик будет отзывчивым и разбить не удастся 😃
Петлю правда не сделаешь…
Но для любителей петель можно еще один режим ввсести. Как в вертолетных гироскопах хед лок. Там с ручки пилот задает угловую скорость… Правда не представляю как это будет выглядеть на самолете 😃
Надеюсь идею изложил понятно.
Что скажет уважаемая общественность?
Общественность скажет:фигня всё это 😃
По сути идея верная, по реализации- очень сложно, а для среднего человека (без степени КТН)- невозможно.😍
Правильная часть"устанавливаем пиро более- менее горизонтально".
Дальше- взлетаем, приводим самолёт триммированием в горизонтальный ровный полёт без крена и-
!внимание!,
! aсhtung!
- нажатием пимпочки на передатчике- записываем в память автопилота данные показания пироголовы, как “правильное” ☕
И он, зараза- знает что вот это :1, 34v-крен и 1,82 v- тангаж (к примеру!)- правильное положение самолёта.
Всё, калибровка окончена.
Не надо никаких “логов”, “просматривать”, “анализировать”: голова-то не котёл, столько умных слов переваривать 😝!
ЗЫ.Такую же процедуру можно применять и для “обучения” автопилота правильному повороту- развороту-крену-снижению, поскольку на земле понять (и записать в память) “нужные углы”- практически невозможно или возможно, но ценой титанических усилий.
Я думал о таком методе. Правда не стал его озвучивать исходя и соображения большей сложности его реализации (больше писанины в програмном коде)… и вероятных проблем с моментом запоминаия, типа если самик накренится вдруг… (хотя никто не запрещает щелкать кнопкой сколько влезет пока не запомнится правильный результат)
Кстати, еще стоит продумать, как давать эту команду “запоминания” и некоторые другие. Сейчас на управляющем канале фиксируется 4 состояния (High, Middle, Low и Fail). И задействованно 3 режима: отключен, стабилизация, возврат. Как раз один свободный для “запомнить” остается. Но на будущее нужно еще несколько режимов. Предлагаю сразу заложить, скажем 8 режимов - 8 секторов PPM сигнала на управляющем канале. Например так: 1-отключено; 2-стабилизация по крену; 3-стабилизация по крену и высоте; 4-запуск режима полета по маршруту; 5-сервисный режим 1; 6-7 определяется пользователем (или сервис 2, сервис 3), 8 - возврат на базу.
Угу, только где такую аппу взять что бы 8 секторов было на переключалке? Тут с 3мя не у всех есть…
Кстати по этому поводу возникла мысль, сделать добавитель\заменитель каналов. Девайс по принципу хедтрекеров. и тренерского разьема берется ППМ пачка к ней добавляются или заменяются послединие N каналов и возвращается обратно, и уже на девайсине могут быть крутилки\ перекллючалки на кучу положений…, для 6ти-7ми канальных доплнительные канал, для нормальных не надо внутрь лезть… Хотя помнится мне что некоторые аппы отдают тренеру только 4ре основных канала…
Угу, только где такую аппу взять что бы 8 секторов было на переключалке? Тут с 3мя не усех есть…
Несколько 3-х и 2-х позиционных переключаетелей легко микшируются на 8 секторов. Например у меня на Futaba 12FG, 6 - трехпозиционников, 1- двух и одна кнопка. 8 зависимых команд - не проблема.
возврат.базу.
На “возврат” как раз никакого специального режима не надо: передатчик выключаем- вот и режим “потеря сигнала, возврат”
А для “записи” можно какой- нибудь редко используемый канал прислонить :я использую кнопку “кадр”, которой фотоаппарат “щёлкается”- если её коротко нажать- то “кадр”, а если длинно- “записать в память данный режим”.
Просто, процессор должен отслеживать изменение РРМ на данном канале и принимать решение: что делать.