Создание собственной системы стабилизации
Вот тут обсуждается протокол CAN для PX4 и для всех летающих девайсов: groups.google.com/forum/?fromgroups=#!topic/drones…
Разрабатывает его наш соотечественник (судя по ФИО). Думаю будет интересное чтиво в рамках F4BY.
Эпидемия!!! vr brain тоже под NuttX уходят, а платы у нас очень похожи порт станет ещё легче (кто не в курсе это тоже арду на F4)
Из сообщения Roberto Navoni
we are available to integrate it in Nuttx Enviroment and test on
VRBrain . It support the bus and we are working in progess also on
some device that support that bus.
What’s your idea about it ?
We are working to develop a hardware simulator of GPS using a VRBRain
4.5 without GPS interfaced with a VRBRain 4.5 with GPS and implement a
can connection … we are working on DJI can protocol … but we can
also evaluate to use Aerospace Can BUS.
Из сообщения Roberto Navoni
Кстати он тут про CAN говорит.
В последнее время, арду пробуют EKF, случайно нашел откуда ноги растут github.com/priseborough/InertialNav - там и MATLAB исходники есть…
I’m sure the docco is coming, but in the mean time have you seen the MATLAB/Simulink from which the C++ is generated?
В последнее время, арду пробуют EKF, случайно нашел откуда ноги растут
Снимаю шляпу перед программером! По размеру матрицы фильтра понятно, что учтены все возможные датчики, вплоть до воздушной скорости. Соответственно это позволяет получить все параметры полета от ИНС, а самой ИНС максимально точно отражать реальное состояние ЛА.
Кстати, код оформлен очень аккуратно, estimator.cpp и estimator.h очень легко вставить в свой проект. Нужно только определить вычислительную подъёмность алго.
Он прекрасен… rcopen.com/forum/f90/topic240405/104
Кстати он тут про CAN говорит.
не так это понятно но тестить то собираются под NuttX
В последнее время, арду пробуют EKF, случайно нашел откуда ноги растут github.com/priseborough/InertialNav - там и MATLAB исходники есть…
нам скоро ничего делать не придётся 😦
не так это понятно но тестить то собираются под NuttX
В этой фразе конечно не понятно, но он писал в теме про CAN, ссылку я давал раньше.
нам скоро ничего делать не придётся
Я думаю, что тут всегда будет чем заняться. Хотя мы конечно не сможем гонятся за арду, потому как у них достаточно большая команда работает, а не один-два человека.
У них очень много кода, который непонятно как работает. Он очень сложный и чем дальше, тем сложнее. Мне кажется, надо разделить на два контроллера - один отвечает за полет аппарата и его удержание, а второй уже полет по точкам, управление подвесом и т.п. Грубо говоря, один мозжечок и второй мозг.
Вот сделать первый, отладить его досконально, сделать настоящий автотюнинг (без необходимости делать какие либо специальные действия для этого) - вот это задача. Все кинулись в полеты по точкам и т.п. а про полтник позабыли.
Подвесом по моему вообще заморачиваться не стоит, ну разве что управлением самого контроллера подвеса…
Автотюнинга в любом случае нужен вкл./выкл. и как писал выше Александр, без всех датчиков, GPS в том числе, нормально инерциалку не построишь, да сам полёт по точкам и выполнение каких либо автомиссий можно отдать “супермосху”, но все данные он должен брать именно с мозжечка в том числе и GPS. Но “супермосх” также должен иметь собственную инерциалку, но уже не бесплатформенную, а гиростабилизированую (абстрагированую от кренов)…
НГ у китайцев закончится MAX-ов закажу. Да и ещё я так понял скоро появятся PX4ESC (по данным разведки F103) с CAN, так вот интересно как будут развиваться события, каждый регуль со своим адресом или всё-таки маршрутизатор?
У них очень много кода, который непонятно как работает. Он очень сложный и чем дальше, тем сложнее. Мне кажется, надо разделить на два контроллера - один отвечает за полет аппарата и его удержание, а второй уже полет по точкам, управление подвесом и т.п. Грубо говоря, один мозжечок и второй мозг.
А зачем на два проца делить? Один неплохо справится. Делить нужно код на задачи для ртос. Одна задача высчитывает положение, другая управляет моторами, третья вычисляет координаты, четвертая решает навигационную задачу и т.д.
Может успею быстрей сделать CAN регули)))
Может успею быстрей сделать CAN регули)))
а протокол, адресация?
вот кстати о чём писали github.com/pavel-kirienko/px4esc
В этой фразе конечно не понятно
we are available to integrate it in Nuttx
а протокол, адресация?
протокол пока сделаю свой, а дописать потом можно что угодно. Адрес будет у каждого esc свой.
Адрес будет у каждого esc свой.
перемычками (переключателями) или программно? лучше думаю механически, не каждый осилит программно перешить или же гуёвину по настройке тогда делать…
А зачем на два проца делить? Один неплохо справится. Делить нужно код на задачи для ртос. Одна задача высчитывает положение, другая управляет моторами, третья вычисляет координаты, четвертая решает навигационную задачу и т.д.
Это уже не принципиально, будет два приложения на одном камне или на двух.
перемычками (переключателями) или программно? лучше думаю механически, не каждый осилит программно перешить или же гуёвину по настройке тогда делать…
Что за каменный век? Подключив регуль к FC, должна быть возможность в GUI указать какой регуль, на каком луче стоит. FC автоматом пропишет адрес и направление вращения (если его будет возможно изменить). Т.е. было бы неплохо, если бы адрес выставлялся автоматом, ну типа DHCP протокола. Я в CAN мало что знаю, поэтому просьба не бить ногами за подкидывание идей )))
FC может запросить например 16 битные уникальные адреса (например ID МК) устройств на шине (регулей). После чего можно “сказать” регулю что бы он начал пикать для того что бы зафиксировать его нахождение (положение) на раме коптера. Так делаем со всеми найденными устройствами (регулями). Далее просто указываем в гуи какой адрес отвечает какому регулю (его положение на раме). Как то так.
Сам думаю пока как сделать, заложены и перемычки (маленькие правда 0402)) ) и возможность в GUI, гуи отдельно для регулей сделана, с протоколом осталось разобратся, по уарту можно будет все настроить и обновить прошивку, и соответственно это все можно будет сделать и по кану с полетного контроллера. С адресацией немного сложнее. На CAN шине не должно быть устройств с одинаковыми адресами, заранее нужно определятся с адресами, или либо по одному подключать и менять адреса. Можно задавать перемычками или в гуи через уарт, и потом указывать размещение “на луче” по адресу.
Как думаете лучше перемычками или по уарту из гуи адреса выставлять?
Что за каменный век? Подключив регуль к FC, должна быть возможность в GUI указать какой регуль, на каком луче стоит.
Тогда необходимо соблюдать уникальность прошитых номеров в регулях, либо
У них очень много кода, который непонятно как работает. Он очень сложный и чем дальше, тем сложнее.
За это я их и не люблю, посему пока летаю только на собственном.
Сегодня прикрутил СБУС к своему проекту, но это меня опечалило. Приёмыш фриски X8R выдает значения в каналах 172-1820, при этом на ШИМ каналах всё ровно 980-2010… Чего делать, хз… Код проверял, так что “не мои лыжи не едут”…
Сам думаю пока как сделать, заложены и перемычки (маленькие правда 0402)) ) и возможность в GUI, гуи отдельно для регулей сделана, с протоколом осталось разобратся, по уарту можно будет все настроить и обновить прошивку, и соответственно это все можно будет сделать и по кану с полетного контроллера. С адресацией немного сложнее. На CAN шине не должно быть устройств с одинаковыми адресами, заранее нужно определятся с адресами, или либо по одному подключать и менять адреса. Можно задавать перемычками или в гуи через уарт, и потом указывать размещение “на луче” по адресу. Как думаете лучше перемычками или по уарту из гуи адреса выставлять?
Значит, просто последовательно подключать регули (или другие девайсы, типа GPS, компаса, модема…) к полетному контроллеру (а он к компу) и менять адрес на уникальный в рамках коптера. А поставляться CAN устройства могут хоть с одним и тем же адресом.
фриски X8R выдает по sbus 11 бит (макс 2047) не в милисекундах, вот он и выдает весь диапозон от 0 до 2048, брать его диапазон и приводить к диапозону 1000 - 2000, только разрешение теряется
можно так по простому)) pwm = (sbus/2) + 1000;
Значит, просто последовательно подключать регули (или другие девайсы, типа GPS, компаса, модема…) к полетному контроллеру (а он к компу) и менять адрес на уникальный в рамках коптера. А поставляться CAN устройства могут хоть с одним и тем же адресом.
только нужно чтобы полетный контроллер мог сам определить адрес подключено устройства
фриски X8R выдает по sbus 11 бит (макс 2047) не в милисекундах, вот он и выдает весь диапозон от 0 до 2048
Да, похоже на то, а откуда такая инфа? Стандартный футбовский СБУС тоже так же работает?
диапазон и приводить к диапозону 1000 - 2000, только разрешение теряется
можно так по простому)) pwm = (sbus/2) + 1000;
По моим данным точно привести к 1000-2000 не получится, вот и выходит что при смене интерфейса приёмника придется настройки управления менять:(
только нужно чтобы полетный контроллер мог сам определить адрес подключено устройства
тут или перебирать адреса (сканировать шину) , но тогда изначально нужно будет подключать все устройства поодному находить и перепрограммировать адреса …
или перемычкой переводить устройство в “технологический режим” с фиксированым адресом , который больше не для чего не использовать (запретить назначать устройствам) и потом перепрограммировать адрес … в этом случае достаточно одной перемычки … если все устройства без запроса полетного контроллера не будут ничего передавать по шине то можно будет таким образом (с перемычкой) перепрограммировать адреса даже когда на шине будут сидеть несколько устройств с одинаковым адресом .