flybrain. передатчик + приемник + автопилот. powered by stm32
Ты что, без меня заказывать собрался!?
Ты сказал, что не готов еще, я и не беспокоил тебя. Так то уже все заказано…
В личку написал.
Эх ты… даже и не сказал, что заказал… Я тут весь сайт мозголета вычитал… изучил, так сказать 😃
Ну ладно, будешь первым 😃
Если же ты знаешь формат радиопакета Эксперта, что мешает добавить и его в приемник?
Алексей, а давайте двигаться в сторону хороших стандартов. Вы реализовали SBUS вход. Я на днях доделаю SBUS выход с приемников с протоколом Эксперта. Учитывая, что мои прошивки передатчиков уже используют SBUS вход, получается полностью цифровой тракт на 10-12 каналов с 11-битной точностью и периодом пакетов 7-14-31 мс.
Если к этому еще добавить мелочи типа RSSI через один из PPM/PWM каналов, поддержку 2-3 сателитов, и сигнализацию о потерях пакетов в SBUS, то получится всем удобно. 😃
Александр, я думал о том чтобы договориться уже всем вместе о стандарте канала между АП и приемником. Но чистого SBUS недостаточно. Лично мне надо двусторонний UART. Так как я передаю приемнику дополнительную информацию и хочу от него иметь много чего еще кроме стандартных каналов. Кроме того, приемник не должен гнать ничего на сервы, без приказа АП. Приемник должен работать слейвом.
Предлагаю это отдельно обсудить, может даже в отдельной теме. Эксперт, Тимофей, Слон и все остальные пусть присоединяются, если хотят. Выработаем стандарт, пользователи только выйграют. Я сегодня сделаю описание моего канала в текущей реализации, выложу. Можно будет взять за фундамент от чего отталкиваться и добавить всем, кому что надо.
Так как я передаю приемнику дополнительную информацию и хочу от него иметь много чего еще кроме стандартных каналов.
Что, например?
Кроме того, приемник не должен гнать ничего на сервы, без приказа АП.
Типа избавить АП от лишних разъемов? Коль на приемнике и так есть гребенка, пусть он за все сервы и отвечает?
ИМХО это черезчур хитро. Проще разделить сущности. Если нужен расширитель выходов для АП, сделайте его отдеьно. Или гоните тот-же SBUS на футабские сервы и хабы…
Лично мне надо двусторонний UART.
У меня на UART большие планы, поэтому я так упорно все фишечки делаю на обыных ножках. 😃
Предлагаю это отдельно обсудить, может даже в отдельной теме. Эксперт, Тимофей, Слон и все остальные пусть присоединяются, если хотят. Выработаем стандарт, пользователи только выйграют. Я сегодня сделаю описание моего канала в текущей реализации, выложу.
Давайте обсуждать. Я - за. Жду описания.
А вот почему бы вот такую www.ebay.com/itm/…/261261765934 плату датчиков не использовать? ИМХО и дешевле и проще.
ИМХО и дешевле и проще.
Есть изначальная концепция - не плодить лишних проводов и модулей, поэтому все автономно на одной плате.
ИМХО это черезчур хитро.
Ничего хитрого. Сейчас это так у меня и работает.
Если нужен расширитель выходов для АП, сделайте его отдеьно.
Уже сделал, но для самодельных приемников, от которых существуют исходники, это лишнее. У приемника уже все разъемы есть. Зачем плодить еще одну аппаратную сущность, если достаточно добавить код в прошивку.
Или гоните тот-же SBUS на футабские сервы и хабы…
SBUS требует аппаратной инверсии, понятно, что Футаба пыталась сделать так, чтобы жизнь хаккерам медом не казалась. ИМХО УАРТ без всякой инверсии гораздо легче для уже существующих приемников. Опять же я имею ввиду только протокол двустороннего взаимодействия АП и приемника. Гнать SBUS на сервы смысла нет, так как ни у кого таких серв нет. Хотя вот, что у меня тут готовится к следующему сезону:
Эта штука может управлять чем угодно. Например можно не серву прицепить, а БАНО
Я тоже добавляю дискретные выхода на приемник. 😃
А инвертированность SBUS даже для меги не проблемма, не говоря уж о STM.
Если хотите, могу выдавать неинвертированный сбас?
Если хотите, могу выдавать неинвертированный сбас?
Александр я и так прием СБАС уже реализовал для СТДАПП. Если вы готовы, рассмотреть вариант именно двустороннего, неинветированного УАРТ между приемником и АП, тогда есть для меня смысл эту тему развивать. Если же как бы желания у Вас нет этой теме время посвящать, то мне проще самому сделать поддержку эфирного канала для OPEN LRS и Эксперта. Потому как вот, что у меня уже готово к испытаниям в воздухе:
И надо заканчивать уже с RFM22. 69я делает ее по дальности и избирательности как два пальца об асфальт. Есть конечно нюансы по автоматическому AFC. Но вроде как я порешал эти проблемы в первом приближении.
Если вы готовы, рассмотреть вариант именно двустороннего, неинветированного УАРТ между приемником и АП, тогда есть для меня смысл эту тему развивать. Если же как бы желания у Вас нет этой теме время посвящать, то мне проще самому сделать поддержку эфирного канала для OPEN LRS и Эксперта
Алексей, на Вашем месте, при наличии своего приемника, я бы варианты чужих приемников даже не рассматривал. 😃 Тем более при таком “Развороте” идеологии, как Salve-приемник. Понимаю, что Вам такой подход удобнее, так как минимизирует количество разъемов на АП, переваливая их груз на приемник, дескать там и так они есть.
Возразить могут только одним примером - приемники саттелиты. Маленькие, только с одним последовательным выходом (максимуум UART+PPM/SBUS), зато размещаемые где уголдно и с ортогональной поляризацией антенн. У них нет гребенки разъемов и для них важно, кто будет арбитром: АП (в идеале) или “главный” приемник. Я у себя реализовал второй вариант - один главный приемник и до 4-х статтелитов взаимодействующих с ним через UART (цепочка типа TX1->RX2; TX2->RX3 … RXглавный…).
Ну еще “пример с натяжкой” - GSM модем в качестве альтернативного канала. Гребенки разъемов серв у него нет по определению…
И надо заканчивать уже с RFM22. 69я делает ее по дальности и избирательности как два пальца об асфальт.
Коль так, ИМХО, заморачиваться с “чужими” приемниками или изобретать новый универсальный протокол обмена пока ни к чему.
Актуализовал документацию. Скачивается одним PDF файлом.
…narod.ru/…/FlyingBrain_User_Manual_v1.3-031113.pd…
добавил новую прошивку на сайте FlyingBrain-0.1.0.277.zip
Обучил ее работать с EB-800. Сделал описание как настраивается EB-600 штатными средствами АП. Никаких дополнительных UART коннекторов больше не нужно.
Те, кто сам собирает, EB-500 больше не заказывайте. Берите либо EB-600, либо EB-800. Они гораздо лучше работают в нашем деле.
Что-то в наших конубрях нет EB600,800 и вообще никаких EB.
Это ведь не принципиально? Можно и например www.ebay.com/itm/…/190889252601 такой взять?
Что-то в наших конубрях нет EB600,800 и вообще никаких EB.
Это ведь не принципиально? Можно и например www.ebay.com/itm/GY-NEO6MV2-F...item2c71e2d6f9 такой взять?
Такой подойдет только если делать внешний GPS.
Все EB (и 500 и 600 и 800) есть в chip-nn.
Это ведь не принципиально?
На плате футпринт под EB500/600/800A, они есть в chip-nn.ru
Если ставить внешний, то ищите с чипом MTK, иначе придется в настройках модуля шаманить и мне в прошивке что-то ковырять, чтобы распознать, что вы там ему подсунули. Разъем для внешнего GPS на плате разведен, можете им воспользоваться, но персонально мне такие решения не нравятся.
Собрал АП, ковыряюсь.
Долго не мог запустить EB-600, молчал, как партизан. Подвешивание 10мкФ между ресетом модуля и землёй решило вопрос. Возможно, это связано с медленным нарастанием питающего 3.3 после включения.
При попытке откалибровать магнитный компас минимальное значение по первой оси скачкообразно улетает с примерно 600 до 4096, соответственно, офсет по этой оси около 2000, по остальным около 50.
Нормально ли это?
Подвешивание 10мкФ между ресетом модуля и землёй решило вопрос
возможно. Через меня прошли три EB-600, вроде запускались все с ресетом в воздухе. Ну будем считать это вариантом фикса. EB-500 - да хотела кондер. Ну главное, что запустилось.
mon on gps_raw показывает данные с EB-600?
У меня в PDF инструкции есть последовательность команд, как ее перевести в правильный режим.
Нормально ли это?
нет. 4096 это перегрузка для АЦП датчиков. Не должно такого быть.
Если плата в горизонте, что показывает консоль на эту команду:
mon on mag
???
Какой чип использован LSM303DLH или DLM?
4096 это перегрузка для АЦП датчиков. Не должно такого быть.
уменьши mag_gain в настройках чипа раза в 2, чтобы по осям значения были ок ±300, а то в разных регионах может шкалить
У меня максимум 580 показывало, что я у себя на широте НН видел.
Димитрий чуть скрупулезнее поисследуйте этот момент. По всем ли осям зашкаливает. Ибо если зашкаливает, то должны быть положения зашкаливания для всех осей. Но я думаю это не реально для Москвы. Телион в Москве летает, ничего у него не шкалит.
Акселерометр в том же чипе, с акселем все в порядке?
mon on accel Должно 1G по осям показывать, когда плату разными ребрами в направлении земли ориентировать.
Он не по всем шкалит, а по рандомной, и не на всех чипах. Железка сама такая, глюковатая. Учись с этим жить 😁
Железка сама такая, глюковатая
Ну если выброс единичный, случайный, значит просто еще раз калибровку запустить с нуля.
Если выброс в процессе обработки данных приходит, то на это по фиг. В обработчике все равно все через ФНЧ идет.
Сегодня у себя понаблюдаю, может у меня тоже есть выбросы рандомные по осям, но реально не припомню такого.
4096 это перегрузка для АЦП датчиков. Не должно такого быть.
Однако, проявлялось стабильно при каждой калибровке.
Откалибровал в другом месте. Всё нормально, видимо, предыдущее место нехорошее