flybrain. передатчик + приемник + автопилот. powered by stm32
Реальный CAN требует два пуда обвязки и слой гуталина. Там трансиверы нужны и приемники, если по уму. А если без этого, то все превратиться в банальный 485й. В качестве физики я вижу стандартный UART только делать его надо тупо и в лоб, и на скорости не выше 36к.Тогда на серву достаточно будет мелкой приблуды, замаскированной под стандартный шлейф. AtTiny на 8 ног + кварц + пара кондеров + 2 разъема, ВСЕ!. НО зато все можно будет соединить в звезду. Каждой серве назначаем свой адрес, она сама свою инфу вычитывает. Сделать протокол программирования адреса. Примерно так же и в SBUS сейчас, только там скорость сверхзвуковая и инверсия аппаратная, чтобы враг не догадался. Еще там кривой вариант с детектированием начала фрейма. Только одному это делать - ну его на фиг, если народ подключится и добавит поддержку выработанного совместно протокола, то буду участвовать и к себе поддержку добавлю. Стоимость одной такой приблуды на серву выше 150руб не будет, даже если в розницу все брать, я уже прикинул. Но нам в тиньку нужен программный UART, аппаратного там нет.
Реальный CAN требует два пуда обвязки и слой гуталина.
www.compel.ru/catalog/interface/can/
Милости просим, драйверы на любой вкус, 1 SOIC8 на девайс. Жрут как кони, но если делать по-взрослому, то извольте мириться с потреблением.
Я у себя CAN интерфейс вывел на разъем доп. функций.
А если подешевле и поближе к народу, то, мне кажется, I2C, и придумывать ничего не надо. И на Тиньке сделать его можно спокойно.
Смысла делать УАРТ (как и И2Ц) для раздачи каналов на сервы нет никакого. Самопальная шина на УАРТе получается малоскоростная, ненадежная при проблемах на узлах, переходник на серву все равно нужен, что с КАНа что с УАРТа. Ну да, с УАРТа немного дешевле, но это почти тупик. Да и И2Ц хороша только внутри одного прибора между блоками, а не между приборами. Не верите - посмотрите на проект Microkopter - сколько там вопросов вызывают регули на И2Ц. Зато когда захотите расширять проект, КАН у вас будет на все случаи жизни. Защищенность от разного потенциала земель, не выходит из строя при ошибках в подключении (некоторые драйверы КАНа до 80 вольт по входу держат), реалтайм арбитраж и уже заранее заложенное сглаживание фронтов для повышения ЭМС. Ни на УАРТе, ни на И2Ц ничего подобного не получить.
Нарисуйте схему трансивера CAN со всем сопутсвующим прицепом и прослезитесь. Какие напряжения вы там гонять собираетесь? CAN - это 2 провода + земля + питание+трансивер+МК (не слабый причем)+обвес из барахла. I2C - это 2 провода + земля + питание + 1МК + задница в протоколе, который не может быть сам восстановлен. UART - это 1 провод и голая ножка МК + crc16 + земля + питание + 1МК, а дальше вперед и с песней. Футаба работает через UART, ничего не глючит. Нам не нужны большие скорости, чтобы сервами управлять. Нам нужно устройство простое как валенок и дешевое, как туалетная бумага.
Я у себя CAN интерфейс вывел на разъем доп. функций.
А толку? А можешь конкретно сказать, что ты на него планируешь повесить и каким способом хотя бы в теории? Сервы? Как? Преобразователь на каждую серву CAN->PWM ? Подключать доп. устройства? Какие? у тебя же все на одной плате в сборе, чего там еще подключать?
А толку? А можешь конкретно сказать, что ты на него планируешь повесить и каким способом хотя бы в теории? Сервы? Как? Преобразователь на каждую серву CAN->PWM ? Подключать доп. устройства? Какие? у тебя же все на одной плате в сборе, чего там еще подключать?
Да всякое. Забей.
Учитывая, что CAN присутствует только в старших типах микроконтроллеров, использоввать его для массовых элемментов РУ: сервы, регули, реле всякие не получится.
Да и все ухищрения физики и протокола на расстояних порядка неск. метров - как из пушки по воробьям.
ИМХО, на моделе достаточно PPM/PWM, UART и I2C для всех видов обмена. Просто и надежно.
Обвязка КАНа проста и недорога. Трансивер в корпусе SO-8 и пара-тройка резисторов. Но с позиции цены шину даже на УАРТе городить не надо, РРМ прост как валенок и не стоит вообще ничего, вполне еще поработает. По поводу “ухищрения физики и протокола на расстояних порядка неск. метров - как из пушки по воробьям” расскажите это сообществу коптероводов, у которых на 30 см шины И2Ц без вдумчивой разводки земель и экранирования постоянно ошибки сыпятся, а при крашах и как следствие КЗ между шиной и питанием процы горят.
Я спорить не стал, пусть автор проекта решает, это его проект.
К тому же, проблемы квадров с их регулями на I2C - это, всё-таки, проблемы квадров.
то, мне кажется, I2C, и придумывать ничего не надо. И на Тиньке сделать его можно спокойно.
+1
Не верите - посмотрите на проект Microkopter - сколько там вопросов вызывают регули на И2Ц.
Ой да ладно!
У меня AVRDragon столько вопросов вызывал, пока не допилил его напильником. По JTAG отказывался шить на кабеле длиньше 10 см. А это таки фирменный девайс.
Кто знает кто и как проектировал ту I2C? Стоят ли там резисторы в линиях на 16-20 ом, какой провод использован для связи? Какие номиналы подтяжки? И т.д. Звон, стоячую волну кто-нить смотрел осциллом?
Нормальный И2Ц на 400 кГц работает на 30 см стабильно. Уменьшаем скорость - увеличиваем дальность. Нам ше надо обеспечить 50 Гц на серву, а это фигня.
Прелесть КАНа в том, что он не теряет протоколы при коллизиях. Но это актуально при многомастерной системе, при одномастерной это такой же 485. Только переменное напряжение высокой частоты в проводах гоняется.
UART - это 1 провод и голая ножка МК + crc16 + земля + питание + 1МК, а дальше вперед и с песней.
+1
Обычный TTL UART, это до метра провода. И, в отличие от SPI и I2C, он нечувствителен к звону в линиях. только вероятность ошибки возрастает, теоретическая, т.к. может выпасть один сампл из 16.
Но у СТМ можно настраивать время нарастания сигнала на ногах, этим можно пользоваться.
у которых на 30 см шины И2Ц без вдумчивой разводки земель и экранирования постоянно ошибки сыпятся, а при крашах и как следствие КЗ между шиной и питанием процы горят.
Как говориться, las manos cresen del culo. Раз даже процы горят.
Небольшая демка того, что на подходе
разрешение 376x220
Небольшая демка того, что на подходе
разрешение 376x220
Выглядит неплохо. Это будет работать на текущей ревизии платы АП или подразумевается новое железо?
Выглядит неплохо. Это будет работать на текущей ревизии платы АП или подразумевается новое железо?
Будет работать на текущей. Осмелюсь ответить за Алексея… 😃
Никаких новых железок не нужно, работать будет в текущей железке. Это разрешение еще не предел, можно еще раздвинуть, но мне пока памяти жалко.
Алексей, у меня возник вопрос (скорее на будущее). Не думал ли ты реализовать возможность управления антенным трекером? Например передавать GPS координаты через обратный канал (с самолета на землю) или генерить аудио сигнал с закодированными данными и передавать его через аудио канал AV передатчика для поддержки существующих трекеров типа ImmersionRC или Eagle Tree?
Сейчас мысли крутятся вокруг схемы будущего треккера со следующими возможностями на плате:
- три сервы. Две под pan/tilt + 1 под вариант для подстройки поляризации. Наклон самолета относительно горизонта будет известен, соответственно будет информация для переориентации антенны, почему бы ее не использовать. Не факт что будет полезный выхлоп. Если не получится, будет просто запасной сервоканал.
- автоматический подбор уровня компаратора для декодирования полезного сигнала из видеопотока. Переменных резисторов точно ставить не буду.
- RFM модуль на прием обратного канала с самолета, для подстраховки пропавшего видео. Кроме того можно будет реализовать управление треккером с пульта самолета. Тогда можно будет поставить 2 направленных антенны - видео + радиоканал. при необходимости организовать радиоканал Пульт-Треккер-Самолет. На пульте антенна обычная, а на треккере направленная
- видео вход от приемника обычного
- видеовыход буферизированный (2 штуки)
- shield разъемы под насадку платы приемника на 5,8ГГц (эта платка уже изготовлена и едет ко мне). Антенну буду цеплять через ВЧ фидер типа RG178. Не факт, что решение будет удачным, но я хочу попробовать.
- usb разъем для подключения к PC
- разъем usart/i2c/SPI для расширения типа синего зуба.
опционально:
- добавить в схему таки к RFM модулю еще и бустер, как в пульте, чтобы можно было прямо с треккера сигнал посылать и сидеть за ноутом, а пульт выключить после взлета
про диверсити пока не очень понятно по криериям переключения и технологии разветвления. Это либо два приемника надо иметь, либо RSSI с видеоприемника. Но можно заложить без проблем вариант с двумя видеовходами для двух приемников и переключаться между ними. Здесь нет проблем.
Вообщем по треккеру принято пока только концептуальное решение, что он будет сделан. Но по плану сейчас
- ОСД в массы. Завтра думаю будет новая прошивка на сайте.
- Добавление в ОСД экранного меню
- Контрольная панель
- Передатчик. Платы уже едут ко мне. Думаю в середине февраля начну сборку. К новому сезону хочу иметь уже обновленную аппаратуру.
- треккер
и передавать его через аудио канал AV передатчика для поддержки существующих трекеров типа ImmersionRC или Eagle Tree?
У меня пробел в познаниях существующих треккеров. 😃 ОК. Аппаратно я заложу возможность вынуть цифровой поток из аудиоканала. Но программную поддержку пока только в список хотелок в самый конец могу добавить.
Алекс, синус-косИнус у тебя табличные или процедурные?
Процедурные. Я решил не парить себе мозг на эту тему. Нагло пользуюсь большой вычислительной мощностью. Пусть мегаАвр кодеры завидуют и считают такты.😁
Выложил долгожданные обновления прошивки в разделе download:
- Перерисовано OSD. Добавлено разрешение экрана 384x220. Переключение между режимами OSD при помощи переменной OSD_Resolution_Mode.
- Для настройки OSD можно задать режим принудительной зарисовки всех возможных элементов даже без присутствия приемника. См. OSD_Force_Show.
- Для облегчения понимания где граница экрана, теперь можно засветить бордюры OSD_Show_Outline_Border
- Для нового разрешения OSD теперь доступен русский язык Set OSD_Lang 1
Подробнее для работы с новым OSD читайте мануал раздел 5.9 Все необходимые нововведения там отражены. Кроме того в мануал добавлено описание работы и настройки миксеров и описание использования S-BUS от Futaba
Текущая версия мануала одним файлом скачать здесь
FlyingBrain_User_Manual_v1.2-160113.pdf
Видео демки пока нет. Вчера ночью все закончил. Может сегодня сделаю вечером, если удастся. Ну может кто-то меня опередит.
Не успел перерисовать вариометр, тоже постараюсь оформить сегодня. Теперь начну рисовать менюшки для управления настройками на экране ОСД
Тут мне справедливо заметили, что я забыл сказать что после перепрошивки автоматом новый режим OSD не включится. Останется старый. Так вот новый надо принудительно включить и сохранить перманентно в конфиге. То есть даем команду Set OSD_Resolution_Mode 1
И еще в догонку. Новые значения координат будут мусорными или нулевыми. Поэтому изначально Reset OSD исправит положение если все элементы ОСД навалились друг на друга с координатами (0,0). Однако не забываем посмотреть и запомнить какое было значение OSD_Comp_Voltage, оно тоже сбрасывается. Его потом восстановить надо будет после Reset OSD.
Настольный тест новой осд
Вчера посидел над темой таблетки для цветовых декодеров и борьбы с цветомузыкой на экране.
Вот результат. Сначала самая больная тема - черный фон, затем уже светлый (ну тут оно всегда проще было)
Смотрим на результат, это запись с EasyCap. За качество не пинайте, я до сих пор не могу заставить ноут с хорошим качеством сделать запись. Ну и туба добавляет еще…
ИМХО, не помешало бы в ОСД разрешение увеличить до 704х576, а также для уменьшения “захламлённости” экрана раздвинуть лестницы ближе к краям кадра и убрать из авиагоризонта линии +10, -10, +30, -30 и т.д.
до 704х576, а также для уменьшения “захламлённости”
Павел, это не добавит места. Никто не сможет смотреть на экране такие мелкие пикселы, поэтому шрифты придется делать толстыми и большими. Кроме того эфир обрежет все разрешение. Нда, и у NTSC камер нет такого разрешения по вертикали. И памяти 50кб + 50кб у меня просто нет в наличи. Вот посмотрим на то, что Тим предъявит миру и там уж решим, есть толк а такой разрешухе или нет.
Чтобы картинка занимала полный объем экрана я добавлю возможность задать разрешение самому пользователю, можно будет раздвинуть по вертикали и горизонтали, так чтобы прямоугольник занимал весь экран конкретной камеры. Потратить еще 10-15кб я смогу себе позволить на это дело. А раздвигать элементы на экране, это уж сами делайте. Возможность расставить контролы как душе угодно - есть. Каждый пусть сам под себя расставляет. Сделать углы отключаемыми - тож не проблема, мне цифры нужны, а кому-то мешают.
Вот патч, который у меня решил проблему цветового беспредела. Не факт, что это не зависит от конктретной камеры. Но тем не менее, сделал я вот так, как на фото.
ИМХО, не помешало бы в ОСД разрешение увеличить до 704х576, а также для уменьшения “захламлённости” экрана раздвинуть лестницы ближе к краям кадра и убрать из авиагоризонта линии +10, -10, +30, -30 и т.д.
Насколько я знаю, автор вообще хочет сделать 3 разных варианта искусственного горизонта. Можно будет выбирать на свой вкус.
И памяти 50кб + 50кб у меня просто нет в наличи.
[ехидненько так, в стиле “ну я же говорил!”] а у моей плиски 4 метра видеобуфер. Могу увеличить до 16, для HDTV какчества 😁
ПС. от помех от передатчика удалось таки избавиться?
а у моей плиски 4 метра видеобуфер.
Рад за плиску, но для меня большое разрешение осд не очевидно в части жизненной необходимости. Какой смысл мельчить аппаратно, чтобы потом программно укрупнять? Сначала посмотрим на результат Тимофея, я хочу увидеть линии толщиной в один пиксел при разрешении 800х600.
ПС. от помех от передатчика удалось таки избавиться?
От видеопередатчика помех и наводок нет. GPS себя чувствует прекрасно с активной антенной.
От обратного канала 433Мгц - есть. Но это >1 Ватта в эфир 2 раза в секунду. Антенна на 433Мгц в 4 см от видеопроводов и прочих проводов, которые никаким экраном не прикрыты. Ясень пень они примут все…я же не могу их уговорить не принимать на себя электромагнитное поле. К тому же это не помехи самого видео, а снос фронтов синхроимпульсов, соответственно компаратор засекает фронт сдвинуто во времени, картинка отъезжает 2 раза в секунду. Я пока не занимался плотно данной темой. Но на будущее купил экранированный кабель, проложу все видеошлейфы внутри экранки + хочу попробовать АП+видео запитать от одной батареи, чтобы земли объеденить в одной точке. Еще есть вариант синхронизиться не от заднего фронта ССИ, а от переднего. Картинка самой видеокамеры не сдвигается в момент передачи. Возможно телевизор работает именно по передним фронтам, или как-то усредняет.
Кстати, что интересно. Пробовал отключать обратный канал и вплотную подносил передатчик, данного эффекта не наблюдается. Подносил антенну вплотную к АП и видеокамере - фиг там, изображение стоит колом. Но на передатчике сейчас только 100 мВатт, поэтому не совсем корректный тест. Вообщем, чешу репу пока на эту тему.
Если можешь посоветовать что-то по делу конструктивного, а не фантастического, welcome…