ERLS_Rover — радиоуправляемый ровер на ESP32-C6 + ExpressLRS

Методическое пособие: ERLS_Rover на ESP32-C6 + ExpressLRS

Стенд: пульт RadioMaster Boxer (EdgeTX) → приёмник BetaFPV ELRS Nano RX → плата ESP32-C6 → драйвер моторов MX1508 + пан-тилт подвес камеры на серво SG90. Прошивка (Pipa_elrs/) вручную декодирует протокол CRSF, применяет танковый (skid-steer) миксер и реализует двухуровневый failsafe.

В отличие от проектов-датчиков, где данные идут “из железа в компьютер”, здесь цепочка длиннее и интереснее: радиокоманда оператора → RF-пакет → UART-байты → битовая распаковка → математика миксера → ШИМ на моторы. Каждое звено этой цепочки — отдельная тема школьной программы (информатика, физика, математика), и каждое можно “потрогать” на стенде.

Для уроков, где нет собранного ровера под рукой, к проекту приложен Python-стенд Pipa_elrs/crsf_visualizer.py — он повторяет декодер прошивки построчно и позволяет двигать виртуальные стики/тумблеры Boxer, наблюдая, как собирается и распаковывается настоящий CRSF-кадр и как поедет ровер.

Кто чем пользуется

1. Инженер отвечает за стенд: биндинг RX к пульту, раскладку каналов на Boxer (см. Pipa_elrs/include/boxer.md), питание моторов, дамп printChannelDump().
2. Учитель проводит эксперимент по сценарию ниже и обсуждает результат с классом.
3. Методист привязывает параметры протокола и кода к темам программы.

Модуль 0. Обязательный шаг: назначение и переназначение каналов на Boxer

Это не просто настройка — это центральный педагогический сюжет проекта. Пока ученик не проживёт связь «физический тумблер → номер канала → строка кода», всё остальное будет магией. Полная пошаговая инструкция — в Pipa_elrs/include/boxer.md; ниже — методический разбор того, ЗАЧЕМ каждый шаг и что ломается при ошибке.

Урок 0. «Кто здесь CH5?» — контракт между пультом и прошивкой

• Тема: интерфейсы и контракты между системами, отладка по наблюдаемым данным.
• Параметры: enum Channel в main.cpp, Channel Order (AETR) и Mixer на Boxer.

Идея. Прошивка жёстко ждёт: газ на CH3, руль на CH4, ARM-тумблер SA на CH5, крутилки подвеса S1/S2 на CH6/CH7, коробка передач SB на CH8. Boxer физически может положить любой орган управления на любой канал. Совпадение этих двух “мнений” — и есть контракт. Никакой провод его не гарантирует: его задаёт человек в меню пульта, а проверяет — дамп в консоли.

Ход работы (назначение каналов).

1. На Boxer: Model → Model Setup → Internal RF → CRSF, диапазон каналов 1–16.
2. Channel Order = AETR (Aileron, Elevator, Throttle, Rudder). Именно при AETR газ встаёт на 3, руль на 4 — как ждёт enum Channel.
3. Model → Mixer — назначаем AUX-каналы под тумблеры:
   • CH5 = SA (тумблер ARM), CH6 = S1, CH7 = S2 (крутилки подвеса), CH8 = SB (коробка). По умолчанию EdgeTX кладёт AUX подряд иначе — поэтому CH8 почти всегда нужно переназначить вручную.
4. Прошить ровер, открыть монитор порта (115200), включить Boxer, дождаться [CRSF] СВЯЗЬ ВОССТАНОВЛЕНА 🟢.

На графике (что видно в консоли):

 [CH-DUMP]  1:1500  2:1500  3:1000  4:1500  5:1000  6:1500  7:1500  8:1500 ...
                              ▲газ         ▲SA(ARM)              ▲SB(коробка)
 Двигаем SA вверх  → должен измениться именно индекс 5, а не 6 или 7.

Разбор. Дамп printChannelDump() — это «рентген» контракта. Двигаем один орган управления — смотрим, какой индекс в дампе шевельнулся. Если SA двигает CH6 вместо CH5 — контракт нарушен, и motors.setArmed() будет читать не тот тумблер: ровер либо не разблокируется никогда, либо (хуже) разблокируется от случайной крутилки.

Переназначение — два честных пути (и почему код трогать нельзя без причины). Когда дамп показал расхождение, есть ровно два решения:

• (рекомендуется) поправить Mixer/Channel Order на пульте — привести физику к тому, что ждёт код. Прошивка — «источник правды», её раскладку знают все три роли.
• либо переписать enum Channel под фактический порядок пульта и перепрошить. Это допустимо, но тогда меняется контракт для всех — и boxer.md, и симулятор, и документацию надо синхронизировать. Правило урока: сначала пульт, код — в крайнем случае, потому что настройку пульта видит и меняет оператор в поле, а прошивку — нет.

Практическое задание. Намеренно переназначьте на Boxer SB с CH8 на CH7 (конфликт с крутилкой Tilt). По дампу предскажите ДО включения моторов: что теперь будет управлять коробкой передач, а что — наклоном камеры? Проверьте по консоли. Верните раскладку обратно и объясните классу, почему такую ошибку невозможно поймать компилятором — она «легальна» и для пульта, и для кода по отдельности.

Модуль 1. Информатика: протокол CRSF как упаковка данных

Урок 1. 16 чисел в 22 байтах — зачем биты «размазаны»

• Тема: представление данных, двоичная система, битовые операции, экономия канала.
• Параметры: parseCrsfChannels() в CrsfParser.hpp, маска & 0x7FF, сдвиги.

Ход работы. Запустите crsf_visualizer.py (uv run crsf_visualizer.py). Верхняя панель — настоящий CRSF-кадр по байтам. Двигайте ползунок «Газ (CH3)» медленно и следите, какие байты кадра меняют цвет/значение.

