Open Source контроллер для квадрокоптера
Вот вам конструктивная критика: Убрать из подключения двигателей стрёмные клеммные колодки. По опыту - держат провод они ровно пока тянешь винт отвёрткой. А то потом будете искать баги в коде, а у вас просто провод болтаться в разъёме будет. Ну я уж не говорю про вес и сопротивление потоку винта =)
Второе - XBee и комповый джойстик - тупиковый вариант. По стоимости как дешёвый ХКшный пульт, по удобству - УГ, по дальности - УГ в квадрате. На отладку сойдёт, конечно. Но на будущее надо сразу предусматривать подключение нормальных приёмников РРМ/PWM.
А чем не устраивает Naze32? Open source, и как раз под STM.
abusemark.com/store/index.php?main_page=product_in…
А чем не устраивает Naze32? Open source, и как раз под STM.
Судя по всему, тем что он готовый, а тут полный цикл производства софта (железа) - совсем другой интерес к этому делу 😃 Ну и потом сказать - это наше (в плане что сами сделали).
А так да, проектов под STM уже хватает, делать что то новое наверное нет резону…
Второе - XBee и комповый джойстик - тупиковый вариант. По стоимости как дешёвый ХКшный пульт, по удобству - УГ, по дальности - УГ в квадрате. На отладку сойдёт, конечно. Но на будущее надо сразу предусматривать подключение нормальных приёмников РРМ/PWM.
Здесь полностью согласен! Стандартная поддержка РРМ/PWM, всякие джойстики только как альтернативные виды контроля.
Вот вам конструктивная критика: Убрать из подключения двигателей стрёмные клеммные колодки. По опыту - держат провод они ровно пока тянешь винт отвёрткой. А то потом будете искать баги в коде, а у вас просто провод болтаться в разъёме будет. Ну я уж не говорю про вес и сопротивление потоку винта =)
Спасибо, пару раз уже натыкались, учтем.
Второе - XBee и комповый джойстик - тупиковый вариант. По стоимости как дешёвый ХКшный пульт, по удобству - УГ, по дальности - УГ в квадрате.
У digi есть 900MHz чипы с дальностью до 64км. Здесь больше вопрос сертификации, в России пока что официально купить можно только до 4500м. Опять же - цифровой канал.
На отладку сойдёт, конечно. Но на будущее надо сразу предусматривать подключение нормальных приёмников РРМ/PWM.
Здесь полностью согласен! Стандартная поддержка РРМ/PWM, всякие джойстики только как альтернативные виды контроля.
С другой стороны поддержку стандартного оборудования никто не отменял, его в любом случае надо делать. К тому же комплект оборудования уже ждет своей участи)
А чем не устраивает Naze32? Open source, и как раз под STM. abusemark.com/store/index.php...products_id=30
Ребята однозначно молодцы, но никто же не запрещает нам делать тоже)
Опенсорс так и живет - форкнул или начал с нуля, посмотрел идеи, добавил свои. А в итоге выживает сильнейший проект. Иначе бы из линуксов сейчас существовал один Debian или Slackware
А чем не устраивает Naze32
Меня лично устраивает качество с которым оно изготовленно, а неустраивает упертость таймкопа и его разнообразные прихоти. Он совершенно невменяем, и напроч отказывается включать поддержку того что ему не интересно - например жпс и сонар. Или менять датчики например…
например жпс и сонар
свободен один Uart но там по ходу телеметрия, проц побольше бы - лап этак на 100…
лап этак на 100
Что мешает мультиплексировать лапы? =)
У digi есть 900MHz чипы с дальностью до 64км… купить можно только до 4500м. Опять же - цифровой канал
А сколько такие чипы стоят? И Я так полагаю, самопальную плату не разведёшь под это, надо покупать готовое? То есть вопрос не о ценнике чипа, а о ценнике некоей DevBoard? 4.5 км - я так полагаю, что это над морем каким-нибудь. Преимущества цифрового канала надо реализовывать с оглядкой на потерю процентов 70 пакетов, тогда можно говорить о какой-то безглючности.
Меня лично устраивает качество с которым оно изготовленно, а неустраивает упертость таймкопа и его разнообразные прихоти. Он совершенно невменяем, и напроч отказывается включать поддержку того что ему не интересно - например жпс и сонар. Или менять датчики например…
Да, действительно утомляет его AVR - дерьмо - один я в шоколаде…
Его плюс в том, что сделал недорогую платку на новой платформе… пройдет немного времени и будут платки и с GPS’ом и нормальным барометром. Я спрашивал у CSG_EU, у него то же есть какие то наработки, но т.к. некому писать софт, он и не делает ничего (хотя у него есть проект Нано квадрика, то же на STM)
А вы Алексей, что-то притихли со своей платкой, туда по идее Multipilot32 портировать можно?
А вы Алексей, что-то притихли со своей платкой, туда по идее Multipilot32 портировать можно?
У меня банально нет времени. Начался строительный сезон, а я строю дом… По мере возможностей, портирую MPNG
А сколько такие чипы стоят? И Я так полагаю, самопальную плату не разведёшь под это, надо покупать готовое? То есть вопрос не о ценнике чипа, а о ценнике некоей DevBoard? 4.5 км - я так полагаю, что это над морем каким-нибудь. Преимущества цифрового канала надо реализовывать с оглядкой на потерю процентов 70 пакетов, тогда можно говорить о какой-то безглючности.
Сам чип развести - наверное нетривиальная задача, а вот модули достаточно удобны - у них одинаковое посадочное место для любого модуля Xbee. На спаркфане модуль на 24км по открытой местности стоит 60 долларов, 65км - 180 долларов.
DevBoard для Xbee обычно предназначены для подключения к компьютеру и в них вставляется готовый модуль Xbee.
Потери решаются обязательной контрольной суммой, главное всегда знать RSSI и иметь достаточный latency.
Опять же - я не говорю что XBee это имба, но как еще один вариант управления - почему бы нет?
Потери решаются обязательной контрольной суммой
Не-не-не… Какая контрольная сумма? Под потерей я понимаю тупо неприход, например, 6 управляющих посылок из 10, причём, возможно, подряд. Контрольная сумма - само собой, просто надо понимать, что в условиях активных помех - есть шанс не получить вообще ничего в течение довольно продолжительного времени. И это надо обрабатывать.
Не-не-не… Какая контрольная сумма? Под потерей я понимаю тупо неприход, например, 6 управляющих посылок из 10, причём, возможно, подряд. Контрольная сумма - само собой, просто надо понимать, что в условиях активных помех - есть шанс не получить вообще ничего в течение довольно продолжительного времени. И это надо обрабатывать.
Т.е. надо иметь или подходящий latency или неподходящий latency вместе с более самостоятельными мозгами на коптере?
Т.е. надо иметь или подходящий latency или неподходящий latency вместе с более самостоятельными мозгами на коптере?
Я за второй вариант. Ибо длину задержки вы угадать всё равно не сможете. много-много суперкоротких команд - вариант, но при капитальном глушаке надо иметь фейлсейв, при чём понимать, когда “писец, аппаратура разрядилась на земле, садимся медленно”, а когда “что-то давно уже не было команд с аппаратуры, не пора ли повиснуть и подождать малость?”, ну и когда “опа, половина пакетов потерялась, ну и фиг с ним, восстановим, летим как ни в чём не бывало”
Я за второй вариант. Ибо длину задержки вы угадать всё равно не сможете. много-много суперкоротких команд - вариант, но при капитальном глушаке надо иметь фейлсейв, при чём понимать, когда “писец, аппаратура разрядилась на земле, садимся медленно”, а когда “что-то давно уже не было команд с аппаратуры, не пора ли повиснуть и подождать малость?”, ну и когда “опа, половина пакетов потерялась, ну и фиг с ним, восстановим, летим как ни в чём не бывало”
Общая идея понятна, спасибо за совет!