flybrain. передатчик + приемник + автопилот. powered by stm32
перед каждой сервой и уложиться рублей в 100 на серву,
Питание надо? Это раз, два. Сигнальчик это три. А питание то не одно для всех? Ну дополнительную ниточку сигнальную на устройство прокинуть? Мне не влом. Итого на плоскость два питания и по одному на устройство. Ну два… Ну три! И это не сто рублей. И из-за этого ломать голову? Даже пыль с чехла на знамени сдувать бы не стал… 😃
Надо найти контроллер, типа tiny48 с уартом, +5В питанием и чтоб дешево. Нужен кварц. в 1см поместится ли?
Чип обманка из струйника
ATtiny45-20SU - 60 руб + кварц kx-9 ~40руб + разъемы(2шт) + пара кондеров. Ну в принципе, почему бы и не попробовать.
ндаа… столько работы проделать за такой короткий срок… снимаю шляпу. Я на сайте алекса читать устал… кароче - круто, что ещё сказать 😃
AlexSneg, а планируется ли автопосадка в будущем? Будет ли для этого задействован сонар для точного определения расстояния на сверх малых высотах?
Аварийная автопосадка и сейчас есть. Включается автоматом при подлете самолета к дому и отсутствия связи. Сначала кругами сброс высоты до 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. Раз даже процы горят.