Open Source контроллер для квадрокоптера
Доброго дня!
Делаем проект полетного контроллера на основе ARM. За основу взяли отладочную плату от ST STM32F4DISCOVERY, в качестве IMU - CHR-6d. Управление сейчас осуществляется по иксби с помощью обычного компьютерного джойстика, регуляторы MAYTECH 20A, двигатели Turnigy D2836/11 750KV, винты 10x4.7
Начинали правда не с ARM, а с AVR, но, вскоре, осознали свою ошибку:)
Результаты пока скромные:P
Вот, что сейчас имеем:
ничего не понятно… оно летает? или только медленно между стульями крутится?
если летает - где видео? если не летает, то как понятно что это перспективно?
если это Open Source, то где ссылка на исходники?
или еще один длясебяпобаловаться проект? - тогда ветка со своим стабом уже есть, можно было туда писать
Нет, пока не летает. Исходники будут, когда появятся результаты, которыми можно будет делиться, а писать в чужую ветку не очень хочется. Вообще опыта конкретно в коптеростроении мало, поэтому ждем конструктивной критики)
поэтому ждем конструктивной критики)
да пока критиковать ничего
Для начала надо создать кучку документов с описанем целей проекта и чем он будет отличаться от десятка прочих. Затем накидать примерные диаграммы программной и аппаратной реализации, а также алгоритмы управления. Выложить это все на подходящей площадке для коллективной работы. Пока что в таком виде это “побаловаться” на пару вечеров, а не open source.
Нет, пока не летает. Исходники будут, когда появятся результаты, которыми можно будет делиться, а писать в чужую ветку не очень хочется. Вообще опыта конкретно в коптеростроении мало, поэтому ждем конструктивной критики)
Молодцы, но есть одно большое НО. Как вы можете ждать критики если нет кода? Открываете проект например тут code.google.com и вы удивитесь и прогрессу и критике и всему остальному.
с такой вялой реакцией на отклонения аппрат летать не будет
с такой вялой реакцией на отклонения аппрат летать не будет
Ну так это же только начало, молодцы что начали такое дело, если на ноги поставят это вообще тема будет. На дискавере процессор ARM M4 стоит с частотой 160мгц, а сама плата 20 баксов стоит. Ни одна атмега даже рядом не валялась по перспективам. К ней можно вообще любую перефирию подключить, причем в прямом смысле любую, это почти компьютер
Молодцы, но есть одно большое НО. Как вы можете ждать критики если нет кода? Открываете проект например тут code.google.com и вы удивитесь и прогрессу и критике и всему остальному.
Абсолютно с вами согласен. На самом деле мы завели эту тему, чтобы показывать ход работ над проектом сообществу. После того как мы дойдем до стабильного результата - будем выкладывать в общий доступ. Будет это гитхаб или гуглокод - не суть важно.
Для начала надо создать кучку документов с описанем целей проекта и чем он будет отличаться от десятка прочих. Затем накидать примерные диаграммы программной и аппаратной реализации, а также алгоритмы управления. Выложить это все на подходящей площадке для коллективной работы. Пока что в таком виде это “побаловаться” на пару вечеров, а не open source.
Обязательно.
На самом деле сейчас уже есть платформа с хостингом кода, сборками кода и коллективной работы. Сейчас к ней имеют доступ закрытая группа людей, мы определяем что и как нужно делать, выявляем некие стандарты разработки, чтобы результат был единообразен. Как будут достигнуты поставленные цели, начнем расширять круг доступа.
Ну так это же только начало, молодцы что начали такое дело, если на ноги поставят это вообще тема будет. На дискавере процессор ARM M4 стоит с частотой 160мгц, а сама плата 20 баксов стоит. Ни одна атмега даже рядом не валялась по перспективам. К ней можно вообще любую перефирию подключить, причем в прямом смысле любую, это почти компьютер
Да, ST нынче делает такие контроллеры по таким смешным деньгам, что непонятно почему Атмеги вообще еще живы:)
с такой вялой реакцией на отклонения аппрат летать не будет
Здоровая доля скептицизма - это то, чего не хватает нашему проекту именно сейчас. Пинок под зад - один из лучших мотиваторов)
Вот вам конструктивная критика: Убрать из подключения двигателей стрёмные клеммные колодки. По опыту - держат провод они ровно пока тянешь винт отвёрткой. А то потом будете искать баги в коде, а у вас просто провод болтаться в разъёме будет. Ну я уж не говорю про вес и сопротивление потоку винта =)
Второе - 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 вместе с более самостоятельными мозгами на коптере?
Я за второй вариант. Ибо длину задержки вы угадать всё равно не сможете. много-много суперкоротких команд - вариант, но при капитальном глушаке надо иметь фейлсейв, при чём понимать, когда “писец, аппаратура разрядилась на земле, садимся медленно”, а когда “что-то давно уже не было команд с аппаратуры, не пора ли повиснуть и подождать малость?”, ну и когда “опа, половина пакетов потерялась, ну и фиг с ним, восстановим, летим как ни в чём не бывало”
Я за второй вариант. Ибо длину задержки вы угадать всё равно не сможете. много-много суперкоротких команд - вариант, но при капитальном глушаке надо иметь фейлсейв, при чём понимать, когда “писец, аппаратура разрядилась на земле, садимся медленно”, а когда “что-то давно уже не было команд с аппаратуры, не пора ли повиснуть и подождать малость?”, ну и когда “опа, половина пакетов потерялась, ну и фиг с ним, восстановим, летим как ни в чём не бывало”
Общая идея понятна, спасибо за совет!