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