На графике:

 Кадр:  [C8][LEN][16][ 22 байта каналов, склеены по 11 бит ][CRC]
                        ▲ газ (CH3) занимает КУСКИ трёх соседних байт,
                          а не один ровный байт — границы каналов не совпадают с
                          границами байт.

Разбор. Каждый канал — число 0..2047, ему хватает 11 бит. Байт — это 8 бит. 16 каналов × 11 бит = 176 бит = ровно 22 байта, без единого лишнего. Цена экономии: каналы не выровнены по байтам — CH3 «размазан» по payload[2..4] (2 бита из одного, 8 из другого, 1 из третьего). Чтобы собрать канал обратно, прошивка сдвигает и склеивает куски (|), а маской & 0x7FF (11 единиц в двоичной) отрезает лишнее. Приведение к uint32_t — не украшение: uint8_t << 10 потерял бы старшие биты. Тот же принцип плотной битовой упаковки — в форматах видео, сжатии и сетевых протоколах: место в канале дороже, чем удобство чтения.

Практическое задание. По формуле из кода _channels[2] = ((p[2]>>6)|(p[3]<<2)| (p[4]<<10)) & 0x7FF вручную (на бумаге, в двоичной системе) соберите значение CH3 из трёх байт p[2]=0xC0, p[3]=0xFF, p[4]=0x03. Сверьте с тем, что показывает симулятор, подобрав ползунок газа под то же значение.

Урок 2. CRC8: как приёмник ловит искажённый в проводе байт

• Тема: обнаружение ошибок, полиномиальные вычисления, надёжность передачи.
• Параметры: calculate_crc8() (полином 0xD5), проверка перед распаковкой.

Ход работы. В симуляторе доведите ползунки до осмысленного положения (ARM вверх, газ вперёд) — ровер «поедет». Теперь в учебной копии кода в функции decode_frame вставьте одну строку порчи байта (frame = bytearray(frame); frame[5]^=0xFF) перед разбором и перезапустите: статус кадра сменится на CRC FAIL, а ровер замрёт.

На графике:

 Целый кадр:     [C8][LEN][16][...данные...][CRC]  → CRC OK  → каналы обновились
 Битый байт:     [C8][LEN][16][..X.данные..][CRC]  → CRC FAIL → кадр ОТБРОШЕН целиком

Разбор. Провод от приёмника к ESP32 ловит электромагнитные наводки; искажённый байт газа мог бы швырнуть ровер вперёд. Пульт в конце кадра дописывает контрольную сумму CRC8 (полином 0xD5, стандарт Crossfire). Приёмник считает её заново по принятым байтам и сравнивает. Не сошлось — кадр в мусор, lastPacketTime не обновляется, ровер держит последнюю валидную команду (а при затянувшемся молчании сработает failsafe, см. Урок 6). CRC надёжнее простой XOR-чётности: ловит и пакетные искажения нескольких бит подряд. Тот же алгоритм — в Ethernet, USB, ZIP.

Практическое задание. В симуляторе есть готовая функция crc8_dvb_s2. Посчитайте CRC8 для двух байт [0x16, 0x00] вручную по алгоритму (сдвиг + XOR с 0xD5 при старшем бите), затем проверьте вызовом функции. Объясните, почему изменение любого одного бита во входных данных меняет итоговый CRC.

Модуль 2. Математика: танковый миксер и управление

Урок 3. Skid-steer: как две гусеницы дают поворот

• Тема: линейные комбинации, знак числа, ограничение области значений.
• Параметры: MotorDriver::drive() — left = thr + steer, right = thr - steer.

Ход работы. В симуляторе: ARM вверх, коробка «D», газ ~середина. Медленно двигайте ползунок «Руль (CH4)» от края до края и следите за стрелками на двух колёсах ровера (правая панель) — их длина = мощность борта, направление = знак.

На графике:

 Руль в центре        Руль вправо           Руль на месте (газ=0)
   ↑   ↑                ↑     ·               ↑     ↓
  L=180 R=180          L=230 R=130           L=+100 R=-100
  едем прямо           плавный поворот        разворот на месте (танк)

Разбор. Миксер — всего две строки: left = throttle + steering, right = throttle - steering. Прибавляя рулевую составляющую к одному борту и вычитая из другого, получаем разницу скоростей → поворот. При газе = 0 и ненулевом руле борта крутятся встречно — ровер разворачивается на месте вокруг оси (так ездят танки и экскаваторы). constrain(..., -255, 255) — страховка от выхода за пределы ШИМ. Это простейший, но реальный пример линейной комбинации двух управляющих сигналов — тот же приём в дифференциальных приводах роботов и стабилизации дронов.

Точка для углублённого занятия (нелинейность на краях). При газе 255 и руле 255 left = 510 → 255, right = 0 — поворот «съедает» газ, и на максимуме отклик стика теряет пропорциональность (ровер «ватный» в углах). Это отмечено и в разборе trouble.md. Предложите классу подумать: как масштабировать пару (throttle, steering) так, чтобы сумма не упиралась в потолок, сохраняя соотношение бортов?

Практическое задание. Для газа = 200 и руля = 120 посчитайте left и right на бумаге, затем воспроизведите положение ползунков в симуляторе (газ и руль в мкс) и сверьте числа L/R в подписи ровера.

Урок 4. «Попугаи» протокола и функция map()

• Тема: линейное отображение отрезков (интерполяция), единицы измерения.
• Параметры: map(172, 1811 → 1000, 2000) в CrsfParser, обратный us_to_crsf.

Ход работы. В симуляторе двигайте любой ползунок и следите за баром канала (мкс) и одновременно за HEX-значениями байтов кадра. Ползунок задан в мкс (1000..2000), а в кадре канал живёт в «попугаях» (172..1811).

