Для кого?

Эта статья для энтузиастов, решивших прокачать свои навыки, и новичков, собирающих свой первый дальнолёт. В любом случае, статья предполагает, что читатель знаком с основами дроностроения, умеет паять, знает, что такое режим пит-стопа, Betaflight Configurator, умеет им пользоваться, а также знаком с CLI. Данное руководство можно использовать не только для ФПВ, т. к. настраивается сам приёмник, а передаваемые им данные может использовать любое подходящее устройство.

Зачем?

Даже самопальный дальнолёт-бомжелёт может влететь в копеечку и терять его жаль (особенно, если к нему прикручена какая-нибудь модная RunCam Thumb 2, на которую вы снимаете виды любимой деревеньки), а ещё больше жаль потраченных на сборку времени и сил. Поэтому сегодня почти все серийные long range оснащены недорогими (в масштабе общей стоимости) приёмниками ГНСС, позволяющими быстро и без особых усилий настроить возврат домой, чтобы при потере управления и/или картинки ваш дрон не упал в болото, а вернулся в точку запуска.

Проблема заключается в том, что на заводе приёмники прошиваются по принципу "чтобы работало везде, всегда и у всех" и по моему опыту не всегда они настроены оптимально. Простейший пример – протоколы передачи данных полётному контроллеру. Почти все современные производители используют чипы от швейцарской компании U-blox, поддерживающие два протокола:

• NMEA

• UBX

Первый является текстовым протоколом, изначально предназначенным для навигации на море. Второй разработан всё той же U-blox и имеет ряд преимуществ:

• протокол является двусторонним, т. е. с его помощью можно не только получать данные, но и настраивать сам приёмник

• целостность передаваемых данных защищена контрольной суммой

• данные передаются в двоичном, а не текстовом виде, поэтому сообщение равной длины содержит больше данных в сравнении с NMEA, а полоса пропускания используется более эффективно

По умолчанию приёмник настроен на работу с обоими протоколами, в то время как Betaflight одновременно использует только один из них: либо NMEA, либо UBX. Выходит, двойная нагрузка ложится и на приёмник, выдающий лишние пакеты, и на засоряемую ими полосу пропускания, и на получающий эти данные полётник.

