Противник PulseGuide

[mo]

Не нашёл тему "глупые концептуальные вопросы", решил создать новую 

Мы можем взять рукоглазый гид (окуляр с перекрестием и пульт) в руки и, заранее выбрав скорость гидирования, нажимать кнопки налево, направо, наверх (север), вниз (юг).

Есть возможность гидировать почти что любую приличную монти через "порт автогида", обычно с разъёмом RJ11 в распайке ST4.

Есть возможность гидировать многие ASCOM монти через PulseGuide. Что, по сути, тот же функционал, что и ST4. Что, по сути, то же самое, что и рукоглаз. Только комп занят нажиманием кнопок налево-направо-...

Я вижу одну и ту же проблему во всех трёх перечисленных способах гидирования. Это постоянная скорость коррекций. Допустим, 0.1 звёздной скорости. Или 0.25. Или 0.5. На кошмар-кошмар монти можно поставить 1х звёздную скорость.

Но какую бы скорость не поставили, у гид-софта нет возможности её изменить на лету. А порой следовало бы. Ситуаций таких может быть масса, вот несколько примеров:
- недостаточная скорость гидирования для компенсации лютого скачка (или быстрого набора) периодики по RA. Гид залипнет на 1..2 пикселя в стороне от 0 и будет пытаться выгнать её в ноль, пока не стихнет буря периодики;
- порыв ветра, уносящий гид-звезду на пяток пикселей и требующий моментальной реакции. Причём ветер стихнет и после этой самой реакции звезда окажется в противоположной стороне на почти те же пяток пикселей;
- люфт при смене направления. Гид-софт его знает (тому пример PHD), ну или предполагает с некоторой точностью (если учесть овальные колёса монти). Но с этим знанием он ничего не может сделать. В то же время достаточно на 5..10х обычной скорости гидирования гнать монти в реверс и, как только звезда сдвинулась, скорректировать данные по размеру люфта, учесть в следующей коррекции;
- быстрая коррекция после межкадровой подвижки для экономии ценнейшего съёмочного времени.

Я видел в максиме возможность гидировать через Move, а не PulseGuide, но она недоступна на моих EQMod монтировках. Да и не совсем это искомое.

Посему вопрос к общественности. Вдруг кто уже думал о том или знает того, кто в курсе. Или ... что-то по теме.

[Fantom]

Олег, мысль интересная и кмк в свое время именно эти размышления подвигли создателя Guidemaster-а сделать опцию "динамическая агрессивность". Немного другой путь, но смысл в том же, на малые ошибки - слабое воздействие, на большие - сильное. К сожалению в другом гидирующем ПО такого не встречал.

[Gennady Bankewich]

  Думаю надо не забывать что нагрузка монтировки, да и она сама, имеет конечную скорость реакции на импульс движения. По сути это интегратор в цепи регулирования камера-гид... привод монтировки.. масса монтировки и телескопа. Что-то сомневаюсь можно ли отслеживать колебания в несколько герц сетапа в несколько десятков кг. Впрочем это можно прикинуть.

[rctr]

  Могу вот поделиться взглядом неофита так сказать...
Немного заинтересовавшись а/фото и начав разбирться с тем как осуществляется
гидирование, удивился некотрому примитивизму сегодняшних решений гидирования.
  В общем то понятно что все это наследие еще со времен
линейных приводов и аналоговых схем управления и пожалуй на сегодняшний
день подобные решения несколько устарели. С другой сторны заглянув в нутро
монтировок "ведущих производителей" видишь там такую же устаревшую схемотехнику,
разработанную в лучшем случае в конце прошлого века. Этой самой схемотехнике
подобные решения как универсальные вполне соответствуют. Вместе с тем в
монтировках так скажем  условно начала среднего класса практически везде есть
либо ШД, либо прецизионные энкодеры, что вполне себе позволяет применить
альтернативные режимы гидирования - сдвиг на определенное число шагов по нужным
осям с максимальной скоростью (естественно с разгоном/торможением чтобы не
бороться с моментами инерций)
  Тут тоже видится 2 пути решения - либо создание встроенной  "умной" электронники
которая будет получать от софта гидирования вектор невязки, а дальше сама будет
решать когда куда и как быстро двигать.
  Второй путь -  в монтировке оставить только двигатели с продвинутыми
контролерами с развитой системой внешних команд, тогда софт "наверху" все решает
и отправляет команды на непосредственное исполнение монтировке.
   Второй путь несколько проще в реализации, но потенциально возникнут проблемы
совместимости в случаях разных монтировок.
  Короче резюмируя - электронника монтировок давно нуждается в обновлении, даже
наверное не только и не столько в части "железа" , сколько  в части софта. 
Но производители это дело ингорируют, а индивидульно этим можно заниматься только
пожалуй из "любви к искусству".

[mo]

Немного другой путь, но смысл в том же, на малые ошибки - слабое воздействие, на большие - сильное.

Это лишь одна из настроек ПИД регулятора. Кажись, ты говоришь об интегральной составляющей, но могу ошибаться. Несомненно, вещь полезная.

Что-то сомневаюсь можно ли отслеживать колебания в несколько герц сетапа в несколько десятков кг.

Я тоже в этом сомневаюсь. Но в этой теме не было ни слова про коррекцию с частотой в несколько герц. Те же самые неизменные 1 Гц или даже ниже. Но с динамической скоростью коррекции в случае внештатных ситуаций.

Иначе получается, что сидит охранник на посту, смотрит в квадратор видеокамер со скоростью 1 чай в час. Тут приходит грабитель и охранник встаёт, заправляет рубаху, моет кружку... с той же скоростью, потом достаёт дубинку и пытается догнать форсмажора.
Но в жизни ж так не бывает. Случается событие, происходит реакция на необходимой скорости.