Разбор. ExpressLRS/CRSF передаёт каналы в собственных единицах 172..1811, а весь код управления оперирует стандартными RC-микросекундами 1000..2000. map() — это линейное отображение одного отрезка на другой: y = y0 + (x - x0)·(y1-y0)/(x1-x0). Симулятор делает обратное отображение (us_to_crsf) при упаковке — поэтому цикл «мкс → попугаи → биты → попугаи → мкс» замкнут и не теряет значение (проверено: ошибка округления ≤ 1 мкс). Та же формула map() — везде, где датчик отдаёт «сырые» отсчёты, а логике нужны физические единицы.

Практическое задание. Выведите обратную формулу к map(x, 172,1811, 1000,2000) и посчитайте, какому значению «попугая» соответствует ровно центр стика 1500 мкс. Проверьте: этому ли HEX соответствует канал в кадре при ползунке на 1500.

Модуль 3. Физика и безопасность систем реального времени

Урок 5. Сквозной ток H-моста и «мёртвое время»

• Тема: транзисторный ключ, короткое замыкание, переходные процессы.
• Параметры: setMotorSpeed() — гашение обоих плеч + delayMicroseconds(2).

Ход работы. Разбор кода без запуска моторов (или на весу, колёса не касаются пола). Покажите в MotorDriver.hpp, что перед подачей ШИМ на любое плечо оба выхода принудительно ставятся в 0, и только затем — микропауза и новый ШИМ.

На графике:

 БЕЗ мёртвого времени              С мёртвым временем (как в коде)
  IN1 ▁▁▁▁████   ← оба плеча         IN1 ▁▁▁▁▁▁██
  IN2 ████▁▁▁▁      на миг открыты   IN2 ██▁▁▁▁▁▁
        ↑ сквозной ток!                   ↑ пауза 2мкс, ток не течёт насквозь

Разбор. MX1508 — это H-мост: два транзисторных плеча на мотор. Если при смене направления одно плечо ещё открыто, а второе уже открывается, ток идёт «насквозь» из плюса в минус мимо мотора — короткое замыкание, греющее и убивающее чип (shoot-through). Периферия ШИМ у ESP32 переключается асинхронно, поэтому в коде всегда сначала гасим оба выхода, ждём delayMicroseconds(2) (транзисторы успевают закрыться) и лишь потом подаём ШИМ. «Мёртвое время» — стандартный приём в силовой электронике: в промышленных инверторах и приводах его закладывают аппаратно.

Практическое задание. Объясните на схеме H-моста стрелками, по какому пути пойдёт сквозной ток, если оба верхних (или оба нижних) ключа откроются одновременно. Почему пауза именно ДО подачи ШИМ, а не после?

Урок 6. Два рубежа failsafe: ARM-тумблер и таймаут связи

• Тема: отказоустойчивость, состояние системы, таймеры реального времени.
• Параметры: ARM_THRESHOLD_US, setArmed(), таймаут 500 мс в CrsfParser::update().

Ход работы. В симуляторе: поставьте газ вперёд и коробку «D», но оставьте ARM внизу (CH5 < 1700) — ровер не поедет (корпус серый, стрелки колёс пустые). Поднимите SA вверх — корпус зеленеет, ровер едет. Это первый рубеж. Второй рубеж (таймаут) обсуждается по коду прошивки.

На графике:

 ARM выкл (SA вниз)        ARM вкл (SA вверх)        Потеря связи >500мс
  корпус серый              корпус зелёный            motors.stop()+ARM сброшен
  газ игнорируется          газ работает              gimbal.center()

Разбор. Первый рубеж — программный предохранитель: MotorDriver не пропускает газ, пока _armed == false, даже при полном стике. Оператор осознанно взводит SA вверх — машина не дёрнется от газа сразу после включения или восстановления связи. Второй рубеж — таймер: если валидные CRSF-кадры не приходят дольше 500 мс, парсер сбрасывает linkUp, а main.cpp в ветке else безусловно вызывает motors.stop() и gimbal.center(). Два независимых рубежа — принцип defense in depth: отказ одного механизма не оставляет систему без защиты. Важная деталь настройки (см. boxer.md): RX failsafe должен стоять в режим No Pulses, иначе приёмник продолжит слать «последние» каналы и таймаут никогда не сработает.

Практическое задание. Почему подвес камеры (GimbalDriver) управляется в обход ARM — крутится даже когда моторы заблокированы, но всё равно центрируется при потере связи? Обоснуйте с точки зрения «что опасно, а что нет» и сравните с логикой моторов.

Приложение: таблица переноса концепций в индустрию

Заключение

ERLS_Rover проводит один сигнал через всю пирамиду инженерных дисциплин: от битов протокола (информатика) через линейную алгебру миксера (математика) к транзисторным ключам и таймерам реального времени (физика и безопасность). Центральный методический сюжет — назначение каналов на пульте: это единственное место, где ученик руками задаёт «контракт» между двумя системами и сразу видит по дампу, работает он или нет. Python-стенд crsf_visualizer.py делает невидимую работу прошивки наблюдаемой, а разница между «ровер поехал» и «ровер поехал безопасно и предсказуемо» — как раз в тех местах (ARM, failsafe, мёртвое время), которые не видны, пока что-то однажды не пойдёт не так.

📊 Презентация проекта: ERLS_Rover на ESP32-C6 + ExpressLRS

Слайд 1: Один сигнал через три науки

• Суть: Радиоуправляемый ровер с подвесом камеры — команда с пульта проходит полную цепочку «RF-пакет → UART-байты → биты → математика → ШИМ на моторы».
• Платформа: ESP32-C6 + драйвер моторов MX1508 + пан-тилт подвес на серво SG90.
• Пульт и связь: RadioMaster Boxer (EdgeTX) → BetaFPV ELRS Nano RX → CRSF по UART на 420000 бод.
• Цель: Показать, как одна команда оператора становится движением колёс, и что за каждым звеном стоит отдельная тема программы.

Слайд 2: Контракт «тумблер → канал → строка кода»