Следствием этого (и не только) является длительное ожидание перед взлётом (на заводских настройках мне иногда приходилось ждать 5-10 минут до появления 6 спутников, что является необходимым минимумом для надёжного возврата домой. Если спутников в момент взлёта менее 6, то летать можно, но возврат работать не будет. Продолжительное ожидание, во-первых, бесит, а во-вторых, сажает батарею, сокращая время полёта. В борьбе за быстрый 3D Fix и минимально необходимые 6 спутников что я только не перепробовал: скручивание проводов в косички, их максимальное пространственное разнесение с линией питания и антеннами VTX и управления, экранирование с помощью заземлённой медной фольги, игры с настройками через CLI. Отдельные товарищи вообще советуют приседать и делать "ку" перед взлётом запитывать только приёмник (а другие товарищи на этом зарабатывают), чтобы не сажать батарею и дать время на разогрев без шумов от полётника и VTX. Правильная настройки делает всё это ненужным, а ожидание сокращается до 0,5-2 минут.

Матчасть

Начнём со списка необходимого для работы. Прежде всего потребуется сам приёмник, экспериментировать будем с распространёнными и массовыми моделями:

• HGLRC M80 (ГЛОНАСС + GPS) – приёмник т. н. 8-го поколения, т. е. собранный на основе чипа М8 от упомянутой выше U-blox

• HGLRC M100 Mini (ГЛОНАСС + GPS + Галилео + Бейдоу + QZSS) – приёмник 10-го поколения, т. е. на основе чипа М10 того же производителя

Поскольку другие производители (Beitan, JHEMCU, GEPRC, Foxeer и прочие) строят свои решения на основе тех же чипов, данные настройки можно использовать для большинства из них, главное уточните, что лежит в основе вашего приёмника (обычно указывается в описании). Также нам потребуются:

• ПК/ноутбук для установки ПО (u-center**)

• плата-переходник для подключения UART-периферии к ПК через USB

• соответственно, переходник MicroUSB/Type-C для подключения платы к компьютеру

Важно понимать, что даже самые правильные настройки не помогут в местах, где сигнал слабый (в глубине помещения, во дворе-колодце, под землёй и т. п.). Даже на чердаке стоящего на возвышенности частного дома сигнал может быть слабым, например, если кровля металлическая. Поэтому во время настройки стоит использовать приложение GPS Test, которое подскажет, сколько спутников мы можем поймать в данное время и в данном месте.

Несколько примеров

Также важно понимать, что в разное время и в разных местах количество "видимых" спутников плавает, следовательно и время захвата тоже может отличаться от случая к случаю. Приложение полезно в ситуации, когда спутники не ловятся/ловятся очень долго и необходимо понять: дело в обстановке здесь и сейчас или всё же в настройках/подключении.

В качестве платы-переходника использовалось готовое решение на основе TTL-USB преобразователя FT232RL FTDI:

Если у вас нет подобного преобразователя, то настройку можно выполнить и с помощью дрона. Для этого необходимо:

• правильно подпаять приёмник к полётнику

• подключить дрон к компьютеру (предварительно установив нужные драйверы)

• запитать дрон (для некоторых моделей питания от USB недостаточно)

• не забыть перевести VTX в режим пит-стопа во избежание перегрева и помех

• в Betaflight Configurator-e переключиться в режим CLI и прописать gpspassthrough, что перенаправит поток данных от приёмника к COM-порту через полётный контроллер

В общем, головной боли и приседаний много, а из плюсов лишь копеечная экономия, так что настраивать будем с помощью переходника.

Пайка

Тут всё просто: смотрим разводку приёмника и переходника и соединяем как обычно: питание к питанию, RX -> TX, TX -> RX:

Обратите внимание на отмеченный желтой рамкой переключатель выходного напряжения, позволяющий выбрать между 3,3 и 5 В. По умолчанию он находится в верхнем положении (5 В), но на всякий случай перепроверьте. Приёмник сможет работать и на 3 вольтах, но на 5 выйдет всяко шустрее.

В итоге получилось вот так:

Теперь подключаемся к компьютеру. Обратите внимание на зелёный светодиод: его моргание означает передачу данных.

Дальше нам потребуется приложение u-center, открыв его в первую очередь рассмотрим области, выделенные красным:

Вверху слева видим две выпадайки: первая отвечает за выбор порта (в моём случае это СОМ6), вторая – за так называемый baud rate. В данной статье я не буду углубляться в определения, будем считать это абстрактной скоростью передачи данных: более высокий уровень означает большую скорость. Если вы подключаетесь впервые и не знаете, какую скорость выбрать, то чуть правее есть иконка с волшебной палочкой – по нажатию приложение выставит уровень самостоятельно.

Когда подключение будет установлено, нажмите F6 (или View > Packet Console). Теперь нам доступен лог полученных сообщений:

Кнопка подключения вверху слева стала зелёной, в правом нижнем углу видим данные о подключенном устройстве (чип 10-го поколения подключен к порту СОМ6 со скоростью 57600). Также мы сразу поймали по одному спутнику ГЛОНАСС и GPS и можем оценить уровень сигнала с каждого из них. На содержимое лога пока не обращайте внимания, на данном этапе нам важен лишь тот факт, что в консоль с постоянной частотой выводятся некие строки, значит всё подключено правильно, приёмник работает, а приложение получает данные.

Настройка

Протокол

Как было сказано выше, Betaflight использует один из двух доступных протоколов и по умолчанию это UBX. Поэтому первое, что мы сделаем, – это очистим полосу пропускания от ненужных сообщений NMEA. Для этого переходим во View > Configuration View, в панели слева выбираем PRT (Ports) и теперь в выпадайках Protocol in/Protocol out оставляем только 0 - UBX для порта UART1. В конце отправляем настройки в память приемника нажатием на кнопку Send:

Многие даже очень качественные руководства по настройке ГНСС (например это) советуют сразу же увеличивать скорость передачи данных. Для HGLRC M100 Mini я оставил 57600, и даже в этом случае полоса пропускания используется на 10-15% (это можно проверить с помощью приложения u-center 2), а HGLRC M80 прекрасно работает даже на 9600. По умолчанию для М10 у вас скорее всего будет 38400 или 57600 и этого хватит с головой. Также имейте ввиду, что очень высокие значения вроде 115200 могут иметь побочку в виде потерянных пакетов, да и не все полётники их поддерживают.

Доступные ГНСС

Далее стоит разобраться с навигационными системами. Делается это с помощью пункта GNSS (GNSS Config). По умолчанию для приёмников на основе М10 у вас будет что-то вроде:

Важное уточнение: если мы хотим включить ГЛОНАСС, то необходимо сперва отключить диапазон В1 для Бэйдоу, в противном случае настройки не сохранятся. Я не знаю, почему не работает связка Бэйдоу-В1 + ГЛОНАСС-L1, если кто в курсе – поделитесь в комментариях. Чтобы заставить эти ГНСС работать вместе нужно Бэйдоу перевести на диапазон В1С, делается это с помощью View > Generation 9 Configuration View, используемый для настройки приёмников поколения 9 и старше:

Обязательно сохраните настройки в память приёмника (см. нижнюю панель)! Теперь он сможет работать со связкой ГЛОНАСС+GPS+Бэйдоу или ГЛОНАСС+GPS+Галилео.

С М80 всё проще: в моём случае он поддерживает только ГЛОНАСС и GPS, дополнительные настройки в этом пункте ему не нужны.

Питание

Теперь в панели слева выбираем PMS (Power Management Setup). Здесь вместо значения по умолчанию 1 - Balanced выставляем 0 - Full Power:

Это увеличит производительность ценой повышенного энергопотребления, но даже в пределе оно ничтожно в сравнении с потреблением двигателей и полётника. Также помним о том, что чем быстрее мы поймаем спутники, тем меньше заряда уйдёт на холостую работу контроллера и VTX, поэтому подобный размен выгоден в нашей ситуации.

Частота

Переходим к важному пункту RATE (Rates), отвечающему за частоту синхронизации. По умолчанию он обычно равен 1000 мс, т. е. приёмник отправляет данные полётному контроллеру 1 раз в секунду (1 Гц). Здесь выставляем 200 мс, увеличивая частоту синхронизации до 5 Гц, этого как правило хватает, но вы можете попробовать другие значение (2 Гц, 10 Гц и т. п.). Опять же, не забываем про кнопку Send внизу:

Обратите внимание, что с ростом частоты объём передаваемых данных тоже растёт, и вот здесь в некоторых случаях может потребоваться увеличение скорости (baud rate). Значение Navigation Rate менять не нужно!

Сообщения

И вот мы подошли к главному – к настройке сообщений, отдаваемых контроллеру. В панели слева выбираем MSG (Messages) и в выпадайке Message последовательно выбираем 01-35 NAV-SAT и 01-07 NAV-PVT и для каждого настраиваем так, как показано ниже (в конце обязательно нажимаем Send):

Здесь будет немного теории. Основными сообщениями, нужными для правильной работы UBX являются:

Betaflight в разделе документации Message types to enable советует включать NAV-PVT, NAV-DOP и NAV-SAT.

Почему же из 4 указанных сообщений включенными остались только 2? В поисках ответа заглянем в исходники Betaflight, а именно в gps.c:

typedef enum {
    //...
    MSG_NAV_POSLLH = 0x02,
    MSG_NAV_STATUS = 0x03,
    MSG_NAV_DOP = 0x04,
    MSG_NAV_SOL = 0x06,
    MSG_NAV_PVT = 0x07,
    MSG_NAV_VELNED = 0x12,
    MSG_NAV_SVINFO = 0x30,
    MSG_NAV_SAT = 0x35,
    //...
} ubxProtocolBytes_e;

На первый взгляд, имеет смысл включить всё, что перечислено среди обрабатываемых сообщений. Но при более внимательном прочтении выясняется, что сообщения NAV-PVT уже содержат всё необходимое, а остальное (кроме NAV-SAT) используется с устаревшими приёмниками:

// if NAV-PVT is enabled, we don't need the older nav messages
case UBLOX_MSG_SOL:
  if (gpsData.ubloxM9orAbove) {
    // SOL is deprecated above M8
    gpsData.state_position++;
  } else if (gpsData.ubloxM7orAbove) {
    // use NAV-PVT, so don't use NAV-SOL
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_SOL, 0);
  } else {
    // Only use NAV-SOL below M7
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_SOL, 1);
  }
