Здравствуйте. Обратите пожалуйста внимание на протоколы: 1. CRSF (поверх UART) между пультом и приемником. Это сейчас самый распространенный протокол, который реализует, то что вы написали. Используется на FPV. 2. Протокол Mavlink. Он несколько сложнее, структуры данных в нем определяются разработчиком, а код для контроллеров (или ПК) можно создать кодогенератором по необходимой вам структуре. 3. Использование LoRa полностью поддерживаю. Обратите внимание на модули с выходной мощностью 5Вт. Этого может быть достаточно (с направленной антенной передатчика) для работы на десятки километров.
Здравствуйте, по 1-2 - я недавно как раз ознакомился поверхностно с этими понятиями, с одной стороны было неловкое чувство досады, что я в очередной раз изобретал велосипед, с другой в целом удовлетворение, что все делал правильно, как и "профессионалы". В защиту проприетарных (или кустарных?) разработок скажу, что если задумываться в сторону безопасности - они могут быть надежнее, так как стандартные протоколы известны, можно пытаться перехватывать управление и т.д. А когда создается что-то кастомное, как перехватить управление? Нужно время, чтобы взломать "код". А если еще какой-то своей крипты докинуть простенькой, то и вообще задача будет непростая. по 3 - посоветуете заводские модули такие глянуть? Меня вот в этой связи интересовали два вопроса: - если взять железки типа под ELRS - они могут работать как удлинитель UART, передадут кастомный поток данных, подаваемый им на вход не в Mavlink или CRSF? - видел что обычно под ELRS идут мощные передатчики, а на борт ставятся маломощные приемники, то есть поток данных односторонний подразумевается?
@well_techn E22-230T37S 5Вт - также на AliExpress (ссылку не вставляю, RUclips это не нравится). В этом передатчике чрезвычайно актуальный сейчас частотный диапазон. 4. Типичное значение частоты отправки пакетов телеметрии 1:64 (или 128). То есть на 64 пакета управления от пульта отправляется один пакет телеметрии с дрона. Дело в том, что в ELRS приемниках стоит очень дохлый МК ESP8266, его лучше лишний раз не нагружать.
@well_techn Нет, не передадут кастомные пакеты. Там очень ограниченный набор входных протоколов, определяемый в конфигураторе (приемника и передатчика): CSRF, SBUS, inverted SBUS, PPM - больше ничего. И в пакетах этих протоколов внутри просто значения 16 каналов и проверка целостности пакета.
@well_techn Типичная мощность передатчика телеметрии внутри приемника ELRS (звучит странно, согласен) от 10, 50, 100мВт - зависит от серии и производителя. Больше, как правило, не нужно: у дрона в воздухе большое преимущество перед пультом в отношении условий радиовидимости (просто выше всех препятствий). Кроме этого значимость канала телеметрии сильно меньше, чем канала управления.
@well_techn кроме этого передатчик ELRS подключается не по UART. Там S.PORT - однопроводный UART со смещенной нулевой линией сигналов. Понадобится физический конвертер сигналов S.port - UART.
Привет! Спасибо за видео! Как понял, в проекте используется встроенный АЦП ESP (например, для оценки положения джойстика, также наверняка, для определения напряжения аккумкляторов). Читал много раз, что АЦП у данного МК является не очень точным. Соответственно вопрос: в ПО используются совсем-совсем сырые данные или предусмотренна какая-то калибровка?
пульт я писал не на ESP32, но в принципе с АЦП на ESP32 слегка работал, мерил напряжение батареи через делитель, пока не поставил под эти нужды отдельный чип. Негатива особо не было, была какая-то аддитивная погрешность, но не криминально. В целом если через АЦП на ESP32 джойстики считывать абсолютная точность тут не нужна великая, как по мне
Спасибо за видос, сам тоже собираю свое радиоуправление, сначала думал юзать модули HC-12, но они маломощные, для тестирования в комнате или в пределах видимости неплохо, потом тоже прикупил ЛОРУ, вот они уже намного лучше. Так же решил свой протокол сделать, тоже делал пакет и контрольные суммы. Только вот с обратной связью у меня не задалось, она все тормозила сильно. Вообще пока не до конца понимаю концепцию выполнения задач на FreeRTOS - не могу понять как и в какие тайминги будет выполняться та или иная задача. Допустим у меня есть три основных задачи - стабилизация дрона (опрос датчиков + ПИД), Прием данных от пульта, Отправка обратной связи - на какие ядра и с каким приоритетом мне их раскидать? Я всегда делал всем приоритет наивысший. Так же с приоритетами не совсем понятно (я понимаю что там есть планировщик) - как приоритет влияет на задачи? Кто-то мне сказал что задача с наименее низким приоритетом никогда не запустится...
задача во FreeRTOS - это функция, содержащая в себе бесконечный цикл. Диспетчер задач внутри FreeRTOS каждые сколько-то миллисекунд (по умолчанию 10) отдает на выполнение то одну задачу, то другую + некая логика по приоритетам, что делать если одна задача важнее другой. Если интересно разобраться - настоятельно рекомендую официальный сайт, там в целом все адекватно расписано. Я вот в этом видео очень кратно зачем нужен FreeRTOS касался ruclips.net/video/dc7WpKdmI9w/видео.htmlsi=LmlcI6dPN3BfkBQ1
по приоритетам - во FreeRTOS при дефолтных настройках используется вытесняющая логика, то есть: - если две задачи имеют равные приоритеты, они запускаются планировщиком по очереди, сменяя друг друга каждый тик - если при выполнении задачи с меньшим приоритетом возникает задача более высокого приоритета - проц мгновенно переключается на выполнение более приоритетной задачи, не дожадаясь конца тика - когда задача наивысшего приоритета выполнится, операционка посмотрит, какая из ожидающих выполнения задач имеет высший приоритет и возьмется за нее.
При моем подходе основная идея в том, что у меня задачи сидят в состоянии Blocked, пока не придут данные через очередь или tasknotify. Тогда просыпаются и в соответствие с приоритетом передаются на выполнение.
Поизучайте ссылку ниже, там это описано www.freertos.org/Documentation/02-Kernel/02-Kernel-features/01-Tasks-and-co-routines/04-Task-scheduling По части разбросать по ядрам - ссылка на структурную схему как я делал в описании. Стабилизация (опрос датчиков + ПИД) в моем понимании важнейшая задача, в пределе если она застопорися дрон просто потеряет контроль, поэтому эта единственная задача на ядре, чтобы ее ничего не отвлекало. Прием управляющих команд имеет высокий приоритет на другом ядре, так как опять же управляемость в приоритете, а вот телеметрия это вторично, может и подождать.
а собственно что еще надо ), любая передача данных к этому сводится, просто сверху можно еще докидать крипту, помехозащищенное кодирование и т.д. Есть специфические задачи, когда, например, целесообразно вынести передающую антенну пульта подальше от оператора, была мысль что в теории вместо UART между пультом и передающим модулем можно использовать RS485 и разнести передающий модуль и пульт управления на расстояние (в пределе 1200м по проводу, столько вроде 485 тянет со спецификации). Будет задержка какая-то наверное, но все же.
я бы значения с ацп пульта просто 8 битные брал и убрал стартовый и eol просто проверяя что в буфере 7 байт, потому что как я понял все равно прерывание будет от каждого принятого байта, а не от только от FF
это очень хороший вопрос! Действительно, на первый взгляд прерывание (событие) типа UART_DATA должно генериться каждый байт (что есть пустая дерготня процессора), но я проверял (ставил в case UART_DATA действие типа printf посмотреть как часто он происходит). Результат - событие UART_DATA не генерится каждый байт, а генерится изредка по непонятной мне логике. Искал на форумах внятные условия генерации события UART_DATA - не нашел, доразберусь как-нибудь. А касаемо убрать "старт" и CRC - можно, так как целостность данных вроде как должен обеспечивать приемопередатчик, но по факту много раз наблюдал как часть пакета терялась, на приемную сторону приходили огрызки данных. Без доп. контроля целостности есть риск вкинуть на Throttle что-то нерелевантное, чего очень бы хотелось избежать. Контроля много не бывает )
не очень понял вопрос. Если речь про встроенные возможности крипты на ESP32, пара библиотек под эти нужны в ESP-IDF есть, типа esp_tls.c. Вот тут неплохой пример с чего можно начать medium.com/@bhautik.markeye/esp32-aes-encryption-using-esp-idf-for-a-string-of-any-length-85fc46ad0d73
Я не вижу принципиальной схемы, это бестолковый набор модулей. И структурную схему не все умеют читать, это чисто школьные приколюхи, там нет точных связей. И пдф надо вытягивать по вертикали, напрягаешь листать влево-вправо, потому что тебе так захотелось. В остальном концепция такая. У дрона антенна узкополосная. У передатчика направленная, типа рамки или патч, это повышает дальность. Также понижение частоты увеличивает дальность. Телеметрию и канал связи лучше разносить на разные частоты, например дрон отключился, но по телеметрии видно, что дрон разворачивается домой или садится аварийно с указанием координат, чтобы потом не искать его на площади 10х10 км. Не надо применять миниатюрные модули приема, там нет фильтров и значит любые искры рядом, гасят связь. Дрон должен принимать-передавать реальные цифры, не надо заставлять его пересчитывать, это время и пусть пересчет делает база. Не надо сажать все на прерывания, это гигантская ошибка. Хорошо, когда уарт сам трудится, проц отдыхает, но тут проблема в помехозащищенности уарта и если хочется повысить ее, тогда сам проц должен принимать и отправлять биты, там можно порулить и вытянуть плохой сигнал. Наивные попытки попытки 2 раза отправлять сигнал, плохо работают, лучше подумать об избыточных битах и исправлять исходные биты. В общем, все как обычно, ардуинщик заявил про революцию, собрал из модулей и написал код, хуже стандартного.
Начну с конца - не подскажете, где заявлено про революцию? Я, как мне кажется, не устаю повторять, что это, по сути, учебный проект, основная цель которого - дать начинающим в этой сфере понимание как можно строить подобные системы. Прежде чем собирать условный Boeing, надо понять как летает самолет братьев Райт, этот проект ближе ко второму. А разобравшись с ним, видя его недоработки - можно развиваться дальше. Данный проект это не конкуренция Пиксе, Арду и иже с ними, которые десятилетиями писались командами, поэтому, очевидно, "хуже" стандартного на Ваш взгляд. В русскоязычном сегменте не много подобный проектов "для начинающих инженеров", и чем больше их будет - тем больше людей задумаются что можно делать что-то свое и расти профессионально, а не просто портировать Пиксу. Теперь по конкретике: - про антенны и частоты все примерно так и озвучивалось, противоречий не вижу - про то, что лучше не обрабатывать на дроне, а передавать готовые данные - согласен, обдумывал это, решил что в данном случае не хочу передавать float'ы через канал, это бы увеличило длину пакета, который и так ходит на этом железе очень медленно, а мощи на ESP32 крутанусь пару операций хватает. Есть, конечно, варианты в любом случае, так что этот тезис поддерживаю - про то, что темеметрию можно сажать на отдельный канал - да, безусловно в профессиональных разработках это, пожалуй, оправдано. Чем больше каналов - тем меньше вариантов их задавить одновременно, если Вы про это. Для подобной разработаки плодить кол-во каналов наверное избыточно, 1 канал на управление, второй на телеметрию, 3й, если вдруг - на RTK поправки, 4й на FPV... Я в принципе подумал, что по сути телеметрия сейчас вся кладется оверлеем на FPV, тогда от обратки под нее можно в принципе отказаться, и не придется использовать мощный передатчик на борту для ее отправки. - про выбранные модули - да, любительский вариант, для бытовых нужд хватает и не нарушает ГКРЧ. При такой концепции выбор других приемопередатчиков- это как смена физического уровня в OSI, не влияет на прикладной. - про то что плохо использовать прерывания, " проц должен принимать и отправлять биты" и "вытянусь плохой сигнал"- Вы про коды Хэмминга и им подобные? Да, вариант правильный, но это опять же, как по мне, задача физического/канального уровня передачи, не прикладного. Выше мы согласились, что проц не надо нагружать лишней обработкой, эти функции хорошо бы на приемопередатчики возложить.
@@well_techn Читать не умеем. Телеметрия нужна в первую очередь, чтобы найти упавший дрон. Значит, никогда его не искал. Управление надо связать с телеметрией, на пределе дрон не сможет принять данные управления по причине малой антенны, но вот база принять телеметрию может, потому что антенна хорошая, а дрон вернется сам и подхватит сигнал управления. Видео надо отдельным скоростным потоком передавать, обычно это вайфай и оверлей там для чисто для прикола. Зачем пихать это в один поток ? Тогда конечно 500м дальность, это потолок. Сам себе проблемы создаешь, еще и пихаешь мысль, что надо мощность повышать. Нахрена ? Для видео - да, для телеметрии - нет, там важнее правильный модуль с фильтрами. Какие-то странные мысли про флоат, вычислил его и работай дальше с целочисленным, поменялось - флоат и опять работа с целым. Нахрена грузить бедный дрон астрономическими вычислениями с бесконечной точкой. Я не совсем понял, 100 команд в секунду это мало ? У тебя скорость 38к-112к, это более 1000 команд. Зачем ? И для этого нужен м7 с 2 ядрами ? Нахрена ? Если приспичило, 2 слабых проца поставь,1 крутит вычисления, другой связью занимается и рулит. Откуда такие фантазии про 2 ядра, всем 1 проца хватает на все. Еще раз. Уарт хорош при надежной связи, но если ее нет, надо процем по аналог входу вытягивать сигнал и регулировать усиление, также он нужен для формирования помехоустойчивых сигналов, чтобы не было 000111 например. Коды Хэмминга для одной ошибки, я про много ошибок говорил. Никого ты не учишь, я посмотрел несколько видео, это жуткая дичь, неизвестно для кого
Спасибо Вам, целый курс по программированию микроконтроллеров. Прекрасно.
Заинтересовал. Спасибо. Отличное видео.
В процессе просмотра хотелось перебить: "Но ведь это ELRS и он уже есть!", но в комментах его уже обсудили. Тогда просто - спасибо.
Фундаментальный труд. Прослушал 2 раза. Спасибо.
С Новым годом! Спасибо за контент.
Здравствуйте.
Обратите пожалуйста внимание на протоколы:
1. CRSF (поверх UART) между пультом и приемником. Это сейчас самый распространенный протокол, который реализует, то что вы написали. Используется на FPV.
2. Протокол Mavlink. Он несколько сложнее, структуры данных в нем определяются разработчиком, а код для контроллеров (или ПК) можно создать кодогенератором по необходимой вам структуре.
3. Использование LoRa полностью поддерживаю. Обратите внимание на модули с выходной мощностью 5Вт. Этого может быть достаточно (с направленной антенной передатчика) для работы на десятки километров.
Здравствуйте,
по 1-2 - я недавно как раз ознакомился поверхностно с этими понятиями, с одной стороны было неловкое чувство досады, что я в очередной раз изобретал велосипед, с другой в целом удовлетворение, что все делал правильно, как и "профессионалы". В защиту проприетарных (или кустарных?) разработок скажу, что если задумываться в сторону безопасности - они могут быть надежнее, так как стандартные протоколы известны, можно пытаться перехватывать управление и т.д. А когда создается что-то кастомное, как перехватить управление? Нужно время, чтобы взломать "код". А если еще какой-то своей крипты докинуть простенькой, то и вообще задача будет непростая.
по 3 - посоветуете заводские модули такие глянуть? Меня вот в этой связи интересовали два вопроса:
- если взять железки типа под ELRS - они могут работать как удлинитель UART, передадут кастомный поток данных, подаваемый им на вход не в Mavlink или CRSF?
- видел что обычно под ELRS идут мощные передатчики, а на борт ставятся маломощные приемники, то есть поток данных односторонний подразумевается?
@well_techn
E22-230T37S 5Вт - также на AliExpress (ссылку не вставляю, RUclips это не нравится). В этом передатчике чрезвычайно актуальный сейчас частотный диапазон.
4. Типичное значение частоты отправки пакетов телеметрии 1:64 (или 128). То есть на 64 пакета управления от пульта отправляется один пакет телеметрии с дрона. Дело в том, что в ELRS приемниках стоит очень дохлый МК ESP8266, его лучше лишний раз не нагружать.
@well_techn
Нет, не передадут кастомные пакеты. Там очень ограниченный набор входных протоколов, определяемый в конфигураторе (приемника и передатчика): CSRF, SBUS, inverted SBUS, PPM - больше ничего. И в пакетах этих протоколов внутри просто значения 16 каналов и проверка целостности пакета.
@well_techn
Типичная мощность передатчика телеметрии внутри приемника ELRS (звучит странно, согласен) от 10, 50, 100мВт - зависит от серии и производителя. Больше, как правило, не нужно: у дрона в воздухе большое преимущество перед пультом в отношении условий радиовидимости (просто выше всех препятствий). Кроме этого значимость канала телеметрии сильно меньше, чем канала управления.
@well_techn
кроме этого передатчик ELRS подключается не по UART. Там S.PORT - однопроводный UART со смещенной нулевой линией сигналов. Понадобится физический конвертер сигналов S.port - UART.
Привет! Спасибо за видео!
Как понял, в проекте используется встроенный АЦП ESP (например, для оценки положения джойстика, также наверняка, для определения напряжения аккумкляторов). Читал много раз, что АЦП у данного МК является не очень точным. Соответственно вопрос: в ПО используются совсем-совсем сырые данные или предусмотренна какая-то калибровка?
пульт я писал не на ESP32, но в принципе с АЦП на ESP32 слегка работал, мерил напряжение батареи через делитель, пока не поставил под эти нужды отдельный чип. Негатива особо не было, была какая-то аддитивная погрешность, но не криминально. В целом если через АЦП на ESP32 джойстики считывать абсолютная точность тут не нужна великая, как по мне
Спасибо за видос, сам тоже собираю свое радиоуправление, сначала думал юзать модули HC-12, но они маломощные, для тестирования в комнате или в пределах видимости неплохо, потом тоже прикупил ЛОРУ, вот они уже намного лучше. Так же решил свой протокол сделать, тоже делал пакет и контрольные суммы. Только вот с обратной связью у меня не задалось, она все тормозила сильно. Вообще пока не до конца понимаю концепцию выполнения задач на FreeRTOS - не могу понять как и в какие тайминги будет выполняться та или иная задача. Допустим у меня есть три основных задачи - стабилизация дрона (опрос датчиков + ПИД), Прием данных от пульта, Отправка обратной связи - на какие ядра и с каким приоритетом мне их раскидать? Я всегда делал всем приоритет наивысший. Так же с приоритетами не совсем понятно (я понимаю что там есть планировщик) - как приоритет влияет на задачи? Кто-то мне сказал что задача с наименее низким приоритетом никогда не запустится...
задача во FreeRTOS - это функция, содержащая в себе бесконечный цикл. Диспетчер задач внутри FreeRTOS каждые сколько-то миллисекунд (по умолчанию 10) отдает на выполнение то одну задачу, то другую + некая логика по приоритетам, что делать если одна задача важнее другой. Если интересно разобраться - настоятельно рекомендую официальный сайт, там в целом все адекватно расписано. Я вот в этом видео очень кратно зачем нужен FreeRTOS касался ruclips.net/video/dc7WpKdmI9w/видео.htmlsi=LmlcI6dPN3BfkBQ1
по приоритетам - во FreeRTOS при дефолтных настройках используется вытесняющая логика, то есть:
- если две задачи имеют равные приоритеты, они запускаются планировщиком по очереди, сменяя друг друга каждый тик
- если при выполнении задачи с меньшим приоритетом возникает задача более высокого приоритета - проц мгновенно переключается на выполнение более приоритетной задачи, не дожадаясь конца тика
- когда задача наивысшего приоритета выполнится, операционка посмотрит, какая из ожидающих выполнения задач имеет высший приоритет и возьмется за нее.
При моем подходе основная идея в том, что у меня задачи сидят в состоянии Blocked, пока не придут данные через очередь или tasknotify. Тогда просыпаются и в соответствие с приоритетом передаются на выполнение.
Поизучайте ссылку ниже, там это описано www.freertos.org/Documentation/02-Kernel/02-Kernel-features/01-Tasks-and-co-routines/04-Task-scheduling
По части разбросать по ядрам - ссылка на структурную схему как я делал в описании. Стабилизация (опрос датчиков + ПИД) в моем понимании важнейшая задача, в пределе если она застопорися дрон просто потеряет контроль, поэтому эта единственная задача на ядре, чтобы ее ничего не отвлекало.
Прием управляющих команд имеет высокий приоритет на другом ядре, так как опять же управляемость в приоритете, а вот телеметрия это вторично, может и подождать.
Это какой-то очередной клон Modbus, то же самое куча данных и CRC в конце ))
а собственно что еще надо ), любая передача данных к этому сводится, просто сверху можно еще докидать крипту, помехозащищенное кодирование и т.д. Есть специфические задачи, когда, например, целесообразно вынести передающую антенну пульта подальше от оператора, была мысль что в теории вместо UART между пультом и передающим модулем можно использовать RS485 и разнести передающий модуль и пульт управления на расстояние (в пределе 1200м по проводу, столько вроде 485 тянет со спецификации). Будет задержка какая-то наверное, но все же.
я бы значения с ацп пульта просто 8 битные брал и убрал стартовый и eol просто проверяя что в буфере 7 байт, потому что как я понял все равно прерывание будет от каждого принятого байта, а не от только от FF
это очень хороший вопрос! Действительно, на первый взгляд прерывание (событие) типа UART_DATA должно генериться каждый байт (что есть пустая дерготня процессора), но я проверял (ставил в case UART_DATA действие типа printf посмотреть как часто он происходит). Результат - событие UART_DATA не генерится каждый байт, а генерится изредка по непонятной мне логике. Искал на форумах внятные условия генерации события UART_DATA - не нашел, доразберусь как-нибудь.
А касаемо убрать "старт" и CRC - можно, так как целостность данных вроде как должен обеспечивать приемопередатчик, но по факту много раз наблюдал как часть пакета терялась, на приемную сторону приходили огрызки данных. Без доп. контроля целостности есть риск вкинуть на Throttle что-то нерелевантное, чего очень бы хотелось избежать. Контроля много не бывает )
Как запилить AES256 на esp32 по модулю на 433 мгц?
не очень понял вопрос. Если речь про встроенные возможности крипты на ESP32, пара библиотек под эти нужны в ESP-IDF есть, типа esp_tls.c.
Вот тут неплохой пример с чего можно начать medium.com/@bhautik.markeye/esp32-aes-encryption-using-esp-idf-for-a-string-of-any-length-85fc46ad0d73
@well_techn шифрование трафика.
@well_techn планируется ли введение протокола Cursor On Target (COT) в данный беспилотник?
"Какой-то добрый комментарий..."
Я не вижу принципиальной схемы, это бестолковый набор модулей. И структурную схему не все умеют читать, это чисто школьные приколюхи, там нет точных связей. И пдф надо вытягивать по вертикали, напрягаешь листать влево-вправо, потому что тебе так захотелось.
В остальном концепция такая. У дрона антенна узкополосная. У передатчика направленная, типа рамки или патч, это повышает дальность. Также понижение частоты увеличивает дальность. Телеметрию и канал связи лучше разносить на разные частоты, например дрон отключился, но по телеметрии видно, что дрон разворачивается домой или садится аварийно с указанием координат, чтобы потом не искать его на площади 10х10 км. Не надо применять миниатюрные модули приема, там нет фильтров и значит любые искры рядом, гасят связь.
Дрон должен принимать-передавать реальные цифры, не надо заставлять его пересчитывать, это время и пусть пересчет делает база. Не надо сажать все на прерывания, это гигантская ошибка.
Хорошо, когда уарт сам трудится, проц отдыхает, но тут проблема в помехозащищенности уарта и если хочется повысить ее, тогда сам проц должен принимать и отправлять биты, там можно порулить и вытянуть плохой сигнал. Наивные попытки попытки 2 раза отправлять сигнал, плохо работают, лучше подумать об избыточных битах и исправлять исходные биты.
В общем, все как обычно, ардуинщик заявил про революцию, собрал из модулей и написал код, хуже стандартного.
Начну с конца - не подскажете, где заявлено про революцию? Я, как мне кажется, не устаю повторять, что это, по сути, учебный проект, основная цель которого - дать начинающим в этой сфере понимание как можно строить подобные системы. Прежде чем собирать условный Boeing, надо понять как летает самолет братьев Райт, этот проект ближе ко второму. А разобравшись с ним, видя его недоработки - можно развиваться дальше. Данный проект это не конкуренция Пиксе, Арду и иже с ними, которые десятилетиями писались командами, поэтому, очевидно, "хуже" стандартного на Ваш взгляд.
В русскоязычном сегменте не много подобный проектов "для начинающих инженеров", и чем больше их будет - тем больше людей задумаются что можно делать что-то свое и расти профессионально, а не просто портировать Пиксу.
Теперь по конкретике:
- про антенны и частоты все примерно так и озвучивалось, противоречий не вижу
- про то, что лучше не обрабатывать на дроне, а передавать готовые данные - согласен, обдумывал это, решил что в данном случае не хочу передавать float'ы через канал, это бы увеличило длину пакета, который и так ходит на этом железе очень медленно, а мощи на ESP32 крутанусь пару операций хватает. Есть, конечно, варианты в любом случае, так что этот тезис поддерживаю
- про то, что темеметрию можно сажать на отдельный канал - да, безусловно в профессиональных разработках это, пожалуй, оправдано. Чем больше каналов - тем меньше вариантов их задавить одновременно, если Вы про это. Для подобной разработаки плодить кол-во каналов наверное избыточно, 1 канал на управление, второй на телеметрию, 3й, если вдруг - на RTK поправки, 4й на FPV... Я в принципе подумал, что по сути телеметрия сейчас вся кладется оверлеем на FPV, тогда от обратки под нее можно в принципе отказаться, и не придется использовать мощный передатчик на борту для ее отправки.
- про выбранные модули - да, любительский вариант, для бытовых нужд хватает и не нарушает ГКРЧ. При такой концепции выбор других приемопередатчиков- это как смена физического уровня в OSI, не влияет на прикладной.
- про то что плохо использовать прерывания, " проц должен принимать и отправлять биты" и "вытянусь плохой сигнал"- Вы про коды Хэмминга и им подобные? Да, вариант правильный, но это опять же, как по мне, задача физического/канального уровня передачи, не прикладного. Выше мы согласились, что проц не надо нагружать лишней обработкой, эти функции хорошо бы на приемопередатчики возложить.
@@well_techn Читать не умеем.
Телеметрия нужна в первую очередь, чтобы найти упавший дрон. Значит, никогда его не искал. Управление надо связать с телеметрией, на пределе дрон не сможет принять данные управления по причине малой антенны, но вот база принять телеметрию может, потому что антенна хорошая, а дрон вернется сам и подхватит сигнал управления. Видео надо отдельным скоростным потоком передавать, обычно это вайфай и оверлей там для чисто для прикола. Зачем пихать это в один поток ? Тогда конечно 500м дальность, это потолок. Сам себе проблемы создаешь, еще и пихаешь мысль, что надо мощность повышать. Нахрена ? Для видео - да, для телеметрии - нет, там важнее правильный модуль с фильтрами.
Какие-то странные мысли про флоат, вычислил его и работай дальше с целочисленным, поменялось - флоат и опять работа с целым. Нахрена грузить бедный дрон астрономическими вычислениями с бесконечной точкой.
Я не совсем понял, 100 команд в секунду это мало ? У тебя скорость 38к-112к, это более 1000 команд. Зачем ? И для этого нужен м7 с 2 ядрами ? Нахрена ? Если приспичило, 2 слабых проца поставь,1 крутит вычисления, другой связью занимается и рулит. Откуда такие фантазии про 2 ядра, всем 1 проца хватает на все.
Еще раз. Уарт хорош при надежной связи, но если ее нет, надо процем по аналог входу вытягивать сигнал и регулировать усиление, также он нужен для формирования помехоустойчивых сигналов, чтобы не было 000111 например.
Коды Хэмминга для одной ошибки, я про много ошибок говорил.
Никого ты не учишь, я посмотрел несколько видео, это жуткая дичь, неизвестно для кого
Рахмет сізге!