• Проблема: Boxer может положить любой орган управления на любой канал; прошивка жёстко ждёт газ на CH3, руль на CH4, ARM (SA) на CH5, подвес S1/S2 на CH6/CH7, коробку (SB) на CH8.
• Назначение каналов: делается в меню пульта (Channel Order = AETR, страница Mixer) — никакой провод его не гарантирует, это задаёт человек.
• Проверка: дамп printChannelDump() в консоли — «рентген» контракта: двигаем один тумблер, смотрим, какой индекс шевельнулся.
• Переназначение: сначала правим пульт (источник правды — прошивка), код трогаем только в крайнем случае, синхронизируя всю документацию.

Слайд 3: Протокол CRSF как плотная упаковка данных

• 11 бит на канал: 16 каналов × 11 бит = 176 бит = ровно 22 байта, без лишнего — каналы «размазаны» по байтам, границы не совпадают.
• Распаковка: сдвиги | собирают куски канала, маска & 0x7FF отрезает лишнее, uint32_t спасает старшие биты от потери.
• Контроль целостности: CRC8 (полином 0xD5) — искажённый в проводе кадр отбрасывается целиком, а не «дёргает» ровер.
• Наглядно: crsf_visualizer.py строит настоящий кадр по байтам и распаковывает его тем же алгоритмом, что и прошивка.

Слайд 4: Математика движения — танковый миксер

• Две строки: left = throttle + steering, right = throttle - steering — разница скоростей бортов даёт поворот.
• Разворот на месте: газ = 0, руль ≠ 0 → борта крутятся встречно, ровер вращается вокруг оси (как танк/экскаватор).
• map() «попугаев»: каналы CRSF (172..1811) переводятся в RC-микросекунды (1000..2000) линейной интерполяцией — та же формула, что при калибровке датчиков.
• Честная граница: на максимуме газа+руля сумма упирается в потолок ШИМ, отклик теряет пропорциональность — повод обсудить нелинейное масштабирование.

Слайд 5: Безопасность — то, что не видно, пока не сломается

• Мёртвое время H-моста: перед сменой направления оба плеча гасятся + пауза 2 мкс — защита MX1508 от сквозного тока (короткого замыкания моста).
• ARM-предохранитель: газ заблокирован, пока SA не поднят вверх — ровер не дёрнется при включении или восстановлении связи.
• Failsafe по таймауту: нет валидных кадров > 500 мс → motors.stop() + подвес в центр. Требует режима RX «No Pulses» на пульте.
• Defense in depth: два независимых рубежа — отказ одного не оставляет систему без защиты; подвес камеры при этом работает в обход ARM (осмотр не опасен), но всё равно центрируется при потере связи.

🎮 Настройка RadioMaster Boxer + BetaFPV ELRS Nano RX под Pipa_elrs

Этот файл — пошаговая инструкция по настройке пульта RadioMaster Boxer (EdgeTX) и приёмника BetaFPV ELRS Nano RX, чтобы физическая раскладка стиков/тумблеров один-в-один совпадала с тем, что ожидает прошивка (enum Channel в src/main.cpp).

Если пропустить этот файл и просто забиндить пульт «по умолчанию» — код всё равно скомпилируется, но CH_ARM/CH_GEAR будут читать не те физические тумблеры, и ровер либо не поедет, либо поедет не от того переключателя. Используйте дамп printChannelDump() (см. src/main.cpp) на каждом шаге, чтобы проверять себя.

0. Что должно получиться в итоге (карта каналов прошивки)

Каналы 9–16 зарезервированы под будущий функционал (свет, лебёдка, лимит скорости) — физически прилетают и парсятся (CrsfParser разбирает все 16), но прошивкой пока не используются.

Подвес камеры управляется классом GimbalDriver (include/GimbalDriver.hpp) независимо от ARM моторов — оператор может осматриваться, даже когда движение ровера заблокировано. При потере связи подвес центрируется (gimbal.center()), как и моторы останавливаются. Сервоприводы — стандартные аналоговые SG90 (PWM 50 Гц, 1000–2000 мкс). Под Dynamixel в будущем потребуется отдельный драйвер (TTL half-duplex протокол вместо PWM) с тем же интерфейсом begin/update/center.

1. Биндинг BetaFPV ELRS Nano RX к Boxer

1. На Boxer: Model → Internal RF → Bind (для встроенного ELRS-модуля) либо зайти в Lua-скрипт ELRS (SYS → Tools → ELRS) и выбрать [Bind].
2. Запитать BetaFPV Nano RX так, чтобы он вошёл в bind-режим:
   • если плата новая/распакована — она уже в bind-режиме при первом включении;
   • если уже была забиндена ранее — замкните bind-пин/кнопку при подаче питания (см. шёлкографию платы) либо отправьте bind-команду через Lua/USB-конфигуратор.
3. Дождитесь синей/зелёной индикации непрерывного свечения на RX — это значит, что линк установлен и приёмник запомнил UID пульта.
4. Важно: ELRS привязывает UID пульта, а не конкретную модель — после бинда приёмник будет принимать сигнал от Boxer в любой модели, если не включена привязка по ModelMatch. Для одиночного ровера ModelMatch можно оставить выключенным, для нескольких моделей на одном RX — включить (Lua → ModelMatch).

2. Настройка модели на Boxer (EdgeTX)

1. Создайте новую модель: Model → Model Select → [+].
2. Model Setup:
   • Internal RF → режим CRSF (или ELRS, в зависимости от прошивки модуля).
   • Channel Range: 1–16 (полный CRSF-кадр, 16 каналов).
3. Lua → ELRS (или Model → Channel Order в новых версиях EdgeTX):
   • Channel Order: AETR (Aileron, Elevator, Throttle, Rudder) — это то, что ожидает прошивка (CH_THROTTLE = 3, CH_YAW = 4).
   • Если в вашей версии Lua-скрипта порядок задаётся иначе (например, TAER) — не меняйте код, а либо переключите Channel Order на AETR в Lua, либо скорректируйте enum Channel в main.cpp под фактический порядок и перепроверьте через дамп.
