Интелектуальный , умный и независимый подвес камеры? Реально!
Для этого и нужна обратная связь софт то не знает, что смазка замерзла/разогрелась и появились пропуски шагов, софт не знает что появился какой-то люфт или другое смещение или на сколько износилась механика. да и кучу еще чего может случится на что сейчас просто фантазии не хватит. При этом конечно и без обратной связи будет работать но могут быть неожиданные сюрпризы.
Послушайте, Евгений, ведь подвес не разрабатывается на случай ядерной войны, чтобы учесть ну прямо все возможные катастрофы 😃 Люфт? Который появится лет этак через 100, учитывая размеры подшипников и просто смешную нагрузку? Пропуски шагов? У меня за все время тестирования шаги пропускались ну пару раз от силы. И я тут вместо энкодера сам: пропущенный шаг прекрасно виден на мониторе. Таскать энкодер для того, чтобы он мне сообщил о том что я вижу сам? Зачем? А если Вы имеете в виду, что энкодер сам вернет мотор на место, так толку-то с того, видео все равно испорчено. Нужно сделать, чтобы шаги не пропускались, вот и все; и ведь никаких сложностей с этим нет!
Я вот тут из опыта вспомнил - как раз по военной тематике)
Вот к примеру если солдата пытаться заставить одного на плацу шагать строевым шагом))))
А если приставить к нему, и он будет знать что получит … ТО результат превысит все ожидания!
И неважно будет болит ли нога, или не выспался и тд.
Это и есть пример глубокой ОС )
Сам был солдатом знаю)))
Вы не так меня поняли, я про то что лучше не пользовать степ дир, а взять 4 моста и атмегу - ну например 328, и обратную связь скажем в виде гироскопа! Просто обзаведясь обратной связью, не нужно предполагать, а вы точно знаете как движется мотор, пропустил, или нет.
Уже писал только что… Я не вижу смысла таскать вещь которая мне может сказать только то, что я и сам могу увидеть невооруженным взглядом. Если шаговик пропускает шаги, нужно настроить драйвер так, чтобы он НЕ пропускал шаги. И после такой настройки он их не будет пропускать, с вероятностью близкой к 100%. По крайней мере с вероятностью, позволяющей не забивать себе этим голову.
Брать в полет энкодер в таком раскладе – это все равно, что перманентно к коптеру прицепить автоматический дефектоскоп, с обратной связью, чтобы делал экстренную посадку – ведь есть же вероятность, что коптер в полете треснет? Так я вижу ситуацию…
Вы думаете безколекторник гладко крутится если его запитать синусом? Нет(по крайней мере хобийный), а вот обратная связь делает движение плавным и точным!
Я считаю, что шаговому мотору с большим количеством шагов энкодер не нужен. С БК я знаком гораздо меньше, и там, может быть, он нужен. Тут я спорить не могу.
“компенсировать механическое несовершенство” - можно без труда зная что с мотором происходит на выходе
Я уже говорил – не считаю, что шаговику нужно что-то там компенсировать. Он сделан с точностью более чем достаточной для применения в стабилизации, и это я уже могу, положа руку на сердце, подтвердить своим опытом.
Внимательно читаю ветки про подвесы, осознавая, что мне не светит создать и настроить что-то выдающееся. Но уже недели 2 в голове крутится одна мысль. Есть плата от сервы, которая выдает напряжение для колекторного двигателя (+ и -), есть вынесенный резистор для определения положения подвеса, берем регулятор от машины (что предлагал, кажеться, Александр Григорьев) с возможностью реверса и програмируем атмегу (или что-нибудь) что-бы выдавался импульс в зависимости от напряжения на выходе контролера сервы - 0В - 1500, -5В - 1200, +5В - 1800 (ну к примеру). И получаем управление подвесом бесколекторным двигателем.
Идея жизнеспособна?
“компенсировать механическое несовершенство” - можно без труда зная что с мотором происходит на выходе, незная этого Вы становитесь заложником множества условий -зачем?
Как раз наоборот, система может работать в “слепую” при железобетонном соблюдении ряда условий. Я просто исхожу из того что состояние мотора не равно состоянию подвеса.
Я пытаюсь следовать известному правилу: не умножать сущности сверх необходимости
Вообще главное, чтоб запала у Вас хватило, все только рады будут что Вы доведет подвес до ума. С энкдером он будет или без.
…програмируем атмегу…
Как бы не совсем это просто как кажется на первый взгляд
Для этого и нужна обратная
Этого никто не отвергал. Вопрос в том что все здесь нужно. Без обратной связи пока еще что вообще не что не работает, где ситуация развивается не по линейному закону. Но алгоритм, нюансы, и решение задачи в продуманности кода. Абратная связь - это лишь сигнал (ответ) алгоритму правильно ли он решает задачу.
А вот как это будет реализованно, во сколько деревянных это выльется скоро нарисуется конкретно. И стоять это решение на месте не будет 😉
С нуля пока что практически ничего не пишется (пока идет все по заготовкам и болванкам созданным ранее для других целей - как бы адаптация и аклиматизация)
Как бы не совсем это просто как кажется на первый взгляд
Всего лишь создать линейную зависимость частоты импульса от напряжения. А управляющий сигнал с мозгов коптера. Ну и настройка соответственно.
Андрей, здесь бы “Тима” подключить к решению задачи и не важно какой дорогой к цели…но он наверно почитывает;) хоть и идел у него за глаза
Програмист знакомый у меня есть, хоть и занятый сильно. Вопрос именно в том, что стоит ли овчинка выделки? Может кто-то пробовал и уже понял, что - “не той дорогой идете, товарищи…”.
Ведь серва тупо работает, за нее мозги коптера думают. Надо именно конечный сигнал отработать. Ограничить скорость двигателя, ну и еще что-нибудь добавить.
стоит ли овчинка выделки?
не стоит. Переделывать частенько сложнее и дороже, чем создать. Как минимум сейчас пять шесть практически независимых хобийных КБ заинтересованны , т.к. желают оказаться на первой волне реализации в массы бесколекторного подвеса.
Самый верхний гребень как бы скушал DJI в хобийном мире
Вечер добрый! А кто нибудь пробовал стабилизировать подвес камеры с помощью вертолетной системы стабилизации?
А кто нибудь пробовал стабилизировать подвес камеры с помощью…
Ага, у меня то-же есть мысль - попробовать Гуардиан на платформу подвеса поставить. Все равно от Иглов нужна будет только информация на экране.
У 3GX куча настроек, в принципе должно хорошо работать. И третья ось присутствует. Её можно настроить на сглаживания поворота или вращения коптера.
Есть еще круче системы стабилизации, микробист или в-бар. Ведь получается что подвес как тарелка автомата перекоса у вертолёта должна держать горизонт по двум осям.
И я тут вместо энкодера сам: пропущенный шаг прекрасно виден на мониторе. Таскать энкодер для того, чтобы он мне сообщил о том что я вижу сам? Зачем? А если Вы имеете в виду, что энкодер сам вернет мотор на место, так толку-то с того, видео все равно испорчено. Нужно сделать, чтобы шаги не пропускались, вот и все; и ведь никаких сложностей с этим нет!
Согласен с Евгением, енкодер только чтобы кнтролировал пропуски шагов, не нужен. Не должен шаговик пропускать шаги - иначе видео может быть испорчено в любой момент.
Насчет самодельного драйвера на полумостах - можно сделать, но не так просто даже догнать инженеров которые чип аллегро сделали. Почитайте датащит - там довольно много нюансов учтено. Простой полумост, хоть синусы аналоговые на него выдай, не выдаст линейного микрошага. А в промышленных контроллерах - там все конечно намного сложнее и куча патентов и денег они стоят немало. Там точность и отсутсвие вибраций очень важно. Дальнейшее развитие шагового привода вижу в повторении достигнутых там успехов, но на более дешевой элементной базе.
Вопрос программистам и математикам, с подковыркой: можно ли на основании только 6DOF-сенсора однозначно определить, горизонтален ли коптер в конкретный момент, или движется с ускорением и под наклоном? Вопрос не праздный…
3 гиры 3 акселя достаточно.строго говоря гира по z вообще может не учавствовать.
Т.е. Аксель по z .оговорился…
3 гиры 3 акселя достаточно.строго говоря гира по z вообще может не учавствовать.
Т.е. Аксель по z .оговорился…
Можете объяснить, как? Я сколько ни бьюсь, не выходит. Акселерометрам все равно, вызван ли вектор силы притяжением или ускорением. Насколько я помню школьный курс физики, согласно ОТО ускорение принципиально неотличимо от гравитации. На гироскопы можно полагаться относительно недолго, пока они не уплыли (ведь они потихоньку подстраиваются под аксели, а аксели-то у нас и врут!) Когда маневр ограничивается парой секунд, ошибка не успевает накопиться. Но попробуйте, скажем, на полной скорости заложить длинный вираж, длящийся секунд 20 – вот тут-то вранье акселей и вылезет во всей красе! Согласен, ситуация нетипичная, но она бывает.
Я в принципе придумал способ сильно снизить эту ошибку, но решение не полное, и к тому же слишком сложное математически. Некрасивое, другими словами. Думал как раз об использовании оси Z акселей – может известны более простые способы использования этой информации для коррекции на долго действующих ускорениях. Можно было бы решить проблему используя дополнительные сенсоры, но без нужды не хочется усложнять.
Согласен с Евгением, енкодер только чтобы кнтролировал пропуски шагов, не нужен. Не должен шаговик пропускать шаги - иначе видео может быть испорчено в любой момент.
Насчет самодельного драйвера на полумостах - можно сделать, но не так просто даже догнать инженеров которые чип аллегро сделали. Почитайте датащит - там довольно много нюансов учтено. Простой полумост, хоть синусы аналоговые на него выдай, не выдаст линейного микрошага. А в промышленных контроллерах - там все конечно намного сложнее и куча патентов и денег они стоят немало. Там точность и отсутсвие вибраций очень важно. Дальнейшее развитие шагового привода вижу в повторении достигнутых там успехов, но на более дешевой элементной базе.
Я еще раз повторюсь, что не советовал изобретать контролер шаговика, а предлагал управлять мотором как трехфазным на основе обратной связи!
По поводу горизонта акселей и гироскопов, есть несколько способов их практическое применение можно наглядно увидеть, в коде ардупилота, мультиви, и тд!
Если хотите понять как по трем осям понять куда наклон, почитайте здесь!
Не забудте, данные в радианах!
К сожалению все способы вычисления виртуального горизонта требуют коррекции гироскопов!
Так как дрейф приводит к значительной ошибке, для этого в основном используют данные акселерометров.
Что приводит всеравно к ошибке, но небольшой и динамичной, так как влияние линейных ускорений не избежать.
Я в принципе придумал способ сильно снизить эту ошибку, но решение не полное, и к тому же слишком сложное математически. Некрасивое, другими словами. Думал как раз об использовании оси Z акселей – может известны более простые способы использования этой информации для коррекции на долго действующих ускорениях. Можно было бы решить проблему используя дополнительные сенсоры, но без нужды не хочется усложнять.
Математически возможно, но на практике данные с обычных цифровых акселей очень шумные, аксель сложно откалибровать и сохранить калибровку с течением времени.
Если хотите понять как по трем осям понять куда наклон, почитайте здесь!
Спасибо, это я уже понял давно, но там вроде и об ускорениях-гравитации говорится. Постараюсь перечитать внимательно.
Математически возможно, но на практике данные с обычных цифровых акселей очень шумные, аксель сложно откалибровать и сохранить калибровку с течением времени.
Алексей, мы наверное о разном… или у нас разные акселерометры 😃 Я свои не калибровал (может только один раз за все время), только задал уровень точности, и они вроде бы никуда не уплывают, в отличие от гироскопов – хотя и шумят. Имел в виду, что они в принципе не понимают разницы между гравитацией и линейным/угловым ускорением.
ну , во первых, какова величина ускорения при вираже в 20 с !? разгон торможение , а сколько это в g =)?