break;
case UBLOX_MSG_POSLLH:
  if (gpsData.ubloxM7orAbove) {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_POSLLH, 0);
  } else {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_POSLLH, 1);
  }
break;
case UBLOX_MSG_STATUS:
  if (gpsData.ubloxM7orAbove) {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_STATUS, 0);
  } else {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_STATUS, 1);
  }
break;
case UBLOX_MSG_VELNED:
  if (gpsData.ubloxM7orAbove) {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_VELNED, 0);
  } else {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_VELNED, 1);
  }
break;
case UBLOX_MSG_DOP:
  // nav-pvt has what we need and is available M7 and above
  if (gpsData.ubloxM9orAbove) {
    ubloxSetMessageRateValSet(CFG_MSGOUT_UBX_NAV_DOP_UART1, 0);
  } else if (gpsData.ubloxM7orAbove) {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_DOP, 0);
  } else {
    ubloxSetMessageRate(CLASS_NAV, MSG_NAV_DOP, 1);
  }
break;

Сохранив настройки и открыв лог пакетов, увидим там примерно такой вывод (пустые строки вставлены мной для наглядности):

08:35:05  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:05  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:05  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:05  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:05  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:05  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:05  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:05  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:05  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:05  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'

08:35:06  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:06  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:06  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:06  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:06  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:06  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:06  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:06  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:06  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:06  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'