4. Mode пульта: Mode 2 (газ на левом стике, руль/Yaw на левом стике по горизонтали — стандарт для большинства пилотов и совпадает с комментариями в коде CH3 — Газ, CH4 — Руль).

3. Привязка тумблеров SA/SB к каналам 5 и 8 (Mixer page)

По умолчанию EdgeTX обычно кладёт AUX-каналы подряд: CH5 = SA, CH6 = SB, CH7 = SC… Прошивке же нужен SB именно на CH8, поэтому канал 6 нужно явно освободить под будущее расширение, а SB перенести на выход 8.

1. Откройте Model → Mixer.
2. Канал CH5: source = SA, weight 100% (это уже может стоять по умолчанию — просто проверьте).
3. Канал CH6: source = S1 (левая крутилка-потенциометр на Boxer), weight 100% — управление поворотом (Pan) подвеса камеры.
4. Канал CH7: source = S2 (правая крутилка-потенциометр на Boxer), weight 100% — управление наклоном (Tilt) подвеса камеры.
5. Канал CH8: source = SB, weight 100%. Если на CH8 уже что-то висит по умолчанию (часто там голос/потенциометр) — удалите старый микс на этом канале и поставьте SB.
6. Сохраните модель.

4. Настройка Failsafe на стороне пульта/приёмника

Прошивка ровера (CrsfParser::update()) уже реализует программный failsafe по таймеру 500 мс (теряется линк → motors.stop() + сброс ARM). Это основной рубеж защиты. Тем не менее рекомендуется не полагаться только на него:

1. В Lua ELRS на Boxer (или конфигураторе BetaFPV) выставьте режим RX failsafe: No Pulses (приёмник перестаёт слать кадры при потере линка) — именно это и ловит CrsfParser по таймауту 500 мс. Не используйте Last Position/ Custom, иначе RX будет продолжать слать «последние известные» каналы, и прошивка не поймёт, что линк пропал.
2. Убедитесь, что Packet Rate ELRS выставлен на разумное значение (50 Hz / 100 Hz / 150 Hz Full) — слишком низкий rate увеличивает задержку реакции и риск ложных срабатываний failsafe-таймера на 500 мс.

5. Проверка биндинга через консоль (обязательный шаг перед выездом)

1. Прошейте ровер и откройте монитор порта на 115200 бод.
2. Включите Boxer, дождитесь [CRSF] СВЯЗЬ ВОССТАНОВЛЕНА 🟢.
3. Смотрите строки [CH-DUMP] ... — они печатаются каждые 200 мс со значениями всех 16 каналов.
4. По очереди подвигайте: оба стика, тумблер SA, потенциометры S1/S2, тумблер SB. Убедитесь, что:
   • стик газа двигает значение в позиции 3;
   • стик руля двигает значение в позиции 4;
   • SA двигает значение в позиции 5 (выше 1700 = ARM);
   • S1 двигает значение в позиции 6 (Pan серво);
   • S2 двигает значение в позиции 7 (Tilt серво);
   • SB двигает значение в позиции 8 (D/N/R пороги 1300/1700).
5. Если какой-то тумблер двигает не тот индекс — вернитесь к Шагу 3 (Mixer page) и поправьте раскладку, а не код прошивки.
6. Только после того как пункт 4 подтверждён, переводите SA вверх (ARM) и проверяйте газ/руль на поднятом над землёй ровере (колёса не касаются пола).

6. Чек-лист перед каждым выездом

• RX BetaFPV Nano светит ровным цветом (линк есть, не мигает).
• [CH-DUMP] показывает все 16 каналов, не залипшие на 1500/1000.
• SA в положении “вниз” (ARM выключен) при включении.
• SB в положении “Neutral” (центр) перед первым ARM.
• Потенциометры S1/S2 в среднем положении — подвес смотрит вперёд/ровно.
• После ARM — короткий тест газа на весу, потом ставим на пол.

📡 Разбор файла радиоканала CrsfParser.hpp

Этот класс выполняет сложную задачу «приёма и декодирования» — он читает байтовый поток из UART-порта (провод от приёмника ExpressLRS), верифицирует каждый пакет через CRC8, побитово распаковывает 16 каналов и отдаёт в main.cpp уже готовые цифры стиков в диапазоне 1000–2000 мкс.

Важное уточнение для джуна: ESP32 не принимает радиосигнал напрямую — этим занимается отдельный приёмник (например, ELRS Nano). Он расшифровывает RF-пакет и отдаёт чистые данные по UART. ESP32 просто читает провод.

📦 1. Базовые переменные и Коробки под данные

enum CrsfState { WAIT_SYNC, WAIT_LEN, WAIT_DATA };CrsfState parserState = WAIT_SYNC;

• Что это: Состояния нашего «таможенного автомата» (State Machine). Плата не читает данные хаотично. Она всегда находится в одном из трех строгих режимов: ждет пароль начала, ждет длину посылки или сгружает коробки.

uint8_t crsfBuffer[64];int _channels[16];

• Что это: Память класса. crsfBuffer — временный мешок, куда сгружается текущий пакет. _channels — 16 ячеек постоянного хранения. Индекс 2 (CH3 Газ) изначально забивается в 1000 для безопасности, остальные рули встают в центр (1500).

⚙️ 2. Низкоуровневая математика (calculate_crc8 и parseCrsfChannels)## Шаг А. Защита от помех (Валидация CRC8)

uint8_t calculate_crc8(const uint8_t *ptr, uint8_t len) { … }

• В чем суть: Провода от приемника ловят дикие электромагнитные наводки. Если байт газа исказился в пути, машина может резко рвануть. Пульт Boxer в конце каждого пакета дописывает контрольную сумму (CRC8). Эта функция прогоняет пакет по полиномиальной формуле 0xD5 (стандарт Crossfire). Если расчетный байт сошелся с байтом пульта — пакет идеален. Если нет — он летит в помойку.

