Создание собственной системы стабилизации
Я был не понят. Седня покажу дринкеро-пелот
Проехали 😃
не могу мысли в кучу собрать 😦 впринципе есть алгоритм про который говорит rual, но по моему та же шляпа притянутая за уши…
не могу мысли в кучу собрать
А вот че, давай-ка покажи где схема валяецца, кварц какой, а я хекс пришлю, попробуем таксказать запустицца дринкеро-прошивкой. Прикольно?
Да, и вот если Ок, то скажи, все входы-выходы на таймерах сидят, или входы на прерывания расчитаны?
А то чета на фриртос мне не очень понравилось с прерываниями работать.
ну плата ещё ж не собрана -недели через две, а на чём сейчас страдаю тут но она у меня одна…
все входы/выходы (шим) на таймерах…
Вот тут обсуждается протокол 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 устройства могут хоть с одним и тем же адресом.