08:35:07  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:07  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:07  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:07  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:07  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:07  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:07  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:07  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'
08:35:07  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
08:35:07  R -> UBX NAV-SAT,  Size  64,  'Satellite Status and Information'

В течение 1 секунды получаем по 10 пакетов, т. к. включены 2 сообщения, а частота равна 5 Гц. Всё, настройка завершена, давайте теперь сохраним её в энергонезависимую память приёмника. Для этого переходим к пункту CFG (Configuration), выбираем Save current configuration и жмём Send:

Теперь можно отпаивать приёмник и подключать его к дрону.

Если после подключения мы перейдём в CLI и прописав gpspassthrough посмотрим вывод консоли пакетов, то обнаружим в логе небольшие изменения:

??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-SAT,  Size  16,  'Satellite Status and Information'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-SAT,  Size  16,  'Satellite Status and Information'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-PVT,  Size 100,  'Navigation PVT Solution'
??:??:??  R -> UBX NAV-SAT,  Size  16,  'Satellite Status and Information'

Если ранее соотношение между NAV-PVT и NAV-SAT было 1:1, то теперь оно равно примерно 1:5. Причина опять-таки в исходниках:

//...
case UBLOX_SAT_INFO:
  // enable by default, turned off when armed and receiving data to reduce in-flight traffic
  setSatInfoMessageRate(5);
  break;

//...

static void setSatInfoMessageRate(uint8_t divisor)
{
    // enable satInfoMessage at 1:5 of the nav rate if configurator is connected
    if (gpsData.ubloxM9orAbove) {
         ubloxSetMessageRateValSet(CFG_MSGOUT_UBX_NAV_SAT_UART1, divisor);
    } else if (gpsData.ubloxM8orAbove) {
        ubloxSetMessageRate(CLASS_NAV, MSG_NAV_SAT, divisor);
    } else {
        ubloxSetMessageRate(CLASS_NAV, MSG_NAV_SVINFO, divisor);
    }
}

//...
#ifdef USE_GPS_UBLOX
    // disable Sat Info requests on arming
    if (gpsConfig()->provider == GPS_UBLOX) {
        setSatInfoMessageRate(0);
    }
#endif
    GPS_calculateDistanceFlown(true); // Initialize
}

При включении и до взвода квадрокоптера для NAV-SAT выставляется уровень 5. Обратите внимание: в выражении rate 5 число 5 означает знаменатель, т. е. на NAV-SAT приходится 1/5 сообщений, отправляемых в цикле синхронизации. Кстати, упомянутый выше раздел документации Message types to enable советует устанавливать для NAV-SAT уровень 10, что явно не стыкуется с исходным кодом.

Получается, в данном случае действующие настройки определяются не только нами, но и прошивкой. Помните об этом, если настройка выполняется для другого устройства и по возможности сверяйтесь с исходниками/документацией.

На мой взгляд, решение выставить для NAV-SAT уровень 5 (равно как и их отключение после взведения) выглядит странно, ведь перед взлётом нам важно как можно быстрее получить данные обо всех доступных спутниках и обновлять их в полёте, ведь на высоте их будет больше. Подозреваю, что отключение NAV-SAT после взведения продиктовано стремлением облегчить жизнь слабым полётникам. В любом случае, для rate 5 я не заметил разницы в работе приёмников.

Как бы то ни было, об этой особенности Betaflight необходимо помнить.

Итоги

Давайте теперь посмотрим на плоды нашего труда. На видео показана работа чипа М10 с нашими настройками. Даже при холодном пуске мы получили 6 спутников и заветный 3D Fix за 31 секунду!

Для М8 время составляет 1-1,5 минуты.

Ну что же, статья подошла к концу, надеюсь, она была полезной для вас. Пишите свои замечания/дополнения в комментариях. До новых встреч!

* - передача координат в телеметрии поможет вам в том случае, если вы вдруг забудете вставить карту памяти в очки/шлем, забудете включить запись или запись окажется битой (да, и такое бывает даже с хорошими очками вроде Skyzone 02O и хорошими картами памяти вроде Canvas от Kingston). С другой стороны, нужно очень сильно постараться, чтобы запороть текстовые логи, которые пишутся в пульт, к тому же сигнал ELRS более устойчивый и его можно получить даже при отсутствии прямой видимости (в отличие от сигнала VTX). В случае же обрыва сигнал управления последнее значение телеметрии с координатами можно увидеть, нажав кнопку Tele вашего пульта ;)

** - на страничке загрузки сказано, что для работы с М10 необходим u-center 2, на самом деле обычный u-center тоже подходит, единственный нюанс связан с настройкой диапазонов для Бэйдоу (см. выше)