Шаг Б. Побитовая распаковка «чемодана» — 16 каналов полностью

_channels[2] = (((uint32_t)payload[2] >> 6) | ((uint32_t)payload[3] << 2) | ((uint32_t)payload[4] << 10)) & 0x7FF;

• В чём суть: В протоколе CRSF данные каналов не хранятся как отдельные байты. Чтобы уменьшить размер пакета и ускорить передачу, разработчики TBS упаковали каналы по 11 бит подряд — получается плотный битовый поток без разделителей. Канал 3 (газ) «размазан» по байтам payload[2], payload[3], payload[4] — 2 бита из одного, 8 из другого, 1 из третьего.

• Почему (uint32_t) — не украшение, а необходимость: uint8_t максимум 8 бит. Если сдвинуть байт влево на 10 позиций без расширения типа — биты просто выпадут за границу переменной. Принудительное расширение до 32 бит (uint32_t) даёт место для манёвра. После OR-а всех кусочков маска & 0x7FF (11 единиц в двоичной) срезает всё лишнее выше 11-го бита — получаем чистое значение канала.

• Полный охват Boxer (CH1–CH16): Протокол CRSF передаёт 16 каналов в 22 байтах (11 бит × 16 = 176 бит = 22 байта). Первые 8 каналов занимают байты payload[0..10], следующие 8 каналов — байты payload[11..21]. Паттерн битовых сдвигов для CH9–CH16 зеркально повторяет CH1–CH8, но со сдвигом на 11 байт в массиве. Если декодировать только первые 22 байта из 22 и не разбирать вторую половину — CH9–CH16 навсегда застрянут на дефолтном 1500, без единого сообщения об ошибке.

for (int i = 0; i < 16; i++) {
    _channels[i] = map(_channels[i], 172, 1811, 1000, 2000);
    _channels[i] = constrain(_channels[i], 1000, 2000);
}

• «Попугаи» протокола (диапазон 172..1811) переводятся в стандартные микросекунды радиоуправления (1000..2000 мкс). Цикл теперь покрывает все 16 каналов. Функция constrain — страховочный трос: если map() вдруг выдаст кривое число из-за граничного значения, constrain насильно зажмёт результат в безопасные рамки.

🔁 3. Асинхронный автомат контроля (update)

Эта функция бесконечно вызывается в главном цикле платы.

