'У костра'

Давным-давно, еще во времена АрдуКоптера 3.0, кем-то был написан HAL для Ardupilot для платформы OpenPilot Revolution. К сожалению, этот код не поддерживался в течение многих лет и поэтому безнадежно устарел.

Некоторое время назад, я привел этот код к текущему состоянию Ardupilot и сделал PR на GitHub-е, дабы включить этот HAL в официальный репозиторий.

С тех пор прошло 2 версии ArduCopter-а, но это PR до сих пор висит.

UPD (20.02.2018) HAL в мастере! Однако еще есть причины пользоваться этим форком

По сравнению с исходным HAL:

Так что если кого-нибудь интересует ArduPlane / ArduCopter на контроллере  весом 5 грамм (с корпусом), а не только на огромном и тяжелом PixHawk - код и бинарники тут.  Описание подключения

Проверено, летает!

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

• USB порт может быть подсоединен к любому UART, например к ОСД для настройки.
• Любой УАРТ может быть подключен к ESC для их программирования
• SD карта может быть подключена к USB в режиме MassStorage - нет необходимости вынимать ее из корпуса для чтения логов

Вышеприведенные пункты позволяют разместить контроллер в корпусе и не разбирать его для настройки/чтения логов. А также:

• автодетект компасов и барометров на внешней шине I2C позволяет подключить любую платку сенсоров для Ардуины серии GY-
• автодетект протоколов SBUS/DSM/SUMD/PPM 
• есть FailSafe при зависании приемника, если ни один канал не меняется за 60 секунд - теперь это не вызовет улета
• возможность подключения 2х приемников - либо одновременно LRS и 2.4, либо как Diversity. Также это заметно увеличивает надежность
• используется система безопасности кварца - контроллер не зависает при его отказе
• возможен оверклок процессора - стабильно работает до 240 МГц!
• возможно практически произвольное использование свободных выводов
• возможно использование аналогового датчика воздушной скорости
• пищалка может быть назначена на любую ногу
• полная индикация состояния на 2х диодах: подсчет спутниковв GPS, режим Failsafe, калибровка компаса, режим Autotune и т. д.
• процессор ~65% времени проводит во сне - что значительно снизило потребление и нагрев

Вся коптерная электроника кучей - 15 грамм.

А вот вся электроника на коптере

Поблагодарить можно тут:
USD
EUR

 Или переводом - PayPal на vde@ykoctpa.ru, Qiwi 9173480717

UPD. Добавлена поддержка барометра на внешней I2C.  Теперь можно взять такой контроллер на Ф4 за 15 баксов, к нему такой  или такой модуль - и вот у нас полный контроллер для Ардупилота за $23 или даже $19

UPD2. Протестирована работа всей перефирии на SoftI2C и SoftSPI - теперь любые 2 ноги контроллера могут быть назначены как внешняя шина I2С, и любые 4 ноги - как внешняя шина SPI. Что, помимо наличия выведенной наружу SPI3, позволяет подключить произвольное оборудование в практически произвольном количестве.

UPD3. Добавлена возможность легко добавлять произвольные платы на похожих процессорах, отличающиеся только назначением выводов

ПРОШИВКА.

OPBL образы не поддерживаются, ибо бинарник должен жить на другом адресе, поэтому для перепрошивки нужно перевести проц в режим DFU - для этого замкнуть выыодв платы BOOT и включить USB. А затем выполнить команду

dfu-util -a 0 --dfuse-address 0x08000000 -D /path/to/firmware.bin 

где firmware.bin это прошивка для вашей платы.

На F4 , ведущих  родословную от OpenPilot Revoluton - то есть на ней самой,  RevoMini (на фото, самая перспективная), Airbot F4 (с внешней платой барометра и магнитометра, придется пересобирать). Ни на каких F3 работать не будет просто по определению - принципиально разное железо в камне.

Поддерживается все что поддерживает Ардупилот

UPD. Пересобиранть не придется, барометр на внешней шине I2C поддерживается "из коробки"

[2016-12-31 11:11:33] kozin писал(а): Есть ли планы присоединить и поддерживать проект в официальном репозитории арду?

Присоединить - да, делалось уже 3 ПР на гитхабе, результат в точности как у вас.

Поддерживать - нет, ибо в отличие от вас нет личной заинтересованности, и какая мне разница где поддерживать - свой форк или официальный?

[2017-01-01 07:47:14] kozin писал(а): я давно пытался убедить коллег в необходимости использования вывода  DRDY MPU6000тем более что аппаратно он у нас уже заведен

сейчас драйвер Invensense поддерживает использование вывода DRDY, достаточно определить "#define INVENSENSE_DRDY_PIN где_он_там"

[2017-01-01 07:47:14] kozin писал(а): если вам будет интересно поэкспериментировать я бы мог вам бесплатно выслать экземпляр актуальной версии нашего контроллера.

Спасибо за предложение, но я пока не вижу смысла. У вас ХАЛ для него давно отлажен и работает,  а камень у вас имеет 2МБ флеша и оттого не нуждается в "кроилове" и отказе от ОС на борту.

У меня же основная задача была - заставить Ардушный код работать на самом мелком (4 грамма без корпуса) и самом дешевом ($34 в розницу), но при этом полноценном F4 контроллере, который к тому же хорошо оттестирован на всяческих Бета/Клин/зеленыйсыр-флаях и зарекоменовал себя весьма надежным. 

спасибо, нашел

https://github.com/night-ghost/ardupilot/blob/master/libraries/AP_HAL/board/revomini.h#L26

Это не  я, я только ХАЛ пилю

[2017-01-02 06:58:56] kozin писал(а): по сути если использовать ваш хал для f4by нужно создать конфиг платы, выбрать проц и расставить датчики по пинам?