Просто сейчас, если я не ошибаюсь, единственный путь приблизиться к быстрой реакции на событие - это выставить огромную скорость коррекции (к примеру, 1х) и да, некую динамическую агрессивность. Но, скорее всего, такая большая скорость коррекции внесёт свои резонансы и, как следствие, проблемы при отсутствии форсмажорных возмущений.

[mo]

Немного заинтересовавшись а/фото и начав разбирться с тем как осуществляется
гидирование, удивился некотрому примитивизму сегодняшних решений гидирования.

Моя мысль шла схоже.

В качестве отступления от темы...
Купив в 2009м году первую "серьёзную" монтировку SW HEQ5 pro я удивился, что современное устройство, опосредованно близкое к перспективной "космической" тематике не имеет USB на борту.

Так и в случае гидирования. Я вижу единственное объяснение, совпадающее с выдвинутой Вами мыслью об эволюционном росте и инерции отказа от старых технологий.

По сути, я предлагаю некую модификацию второго из предложенных Вами пути.
Мы железо и контроллеры монтировок оставляем как есть. Но добавляем возможность гид-софту регулировать скорость гидирования. Пока что можно говорить о самой распространённой системе лёгких (и часто кривых) монтировок, где предлагаемое новшество наиболее актуально - монти под управлением EQMod.

Обозначив такое сознательное ограничение класса монти, меж тем мы оставляем для участия в проекте все SW монти, некоторых "лебедей" с A&I контроллером, возможно какие-то ещё монтировки, поддерживаемые проектом EQMod.
На самом деле для парамона подобный апгрейд не нужен. Там и без него всё шоколадно . Там, насколько я увидел, гидирование идёт через Move и калибровка в максиме занимает 6 секунд по обоим осям.

Как я вижу, для реализации задуманного нам нужно:
1. понять, что изменение нужно;
2. модифицировать EQMod (проект с открытым кодом), создав интерфейс изменения скорости гидирования, если его там до сих пор нет. В идеале через расширение стандарта ASCOM, если мыслить вперёд;
3. дописать алгоритм гидирования в PHD (проект с открытым кодом), например. Он там в виде отдельного C++ файла небольшого размера.

И вот тут, лично у меня, возникает законный вопрос, озвученный выше под номером 1.

[mo]

Соберу в кучу аргументы "за" то что изменение нужно:

- у многих дешёвых EQMod монти нет прижима по DEC и адова пила заставляет сбивать полярку и включать гид по оси в одну сторону;
- опять таки, "дешёвый" вариант выезда в поля. Съёмка на ветру затруднена / невозможна при малой агрессивность / скорости гидирования;
- и вновь о дешёвых монти с высокой периодикой по RA. На малой агрессивности / скорости гидирование по этой оси порой вовсе не выводит звезду в 0 по десятку секунд.

[Gennady Bankewich]

  Опять же, не плохо было бы измерить постоянную времени переходного процесса реакции сетапа на единичный импульс управления. Не имеет значения шаговик там стоит или сервопривод. Типа заснять хоть на вебку трек звезды при отсутствии ведения но с подачей единичного импульса на привод, полярку развернуть на 90^о естественно.

[Ivan7enych]

По моему достаточно залезть в екумод и сделать все изменения в нем.
Разбить длительности импульсов на несколько диапазонов и в каждом работать на своей скорости, так чтобы результат движения был тот же, но длинные запросы отрабатывались на большей скорости и за короткое время.

[mo]

По моему достаточно залезть в екумод и сделать все изменения в нем.
Разбить длительности импульсов на несколько диапазонов и в каждом работать на своей скорости, так чтобы результат движения был тот же, но длинные запросы отрабатывались на большей скорости и за короткое время.

А ведь есть в этом решительный прорывный смысл.
Надо таки будет обдумать.

[rctr]

И вот тут, лично у меня, возникает законный вопрос, озвученный выше под номером 1.

Ну наверное если эта тема появилась, нужда есть и Вы видите в увеличении скорости гидирования возможность решить определенные проблемы,
 другое дело возможно ли решить проблемы таким путем, по хорошему нужно бы провести анализ логов гидирования  и прикинуть что реально можно
тут выиграть,  может статься что тут не самое узкое место.
а пункт 2 возможен если протокол управления SW монти имеет необходимый функционал, я так понял протокол там проприетарный и никто особо желанием раскрывать его не горит

[химик]

По моему достаточно залезть в екумод и сделать все изменения в нем.Разбить длительности импульсов на несколько диапазонов и в каждом работать на своей скорости, так чтобы результат движения был тот же, но длинные запросы отрабатывались на большей скорости и за короткое время.

Если есть функция "Обучение привода", то это должно быть одно и то же.

[Galaxy Master]

Странно, что перед желанием потратить N-ое время на нечто неведомое, ни у кого из участников не возникло желание количественно оценить профит.

PS. Про общее качество обстановки в которой надо компенсировать (и очевидно частые) рывки, я вообще молчу.

[mo]

Странно, что перед желанием потратить N-ое время на нечто неведомое, ни у кого из участников не возникло желание количественно оценить профит.

PS. Про общее качество обстановки в которой надо компенсировать (и очевидно частые) рывки, я вообще молчу.

Странно не это. А то, что ты не прочёл выделенное мною жирным. Вопрос номер раз как раз и звучит "понять нужно ли оно".

[Galaxy Master]

Странно не это. А то, что ты не прочёл выделенное мною жирным. Вопрос номер раз как раз и звучит "понять нужно ли оно".

Ошибка. Прочел как понять, что изменить нужно