while (_serial->available() > 0) { uint8_t b = _serial->read();

• Плата выгребает байты из буфера порта по одному.

Робота автомата по шагам:

• case WAIT_SYNC: Ищем байт 0xC8 (пароль начала кадра CRSF). Всё остальное игнорируем. Нашли? Сбрасываем счетчик байт и переключаемся на ожидание длины.
• case WAIT_LEN: Читаем второй байт. Он указывает длину посылки. Если она в рамках адекватного (2..62 байта), запоминаем её и переходим к сбору данных.
• case WAIT_DATA: Складываем байты в буфер, пока счетчик bytesRead не доползет до длины посылки.

if (crsfBuffer[0] == 0x16) { if (calculate_crc8(crsfBuffer, payloadLen - 1) == … parseCrsfChannels(&crsfBuffer[1]);

• Как только пакет собран, проверяем: это пакет каналов управления (0x16)? Если да, проверяем CRC8. Если всё супер — отправляем данные на распаковку.
• Важная деталь: В функцию parseCrsfChannels передается адрес со сдвигом &crsfBuffer[1]. Мы отрезаем служебный байт типа пакета 0x16, чтобы математика сдвигов совпала с началом чистых битовых данных.
• После любого исхода (успех, левый тип пакета или битый CRC) — переменная bytesRead обнуляется, а автомат встает в режим WAIT_SYNC ловить следующий кадр.

🦺 4. Непрерывный контроль связи (Failsafe и выходы)

if (millis() - lastPacketTime > 500) {

• Если пакеты от Boxer успешно разбираются, переменная lastPacketTime постоянно обновляется текущим временем. Но если пульт выключили или оборвался провод, время пойдет вперед.
• Как только задержка превысит 500 миллисекунд (полсекунды), парсер бьет тревогу: сбрасывает флаг linkUp в false и принудительно забивает каналы безопасным аварийным мусором: газ в ноль (1000), рули в центр (1500).

int getChannel(int chIndex) { if (chIndex < 1 || chIndex > 16) return (chIndex == 3) ? 1000 : 1500; return _channels[chIndex - 1]; }

• Функция, через которую main.cpp забирает данные.
• Защита уровня PRO: Индексы в коде идут от 0 до 15, а человек просит каналы от 1 до 16. Функция сама вычитает единицу (chIndex - 1). А если программист случайно попросит несуществующий 44-й канал, плата не зависнет — условие перехватит ошибку и вернет безопасный нейтраль.

🛠 Как устроен твой MotorDriver ( MX1508 + ESP32-C6)

Представь, что этот класс — это водитель-механик внутри твоей машинки. Ему сверху (из главного файла main.cpp) кидают информацию о том, куда ты нажал стики на пульте Boxer, а он физически переключает передачи и жмет на педали.

📦 1. Принимаем инструменты (Конструктор и begin)

MotorDriver(int l1, int l2, int r3, int r4) : _l1(l1), _l2(l2), _r3(r3), _r4(r4) {}

• Что это: Робот-сборщик при создании класса спрашивает: “Слыш, к каким дыркам (пинам) на плате припаян драйвер MX1508?”. Ты передаешь ему пины 10, 11, 6, 7 (или любые другие), и класс запоминает их в свои внутренние переменные с нижним подчеркиванием (_l1, _l2…).

void begin() { ledcAttach(_l1, 15000, 8); …

• В чем тут фишка: Драйвер MX1508 не понимает просто команды “крутись”. Ему нужно слать ШИМ-сигнал (быстрое-быстрое мигание током, которое задает скорость).
• Команда ledcAttach — это фишка нового ядра ESP32 3.х. Она берет твой пин, настраивает на нем частоту 15 000 Гц (15 кГц) и разрешение 8 бит.
• Почему именно 15 кГц и 8 бит:
• При 15 кГц моторы крутятся абсолютно бесшумно. Частота настолько высокая, что человеческое ухо не слышит писка обмоток мотора.
  • 8 бит дают нам ровно 256 уровней скорости (от 0 — стоим, до 255 — тапка в пол).

🕹 2. Магия управления (drive)

Эта функция — мозг водителя. Сюда каждую миллисекунду прилетают три цифры от пульта: steering (руль Yaw), throttle (газ) и gearboxSwitch (тумблер SB).

Шаг А. Перевод «попугаев» в понятные цифры

int rawSpeed = map(throttle, 1000, 2000, 0, 255);if (rawSpeed < 15) rawSpeed = 0;

• Пульт шлет газ в микросекундах (от 1000 до 2000). Водитель через функцию map пересчитывает их в ШИМ-скорость (от 0 до 255).
• Строчка if (rawSpeed < 15) — это защита от дурака. Если ты едва тронул стик или он чуть дрожит в самом низу, скорость принудительно сбрасывается в 0, чтобы моторы зря не грелись и не пытались ехать от микро-касаний.

int cmdSteering = map(steering, 1000, 2000, -255, 255);if (abs(cmdSteering) < 15) cmdSteering = 0;

• Руль (Yaw) тоже переводится из 1000..2000 мкс, но в диапазон от -255 (поворот до упора влево) до +255 (до упора вправо). Центр стика становится идеальным нулем. Здесь тоже стоит «мертвая зона» в 15 единиц, чтобы машина ехала прямо, если ты отпустил стик.

Шаг Б. Коробка автомат (Тумблер SB)

if (gearboxSwitch < 1300) { finalThrottle = rawSpeed; // [D] - Движение вперед } else if (gearboxSwitch > 1700) { finalThrottle = -rawSpeed; // [R] - Задний ход } else { finalThrottle = 0; // [N] - Нейтраль }

• Водитель смотрит, куда ты щелкнул тумблер SB:
• Если он ВВЕРХ, то итоговый ход (finalThrottle) равен твоей скорости со знаком плюс.
  • Если он ВНИЗ, скорость превращается в минус (-rawSpeed).
  • Если он ПО ЦЕНТРУ, то ход принудительно обнуляется. Газ заблокирован!

Шаг В. Танковый микшер (Смешиваем газ и руль)

int leftPower = constrain(finalThrottle + cmdSteering, -255, 255);int rightPower = constrain(finalThrottle - cmdSteering, -255, 255);

Это самая главная математика, благодаря которой машина умеет поворачивать:

• Едем прямо [D]: Газ = 200, Руль = 0. Левый борт = 200 + 0 = 200. Правый борт = 200 - 0 = 200. Оба мотора крутятся вперед с одинаковой скоростью. Машина прет прямо.
• Поворачиваем на ходу вправо: Газ = 200, Руль = 50 (поворот вправо). Левый борт = 200 + 50 = 250 (ускоряется). Правый борт = 200 - 50 = 150 (замедляется). Машина плавно забирает направо.
• Танковый разворот на нейтрали [N]: Газ = 0, Руль = 100 (поворот вправо). Левый борт = 0 + 100 = 100 (крутится вперед). Правый борт = 0 - 100 = -100 (крутится назад). Машина бешено крутится на месте вокруг своей оси!
• Функция constrain следит, чтобы при сложении цифры случайно не вылетели за пределы разрешенных -255 и 255.

🔌 3. Педали в пол (setMotorSpeed)

После того как микшер посчитал финальную мощность для левого и правого борта (от -255 до 255), вызывается эта низкоуровневая функция. Она физически дергает пины, к которым подключен чип MX1508. У чипа MX1508 на каждый мотор идет по два провода (IN1 и IN2). Он устроен так: чтобы крутиться в одну сторону, нужно подать ШИМ на один провод, а второй прижать к земле (дать 0). Чтобы крутиться назад — наоборот.

if (speed > 0) { ledcWrite(pin1, speed); ledcWrite(pin2, 0); }

• Вперед: Если мощность со знаком плюс, мы пускаем ШИМ-сигнал на первый пин, а на втором пине жестко держим 0.

else if (speed < 0) { ledcWrite(pin1, 0); ledcWrite(pin2, abs(speed)); }

• Назад: Если мощность со знаком минус (задний ход), мы тушим первый пин в 0. А на второй пин подаем ШИМ-сигнал скорости. Функция abs(speed) берет модуль числа, превращая, например, -150 в обычные 150, чтобы контроллер ШИМ не сошел с ума от отрицательного значения.

else { ledcWrite(pin1, 0); ledcWrite(pin2, 0); }

• Стоп: Если скорость равна 0 (или сработал stop() при потере связи с пультом), водитель полностью обесточивает оба пина драйвера. Ток на моторы не идет, машина плавно останавливается.

🔍 4. Наблюдаемость (getLastMode и getLastSpeed)

int  getLastSpeed() { return _lastSpeed; }
char getLastMode()  { return _lastMode;  }

• Зачем это нужно: Класс хранит состояние машины внутри себя — это называется инкапсуляция. Вместо того чтобы внешний код (main.cpp) сам пересчитывал скорость по формулам MotorDriver, он просто спрашивает: «Что ты сейчас делаешь?»

• Почему это правильная архитектура: Представь, что ты завтра меняешь дедзону с 15 на 25. Если логика расчёта скорости дублируется в main.cpp — лог начнёт показывать неправильные цифры, и ты потратишь час на поиск бага. Когда есть один источник правды (сам MotorDriver), изменение в одном месте мгновенно отражается везде. Это принцип Single Source of Truth — один из базовых в проектировании систем.

• _lastSpeed содержит finalThrottle со знаком: положительное значение = вперёд, отрицательное = назад, 0 = нейтраль или стоп.

• _lastMode — символ 'D', 'N' или 'R'. Формат %c в Serial.printf позволяет вывести его напрямую без String-объектов, что быстрее и не фрагментирует кучу.

🕹 Разбор главного файла проекта main.cpp

Если класс моторов — это механик, а класс парсера — таможенник, то main.cpp — это генеральный директор (диспетчер). Он сам не крутит моторы и не разбирает байты. Его задача — запустить все системы, забрать данные у пульта и вовремя передать их моторам.

📌 1. Дефайны и создание объектов

#define ELRS_RX_PIN 5 #define ELRS_TX_PIN 4

#define MOT_L1 10 #define MOT_L2 11 #define MOT_R3 6 #define MOT_R4 7

• Что это: Таблица коммутации для всей платы. Мы жестко фиксируем, куда припаян радиоприемник ExpressLRS (5 и 4) и куда подключены четыре управляющих провода драйвера MX1508 (10, 11, 6, 7). Если завтра ты решишь переставить провода на бредборде — менять код не придется, достаточно перебить цифры здесь.

HardwareSerial elrsSerial(1); CrsfParser rx(&elrsSerial); MotorDriver motors(MOT_L1, MOT_L2, MOT_R3, MOT_R4);

• Что это: Рождение главных рабочих модулей.
• Создаем аппаратный порт elrsSerial (выбираем UART №1 внутри чипа ESP32-C6).
  • Создаем парсер rx и отдаем ему этот порт: “На, слушай ExpressLRS отсюда”.
  • Создаем драйвер motors и зашиваем в него наши пины бредборда.

🔧 2. Блок инициализации (setup)

void setup() { Serial.begin(115200); delay(2000);

rx.begin(ELRS_RX_PIN, ELRS_TX_PIN);
motors.begin();

}

• Что это: Команда «СТАРТ» при подаче питания.
• Запускаем USB-порт компьютера на скорости 115200 для вывода текста на экран (в монитор порта).
  • Делаем паузу 2 секунды, чтобы чип USB успел очухаться на ПК.
  • Даем команду rx.begin — парсер включает физический UART приемника на бешеной скорости протокола Crossfire (420 000 бод).
  • Даем команду motors.begin — драйвер настраивает ШИМ-генераторы (ledc) на частоту 15 кГц для бесшумного хода.

🔁 3. Вечный рабочий цикл (loop)

Функция крутится по кругу со скоростью процессора ESP32-C6. Весь loop разделен на три четких шага:

Шаг А. Постоянный фоновый сбор данных

rx.update();

• Эта строчка обязана вызываться на каждом круге без задержек. Она заглядывает в буфер UART. Если туда прилетел свежий кусок пакета от пульта Boxer, парсер забирает его, проверяет контрольную сумму (CRC8), распаковывает биты и обновляет базу данных каналов внутри себя.

Шаг Б. Главный диспетчерский пункт (Если связь есть)

if (rx.isConnected()) { int yaw = rx.getChannel(4); // CH4 - Повороты (Yaw) int thr = rx.getChannel(3); // CH3 - Скорость (Газ) int gearboxSw = rx.getChannel(8); // CH8 - Коробка автомат на SB

motors.drive(yaw, thr, gearboxSw);

• Диспетчер проверяет: “Пульт Boxer на связи?”. Если да (true), он вытаскивает из базы данных парсера три нужные цифры в микросекундах (1000..2000 мкс) — положение левого стика (вверх/вниз, влево/вправо) и положение тумблера SB.
• И сразу же, без тормозов, скидывает эти три цифры в класс моторов motors.drive(). Машинка мгновенно реагирует на пальцы.

Шаг В. Защитный сейв (Если связь пропала)

} else { motors.stop(); }

• Если ты выключил пульт, или отошел слишком далеко, или оторвался провод — парсер внутри себя взведет флаг аварии. Диспетчер тут же провалится в ветку else и даст команду motors.stop(). Аппаратный ШИМ полностью выключится, и машина не уедет в стену в неконтролируемом состоянии. Это Failsafe промышленного уровня.

📊 4. Умный фильтр логов (Вывод на экран)

bool channelsChanged = false;
if (abs(yaw - prevYaw) > DEADZONE) { channelsChanged = true; prevYaw = yaw; }
if (thr != prevThr)                { channelsChanged = true; prevThr = thr; }
if (abs(gearboxSw - prevSwitch) > 100) { channelsChanged = true; prevSwitch = gearboxSw; }

• Если выплёвывать текст в консоль на каждом круге loop, Serial станет узким местом и замедлит весь цикл. Поэтому диспетчер сравнивает текущие значения с предыдущими (prev...) и ставит флаг только при реальном изменении:
• Руль (Yaw) сдвинулся сильнее, чем на DEADZONE (7 единиц из диапазона 1000–2000)? Флаг!
  • Газ (thr) изменился хоть на 1 мкс? Флаг!
  • Тумблер коробки передач щёлкнул (скачок > 100)? Флаг!

if (channelsChanged) {
    Serial.printf("🎯 КЛАСС -> Режим: [%c] | Скорость: %d | Руль: %d\n",
                  motors.getLastMode(), motors.getLastSpeed(), yaw);
}

• Только если флаг взведён, диспетчер запрашивает у класса моторов геттеры getLastMode() и getLastSpeed(). Это единственный источник правды о состоянии машины — те самые значения, которые MotorDriver только что передал на железо.

• Почему не считаем скорость заново прямо здесь? Раньше так и было: main.cpp дублировал ту же математику с map() и условиями гитбокса. Это называется «расхождение источников правды» — при изменении дедзоны в MotorDriver лог начинал врать. Теперь лог всегда показывает то, что реально уехало на мосфеты.