Создание собственной системы стабилизации
Межпроцессорное общение естественно SPI(скажу по секрету один свободный выведен причём с nss - можно и управлять данным контроллером), но регуляторов много и все на spi не посадишь, а регуляторы с поддержкой can будут однозначно 😃
не надо CAN. зачем столько накладных расходов. вот мотивируйте во что вы сейчас уперлись, что надо в CAN лезть
Пока про поддержку CAN в софте речь не идёт, но не учесть его в в аппаратуре не дальновидно. Плюсы КАН очевидны ->
CAN хорош тем что это всего два провода(три вместе с землей), на которые можно посадить все исполнительные блоки, соотвественно количество проводов к регулям уменьшается. Плюс он очень надёжный и весьма помехозащищенный. Промышленный стандарт же. Минус, аппаратная поддержка далеко не везде и нужна внешняя микросхема - драйвер шины.
Это не минус, СТМ32 имеет весьма глубокую поддержку КАН, а драйвер 8ногая мелкосхема.
я конечно извиняюсь что влезаю, но уменьшение количества проводов и некая “помехозащищенность” выглядят неубедительно.
обычный ШИМ тоже идет по двум проводам, длина проводов в схеме “звезда” будет меньше, чем в “кольце” (если только не соединять ESC-и по периметру) и выдумать что-то еще помехозащищеннее ШИМ-а довольно трудно, знай себе время импульса измеряй. про совместимость можно и не говорить.
Например на гексе, отказ одного из моторов и перераспределение нагрузки на оставшиеся.
тоже надуманно. проблемы в регуле/моторе – заваливание аппарата – автоматическая коррекция, эта цепочка работает на всех алгоритмах удержания используя только датчики положения (гиры/аксели). нормальная система учитывает только конечный результат (положение аппарата) независимо от состояния исполнительных устройств.
Плюс он очень надёжный
при условии предварительной планировки “сети” и правильного арбитража. к тому же CAN - это протокол низкого уровня, а городить поверх него свой велосипед — это весьма полезно для мозга, но не для конечной реализации.
Имхо тупиковый путь “нестандартных” регулей, дорогих, редких и труднодоставаемых, был хорошо виден у немцев с их i2c 😃 Нет смысла сейчас делать опять что-то новое, когда обычные регуляторы по 10$, да и вроде качество полета сейчас упирается вовсе не в регули.
Я чёт не понял, спор из-за пяти баксов что-ли 😃 лапы эти всё равно ни для чего не используются и место для драйвера нашлось - ну пускай висит, есть особо много не просит, понадобится - будем использовать, а нет так нет 😃
я вот сегодня починил вход, задействовал 11 выходов (можно и 12 но пока пусть так 8-моторы 3-сервы) перевернул плату с головы на ноги, правда с компасом накосячил - исправлю, сейчас в планере балуюсь 😃
я конечно извиняюсь что влезаю, но уменьшение количества проводов и некая “помехозащищенность” выглядят неубедительно. обычный ШИМ тоже идет по двум проводам, длина проводов в схеме “звезда” будет меньше, чем в “кольце” (если только не соединять ESC-и по периметру) и выдумать что-то еще помехозащищеннее ШИМ-а довольно трудно, знай себе время импульса измеряй. про совместимость можно и не говорить.
По ШИМ вы сделаете обратную связь? ТО же самое и I2C, в принципе то протокол это позволяет, но все помнят немцев. CAN перспективный протокол и то что пока нет таких регулей, не значит что не надо закладывать возможность его использования. Да собственно, не обязательно регули, может это будет какой нибудь сенсор или ряд сенсоров (сонар, opticflow, LRF) да мало ли чего еще придумают.
Те же DIYDrones то же обратили внимание на эту шину и их новый контроллер (Pixhawk) ее имеет на борту.
Как хороший пример, vis.asta - у него если память не изменяет то же CAN регули, не думаю что просто так, “от балды”.
ну вроде датчики настроил, жалко дождь идёт fix-а нету даже на окне 😦 так-бы gps проверил…
Я чёт не понял, спор из-за пяти баксов что-ли лапы эти всё равно ни для чего не используются и место для драйвера нашлось - ну пускай висит, есть особо много не просит, понадобится - будем использовать, а нет так нет
Совершенно так.
Да собственно, не обязательно регули, может это будет какой нибудь сенсор или ряд сенсоров (сонар, opticflow, LRF) да мало ли чего еще придумают.
Вот именно! Это универсальный, надежный интерфейс, а главное на шине нет мастера. Чем это хорошо? Тем что у вас есть общая среда обмена информацией на борту! конечно для мультивия не актуально.
Пример:
У вас на борту несколько вычислителей: полётнег (стабилизация и удержание заданного положения) , быстрый и “тупой” видео вычислитель (видео одометрия, удержание в поле зрения заданного маркера и получение относительного вектора на маркер), контроллер подвеса (удержание заданного положения видеокамеры), “мега мозг” БОЛЬШОЙ вычислитель, универсальная машинка с универсальной осью, обеспечивает выполнение основного задания.
полетнег должен отправлять крен, тангаж, курс, вектор мгновенной скорости на всех, от основного мозга должен получать задание на направление и высоту, коррекцию скорости. Видео должно раздавать вектор скорости и вектор на маркер, управлять подвесом. Основной вычислитель должен отправлять задание на полетнег, получать от него состояние, получать данные с видео, работать с базой маркеров, передать маркеры на видео-вычислитель.
Т.е. нужно постоянно передвать массив переменых меж блоками.
Дык вот КАН в отличии от усарта и пр. делает это вполне удобно для программера, в виде почтового ящика. Флажек поднялся, заглянул в ящик, забрал значение. Для каждой переменной свой ящик можно выделить, для массивов настроить ПДП на ящик.
в банальном ффокусе 4ре CAN шины. и все на разных скоростях. одна на разъем диагностики выделенная. вторая на MCU и его датчики, третья на связь MCU-коробка-ABS. четвертая на магнитолу и окна-двери.
отчего бы в одну шину все не слить? там и коллизий ведь нету.
Сергей, can шина критична к длинне, скорей всего из-за этого?
нетолько к длине …
там несколько шин еще и для надежности …
бедет нехорошо если изза промокшего кабеля в двери отвалится нетолько магнитола но и коробка …
отдельная шина диагностики это вообще “защита от дурака” малоли кто что в этот разЪём сунет и как это повлияет на обмен по шине , а так моск может просто игнорировать этот канал …
Поизвращался с mtk 3329 - работает, правда кое как поймал 4-ре спутника - и носит по всей европе 😦
противоугонка - релюшка управляемая по радио коротит обе ноги CAN на массу. или притворяется датчиком положения коленвала. вроде завелся, но не едет.
для надежности раскидывают.
Вхожу в процесс. Веточку осилил.
Опыт, какой нибудь был, в этом направлении ?
Придётся свернуться ненадолго, дочку скорая забрала с острым ларингитом 😦
Придётся свернуться ненадолго
Дочке скорейшего выздоровления!
Опыт, какой нибудь был, в этом направлении ?
Опыт наблюдателя) Друзья занимаются вертолетами и самолетами. Решил начать с квадры.
дочку скорая забрала
Выздоравливайте!
Придётся свернуться ненадолго, дочку скорая забрала с острым ларингитом
Держитесь! В принципе ничего страшного, у нашей 3 раза было. И малому уже один раз вкатали преднизолон (правда был не ларингит).
Решил начать с квадры.
Для чего или зачем, как Вы думаете, применять здесь нечеткую логику??
Собрал сегодня проект Afroflight32 под STM32F103VE плату, адаптировал для разработки в EmBlocks. Работает с сенсорами GY-80 10DOF (L3G4200D, ADXL345, BMP085, HMC5883L) и комплектом из MPU6050, MS5611 и HMC5883L.
Поддерживается MultiWiiConf и MultiWii WinGUI для конфигурирования.
Буду дальше разбираться и дорабатывать код. в STM32F103 еще приличный запас по производительности и свободным ногам. Если не хватит, можно попробовать перенести на STM32F407.
в STM32F103 еще приличный запас по производительности
Для вийного кода СТМ32 имеет 1000%ный запас (а может и больше).