Создание собственной системы стабилизации
Подвесом по моему вообще заморачиваться не стоит, ну разве что управлением самого контроллера подвеса…
Автотюнинга в любом случае нужен вкл./выкл. и как писал выше Александр, без всех датчиков, 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 не получится, вот и выходит что при смене интерфейса приёмника придется настройки управления менять:(
только нужно чтобы полетный контроллер мог сам определить адрес подключено устройства
тут или перебирать адреса (сканировать шину) , но тогда изначально нужно будет подключать все устройства поодному находить и перепрограммировать адреса …
или перемычкой переводить устройство в “технологический режим” с фиксированым адресом , который больше не для чего не использовать (запретить назначать устройствам) и потом перепрограммировать адрес … в этом случае достаточно одной перемычки … если все устройства без запроса полетного контроллера не будут ничего передавать по шине то можно будет таким образом (с перемычкой) перепрограммировать адреса даже когда на шине будут сидеть несколько устройств с одинаковым адресом .
тут или перебирать адреса (сканировать шину) , но тогда изначально нужно будет подключать все устройства поодному находить и перепрограммировать адреса … или перемычкой переводить устройство в “технологический режим” с фиксированым адресом , который больше не для чего не использовать (запретить назначать устройствам) и потом перепрограммировать адрес … в этом случае достаточно одной перемычки … если все устройства без запроса полетного контроллера не будут ничего передавать по шине то можно будет таким образом (с перемычкой) перепрограммировать адреса даже когда на шине будут сидеть несколько устройств с одинаковым адресом .
Отличная идея, только тогда проще микрокнопку поставить, которая переведет устройство в режим программирования и сменит адрес на заданный.
Да, похоже на то, а откуда такая инфа? Стандартный футбовский СБУС тоже так же работает?
По моим данным точно привести к 1000-2000 не получится, вот и выходит что при смене интерфейса приёмника придется настройки управления менять:(
Насколько мне известно - да. Вообще говоря у всех топовых производителей система управления полностью цифровая - после того как стики оцифрованы, нигде обратного преобразования не происходит - Канал передачи по воздуху - цифровой, на выходе из приемника - цифровой SBUS или DBUS, который тот же UART только испорченный у футабы. Машинки топовые тоже принимают Sbus напрямую, внутри стоит контроллер. Только потециометры сервы могут быть аналоговыми.
Вот поэтому я и думаю на тему полностью цифрового управления, а не прошлого века с аналоговым по сути PPM и PWM. Благо для управления моторами есть полностью цифровые регули на I2C и CAN. Причем на CAN правильнее, имхо. Потому что I2C не является помехозащищенной шиной.
Так что привязываться к миллисекундам в корне неверно, на мой взгляд.
Правильнее по получении любого протокола приводить к шкале 1-1000 или 0-4095, например.
Отличная идея, только тогда проще микрокнопку поставить, которая переведет устройство в режим программирования и сменит адрес на заданный.
с кнопкой лучше чуть подругому … в ГУИ входим в режим программирования и оно просит нажать кнопку на нужном устройстве … контроллер начинает подавать запросы по зарезервированому для программирования адресу … при нажатии на кнопку устройство начинает слушать зарезервированый адрес и при получении запроса входит в технологический режим … если запроса нет - при отпускании кнопки продолжает работать в штатном режиме … будет защита от случайного нажатия …
равильнее по получении любого протокола приводить к шкале 1-1000 или 0-4095,
да, наверно так и буду делать.
с кнопкой лучше чуть подругому …
Да, так будет правильней. Особенность шины CAN в том, что там нет АДРЕСАТА ПОЛУЧАТЕЛЯ, но в каждом сообщении есть ИДЕНТИФИКАТОР ОТПРАВИТЕЛЯ, т.е. все приемники на шине слушаю всё что хотят, нужное оставляют себе. Типа сообщение, “МОСК-КУРС - значение” понимается приемниками как “курс по данным мозга равен значению”, кому надо его поймают и прочтут. У приёмников есть “почтовые ящики”, контроллер в эти ящики “подписывает” на приём сообщений с определенным идентификатором. После чего просто читает “последние новости” от подписанных идентификаторов.
Получается такой алгоритм: мозг вводится в режим назначения регулей и начинает рассылать по шине сообщение с определенным идентификатором и значением идентификатора для регуля. Регуль с нажатой кнопкой ловит сообщение и присваивает себе идентификатор, после чего отвечает мозгу с установленного идентификатора. Мозг завершает процедуру связки этого регуля.
Может кто подскажет. Заливал я прошивку в один из контроллеров на ATMEGA2560. Прошивка получилась больше по размеру чем доступная память в CPU. Так вот, при заливке прошивки (через ардуино иде), контроллер умер (ни на что не реагирует, лампочками не моргает и т.п.). Вчера попробовал подключить USBasp и прошить бутлоадер по новой - та же фигня. Бутлодырь записывается нормально в проц, фьюзы (FF, D8, FD) то же пишутся и читаются. Когда пытаюсь залить прошивку (из hex файла), она заливается но потом по первому же байту не проходит верификация и действительно, из проца читается какая то муть вместо прошивки. В свою очередь, бутлодырь хоть и записался в проц, но по прежнему не работает… Что это может быть?
Да, похоже на то, а откуда такая инфа? Стандартный футбовский СБУС тоже так же работает?
mbed.org/…/futaba-s-bus-controlled-by-mbed/
В свою очередь, бутлодырь хоть и записался в проц, но по прежнему не работает… Что это может быть?
перед прошивкой бутлоадера чип стираете? во фьюзах выставлена загрузка с области бутлоадера?
она заливается но потом по первому же байту не проходит верификация и действительно, из проца читается какая то муть вместо прошивки.
лок биты на всяк гляньте, а также фьюзы размера бутлоадера + заново его пролить