А давайте обсудим Arducopter - APM
развод 😦 Pixhawk only
Ну так из ардуины выжали все, на что она способна. Имхо, разработчикам уже стоит выделять отдельную ветку для нормальных платформ и ветку для восьмибитного убожества.
Явно владелец Pixhawk 😃 Восьмибитное убожество летает (и имеет функционал) огого, может дать фору подавляющему большинству альтернативных решений
А в нормальном разработчики допилили Пиксфлоу? Лежит девайс, ждет. На ненормальном убожестве типа АРМ пытаюсь наладить оптический датчик от мыша. Вот где убожество!
Явно владелец Pixhawk 😃 Восьмибитное убожество летает (и имеет функционал) огого, может дать фору подавляющему большинству альтернативных решений
Вы забыли про баги, щедро разбросанные разработчиками по всему коду. Уже не один коптер улетел черт знает куда из-за того, что в восьмибитках закодить нормальные, сложные алгоритмы определения своей позиции невозможно.
У меня два apm 2.6, два cc3d и прототип своего контроллера на базе ARM Cortex-A8. Pixhawk в руках не держал, дороговато, а убойных преимуществ нет.
а зачем сложные алгоритмы определения позиции, этим пусть gps занимается, мы же не говорим о полетах внутри помещении? Как сказал выше Дмитрий “если при полете к точке, расстояние до нее не уменьшается, а увеличивается, отменять режим нафиг” простая арифметика, тут и счеты с костяшками подошли бы, 32 бит и даром не нужно. Количество багов зачастую растет с увеличением количества и сложности функций, а не наоборот
а зачем сложные алгоритмы определения позиции, этим пусть gps занимается
В условиях городской застройки, gps не очень хорошо справляется. Даже точность позиционирования в 0.3 - 0.5 м может привести к тому, что коптер при аварийной посадке сядет не на площадку, а на столб/куст/в яму.
если при полете к точке, расстояние до нее не уменьшается, а увеличивается, отменять режим нафиг
Это не серьезно. А если у нас неправильно определены текущие координаты?
32 бит и даром не нужно
Я вот тоже самое читал в одной советской книжке по проектированию микроЭВМ. Куда этот подход привел, думаю объяснять не надо.
Количество багов зачастую растет с увеличением количества и сложности функций, а не наоборот
Вот это как раз про APM.
А если серьезно подойти, то все существующие на рынке полетные контроллеры ущербны по сути своей. Один единственный вычислительный модуль занимается и декодированием команд от р/у, и снятием показаний с датчиков, и фильтрацией (по мере убогости cpu), и мат.вычислениями, и генерированием ppm/pwm сигнала для esc, и отправкой телеметрии… хорошо, хоть esc отдельные используются. Когда на одном кристалле выполняется столько разного кода, крайне трудно, т.е. практически невозможно избавиться от багов.
А по мне так можно было бы решить частично проблемы с малым объемом памяти, если не плодить множество режимов полета. Скажем, если нужно летать по точкам- сделать соответсвующую прошивку для таких полетов. Нужно только ручное управление - опять же - пересобрал прошивку и летай ручками. Зато, можно было бы освободить код именно под конкретные задачи и реализовать их как нибудь уж получше. И сделать конструктор прошивок прямо на сайте. Универсальность - это отлично, но тогда когда железо его тянет. На пиксхавке и оставить его! А для ардуинок - разделение по задачам.
А если серьезно подойти, то все существующие на рынке полетные контроллеры ущербны по сути своей. Один единственный вычислительный модуль занимается и декодированием команд от р/у, и снятием показаний с датчиков, и фильтрацией (по мере убогости cpu), и мат.вычислениями, и генерированием ppm/pwm сигнала для esc, и отправкой телеметрии… хорошо, хоть esc отдельные используются. Когда на одном кристалле выполняется столько разного кода, крайне трудно, т.е. практически невозможно избавиться от багов.
Так же поддерживаю! Вполне можно было чуть дороже сделать контроллер, но на двух нормальных процессорах. Разделить между ними задачи. Один бы пусть за навигацию и контроль полета отвечал. Другой - непосредственно занимался бы периферией и данными обмена с оператором.
На ненормальном убожестве типа АРМ пытаюсь наладить оптический датчик от мыша. Вот где убожество!
А с сонаром разобрались?
А если серьезно подойти, то все существующие на рынке полетные контроллеры ущербны по сути своей. Один единственный вычислительный модуль занимается и декодированием команд от р/у, и снятием показаний с датчиков, и фильтрацией (по мере убогости cpu), и мат.вычислениями, и генерированием ppm/pwm сигнала для esc, и отправкой телеметрии… хорошо, хоть esc отдельные используются. Когда на одном кристалле выполняется столько разного кода, крайне трудно, т.е. практически невозможно избавиться от багов.
Это прогресс каким бы он ущербным не был, увеличение степени интеграции приводит к такой необходимости. Если все размышляли бы так же как вы, то не появилось бы на свет многих вещей, ну например новшество в виде умных часов и т.п.
Но с другой стороны есть такой тип микросхем, как ПЛИС - в пределах одного кристалла можно делать все тоже самое и при этом все функции абсолютно независимые. Тут правда рядовой программист со знанием Сии не потянет))
Или же давайте строить нейронные сети! 😉
Еще лучше сделать разделение на три аппаратных блока: платформа стабилизации, навигационный модуль, коммутатор команд (свич). Платформа стабилизации занимается только управлением положения коптера в пространстве (из датчиков только IMU, барометр и может быть сонар или IR-дальномер). Любые высокоуровневые функции навигации (полет по точкам, удержание gps позиции, полетные скрипты) и специальные режимы полета выполняет отдельный модуль со своим контроллером. Навигационный блок подключается к платформе стабилизации через специальный свич, который пропускает через себя команды от навигационного блока и обычного ppm приемника р/у. При определенном сигнале от блока р/у, свич отсекает навигационный блок и пропускает только команды от р/у - режим ручного спасения в случае сбоя навигационного блока.
К навигационному блоку можно прикрутить и любые другие функции - достаточно гребенки GPIO-контактов и api для работы с ними, а юзеры уже разберутся.
Для хобби-контроллеров все это можно объединить на одной плате. Легко. И можно даже уложиться в стоимость оригинального APM.
P.S. Пока писал, аналогичную мысль уже высказали.
Наконец то кончилась безобразная погода и смог подлетнуть на улице на свежесобраном Y-6! Впечатления самые положительные. Отлетал 2200 акк, вышло 8 минут при разряде до 10.5 вольт. Моторы 2212 980кв х6 с ХК, регули Афро 30А прошитые последней прошивкой СаймонК. Пропы верхние 10х4.5, которые шли с моторами, нижние примерно 9х6. Обрезаные 10х6, поскольку штатной длины задевали за луч. Рама HLG Dragonfly Y3 Tricopter Y6 Hexacopter с Ебея. Очень устойчив. В паре сантиметров у земли никаких осцилляций. Резво набирает высоту и висит, как прибитый. Только сносит по ветру. Что самое приятное нет просадок и набора высоты при поворотах по Яву. Просто плавно поворачивает и замирает, стоит отпустить стик. Летал только в стабе, стемнело и пришлось возвращаться, не отлетав полностью аккум. Доволен до предела. АРМ 2.7 прошивка 3.2
Вы забыли про баги, щедро разбросанные разработчиками по всему коду. Уже не один коптер улетел черт знает куда из-за того, что в восьмибитках закодить нормальные, сложные алгоритмы определения своей позиции невозможно. У меня два apm 2.6, два cc3d и прототип своего контроллера на базе ARM Cortex-A8. Pixhawk в руках не держал, дороговато, а убойных преимуществ нет.
через мои руки прошла не одна сотня апм, лично я доверил бы аппарат от 100тр только АПМ с причем только прошивкой 3.1 ибо она летаная -перелетаная. Есть у меня и пиксавки и f4by но эти контроллеры еще надо “научиться готовить” и они еще должны заслужить доверие.
вот к примеру видео от активного разработчика и генерального тестера Марко
он считает что причиной этого креша стал код ланд - детектора (так сейчас написано в коменте к видео)
хотя в обсуждении до последнего писал что хз что произошло и лога не осталось
через мои руки прошла не одна сотня апм, лично я доверил бы аппарат от 100тр только АПМ с причем только прошивкой 3.1 ибо она летаная -перелетаная.
Вот тут я с Вами полностью согласен.
В условиях городской застройки, gps не очень хорошо справляется. Даже точность позиционирования в 0.3 - 0.5 м может привести к тому, что коптер при аварийной посадке сядет не на площадку, а на столб/куст/в яму.
Это не серьезно.
Вот это как раз про APM.
т.е. практически невозможно избавиться от багов.
Конструктивные предложения будут или пустые слова?
APM в целом не так плох. Здесь обсуждаем, а про другие контроллеры в другом месте…
Конструктивные предложения будут или пустые слова?
Прежде, чем требовать конструктивные предложения, научитесь не вырывать слова из контекста. А то ваш пост выглядит так, словно вам не понравилось моей сомнение в предложенном алгоритме. Но поскольку аргументов нет, осталось только потребовать некие абстрактные конструктивные предложения. Критикующий не обязан выдавать альтернативные предложения и методы решения проблемы.
через мои руки прошла не одна сотня апм, лично я доверил бы аппарат от 100тр только АПМ с причем только прошивкой 3.1 ибо она летаная -перелетаная. Есть у меня и пиксавки и f4by но эти контроллеры еще надо “научиться готовить” и они еще должны заслужить доверие.
Оригинальному APM или с вашими модификациями? Ограничения по версиям прошивок свидетельствуют не в пользу APM, они свидетельствуют о принципиально ущербном подходе разработчиков - стахановскими темпами добавлять новые фичи, а на исправления багов забивать.
Я изучал исходный код APM (делал модификации под свои нужды). В любой коммерческой софтверной компании за такое качество кода уволили бы давно. Конечно, это опенсорс, здесь никто никому ничего не должен, но совершенно не удивительно, что в таком месиве кода скрываются трудновоспроизводимые баги. И это одна из главных причин, по которой я ушел от APM.
стахановскими темпами добавлять новые фичи, а на исправления багов забивать.
Вот тут кстати да, этим они не радуют.
Раздумываю о покупке такого модуля, но смущает описание - стандартная скорость обмена 9600, что соответствует частоте обновления в 1гц, а также указано отсутствие eeprom на плате, что, по идее, делает невозможным заранее настроить модуль на нужную скорость обмена. Возможна ли организация начальной настройки модуля на нужную скорость самим контроллером?
хороша наза: фиг его знает какой там код, набор фич минимально необходимый, уже год и один месяц (!) не было ни одного релиза. Даже сколько там бит ни кто толком не знает 😃
уже год и один месяц
Только АПМу до их системы плуг энд плей как до луны. И летает она из коробки лучше чем апм. Толку от функционала когда там баг на баге?
Раздумываю о покупке такого модуля, но смущает описание - стандартная скорость обмена 9600, что соответствует частоте обновления в 1гц, а также указано отсутствие eeprom на плате, что, по идее, делает невозможным заранее настроить модуль на нужную скорость обмена. Возможна ли организация начальной настройки модуля на нужную скорость самим контроллером?
А в чем проблема? UBLOX-7M частота обновления до 10 герц. Написано default, вполне вероятно, что скорость можно повысить. Плохо, что EEPROM нет.
причем только прошивкой 3.1 ибо она летаная -перелетаная
А можно конкретную версию прошивки? (а лучше hex под квад)