Именно. Свой файл платы (или #if) в AP_HAL/board и своя папка платы в AP_HAL_REVOMINI/wirish/boards с распиновкой камня. 

[2017-01-02 06:58:56] kozin писал(а): еоретически ваш хал может вернуть возможность вернуть проект в изначальное "арду" русло, когда широкий круг лиц мало мальски знакомых с С++ мог дополнить проект своим функционалом

Я как раз старался именно это и получить. Возврат к истокам, так сказать - ибо мне непонятно, зачем на борту нужен интерпретатор командной строки... 

Проект начинался с Ардуины - и самым логичным развитием был бы переход на платформу Ардуино32. Вот только ээээ... слегка извращенная структура контроллера PX4, на коий и был первый 32-бит порт, оставила свой отпечаток на всем проекте. Более поздние ХАЛ, например Линукс, уже гораздо проще идеологически. Да и практически все датчики для PX4 являются особым случаем - AP_InertialSensor_PX4 вместо AP_InertialSensor_Invensense, и так далее.

Единственное что пока есть один косяк - все работает при (не)оптимизации -O0,  а даже -Og ломает опрос MPU6000 Сейчас вроде выловил пострадавшие файлы, по мере свободного времени постараюсь поймать.

Ну таки обычно да, вот только в данном случае я ничего похожего не вижу. SPI вообще не использует прерываний, а вся обработка таймеров не использует переменных, общих с основным потоком.

6 файлов, требующих -O0 чтобы все работало, я сегодня выделил в TODO, но убей Бог лаптем не могу понять связь SPI и таймеров..

[2017-01-02 12:23:43] kozin писал(а): шедулер на прерываниях?

Естественно, прерывания от 7 таймера 8КГц, но все проходится по шагам и вроде правильно, в том числе и все интервалы - а из MPU читается мусор или нули.

[2017-01-02 15:03:15] kozin писал(а): то при частоте вызовов 1кгц я в консоли получаю 1-символьные значения крайне нестабильно, раз у несколько сек.

Там везде стоит проверка что вывод в консоль запрещен из таймерных функций, так что вывод получается ТОЛЬКО если по какой-то причине прерывание было отложено и затем вызвано из основного потока.

[2017-01-02 15:03:15] kozin писал(а): если функция не успела отработать за отведенный период ее прерывают и перезапускают

Это вопросы реализации конкретного шедулера, я так не делаю.

[2017-01-02 15:03:15] kozin писал(а): обственно кто таков этот функтор и в чем его специфика - для меня темный лес

Просто обертка для того чтобы можно было унифицированно вызвать метод любого класса без возни с оператором ->*

[2017-01-02 15:03:15] kozin писал(а): в доке другой пример

Дока ни о чем, если в двух словах то нужны 2 дополнительных потока - высокого приоритета и желательно реалтайм, и низкого приоритета. Звязываться с настоящей многозадачностью было лениво, поэтому реалтайм поток реализован как и в АПМ на таймере, а низкоприоритетный на простой кооперативной многозадачности во время исполнения разнообразных dalay()

[2017-01-02 15:03:15] kozin писал(а): тоже стало все рассыпаться именно тогда когда он повесил обновление на таймер

Но у меня-то при -O0 работает! Хотя явно выполняется дольше чем без оптимизации.

у меня кстати ряд варнингов показывает эклипс

втч https://github.com/night-ghost/ardupilot/blob/master/libraries/AP_InertialSensor/AP_InertialSensor_Invensense.cpp#L811

Description    Resource    Path    Location    Type
No break at the end of case    AP_InertialSensor_Invensense.cpp    /ardupilot/libraries/AP_InertialSensor    line 811    Code Analysis Problem

[pinmap] спасибо! классно!

если я не надоел еще тут своим "нудежом" то какие есть мысли по DRDY.

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

в ситуации когда используется drdy - идеально поставить легковесную функцию в аппаратное прерывание, для регистрации фронта импульса. Если же проверять пин DRDY циклически из таймера, то чтобы гарантировано попасть в момент близкий к фронту импульса состояние пина нужно проверять с частотой на порядок выше чем частота сигнала, т.е. при частоте измерения мпу 1кгц нужно опрашивать пин как минимум на 10 кгц. Причем в случае если фронт импульса зарегистрирован то важно не запускать повторные измерения пока пин в активном сотоянии, следует дождаться нового фронта. При этом можно установить таймер на паузу чуть меньше чем цикл измерения мпу, а затем проверять пин с высокой частотой.

если же пин готовности мпу проверять тупо с частотой измерений, т.е. 1кгц то проверка пина может придтись не на начало импульса а гдето к его концу и велика вероятность что чтение  регистров может совпасть с процессом их переустановки в результате измерения. зы. я не знаток мпу, чисто по аналогии с другими спи устройствами

Вдогонку про Пинмап. Есть еще таблица таймеров в pwm_in.c и еще одна таблица таймеров в timer.c. По уму их тоже надо бы в описатель платы засунуть, но вроде бы в пределах семейства они остаются неизменными

[2017-01-03 09:10:11] kozin писал(а): вроде как тут регистрируется

Это да, как я уже сказал я стараюсь по максимуму не трогать код ВНЕ ХАЛа. 

[2017-01-03 09:10:11] kozin писал(а): 1кгц

Кстати о получение данных с МПУ совмещено с их не самой легкой обработкой, так что иногда эта _poll_data выполняется аж 1286uS - так что килогерц это весьма оптимистично.

ради интереса посмотрел используют ли аппаратные прерывания в клинфлайте.

https://github.com/cleanflight/cleanflight/blob/master/src/main/drivers/accgyro_mpu.c#L216