flybrain. передатчик + приемник + автопилот. powered by stm32
Аварийная автопосадка и сейчас есть. Включается автоматом при подлете самолета к дому и отсутствия связи. Сначала кругами сброс высоты до 10м, а затем выпрямление и снижение до 2м. Затем выключение движка и планирование до встречи с планетой. Место посадки не выбирается сейчас, садится куда попало. А в будущем да, сонар прикрутим будем по траектории заходить в заданное место посадки. А пока режим посадки, это чисто подстраховка отсутствия радиоканала.
…в будущем да, сонар прикрутим будем по траектории заходить в заданное место посадки.
Мысль на далекую перспективу: было бы круто иметь систему визуального распознания какого-нибудь маркера начала посадочной полосы. В связке с хорошо работающим сонаром, это позволит выполнять посадки с ювелирной точностью. 😃 А может и самодельную PAPI задействовать 😃
Мысль на далекую перспективу:
Маркер на противника, взрывчатку и 😃
Закроют нас…
Хотя сама идея устройства не плоха.
Угу. Но без хотя бы 10 ШИМ и дальнобойного передатчика это игруха на “погонять кота по дому”.
Я вот задумался именно в этом плане.
А по ценнику еврейский компулаб вообще вне конкуренции.
Там буквы в мане не знакомые школоте 😉
Только вот сборку оси
Ещё не забываем, что линукс с андроидом, это не RTOS. Ну подключат они гироскоп к порту, дальше то что? 😃
Надо найти контроллер, типа tiny48 с уартом, +5В питанием и чтоб дешево. Нужен кварц. в 1см поместится ли?
Серва D-MG16 имеет в качестве мозгов какой то атмеловский чип (кажется ATMEGA8, могу уточнить) Вот этот чип можно перешить под междумордия интерфейса по нужному протоколу 😎. Ну нужно реверсить родную прошивку сервы насчет штатного режима работы.
Ещё не забываем, что линукс с андроидом, это не RTOS. Ну подключат они гироскоп к порту, дальше то что? 😃
поставят Win7 😇
И еще такая мысль. Уж если идти в сторону общей шины, то никак не SBUS.
CAN?
Реальный 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?
У меня пробел в познаниях существующих треккеров. 😃 ОК. Аппаратно я заложу возможность вынуть цифровой поток из аудиоканала. Но программную поддержку пока только в список хотелок в самый конец могу добавить.