Вообще перестало работать редактирование сообщения. Такое уже было: горит зеленое "Загружается", и все. Пришлось дублировать текст целиком как новое собщение.
Попытаюсь по Витиной просьбе описать результаты поездки с моей точки зрения.
Прежде всего, разъяснить ситуацию со службой времени, в которую так много упирается. Краткий ответ на вопрос: работает или не работает? -
да, работает. На вопрос: решает задачу? не решает? - ответ:
нет, не решает. А именно, устройство должно обеспечивать: 1) выдачу триггерного импульса на все 4 камеры комплекса по запросу от компьютера и 2) обеспечение сетевого времени по NTP. П.2 для привязки времени экспозиции, строго говоря, не нужен, если реализован п.1 - если устройство обеспечивает программируемое управление экспозицией по своим часам и умеет выдавать метки времени в компьютер, компьютерные часы вообще могут идти как угодно, ошибки времени не будет. И, кстати, Олегово устройство это обеспечивает. Проблема же в том, что реализация п.1 для ЭОП-1 возможна либо как
одного 4-канального устройства, либо как
4 идентичных
одноканальных. А сейчас мы имеем
одно одноканальное. Т.о. п.1
не решен.
Чтобы все-таки обеспечить привязку времени, мы решили пустить PPS от устройства на все 4 камеры и работать по старой схеме привязки к ближайшей секунде. В этом смысле новое устройство ничем не лучше старого GPS - но хоть в таком, достаточно кривом виде возможность наблюдений оно может обеспечить - при условии, что на управляющих компьютерах есть достаточно точное системное время (по NTP). Для того, чтобы устройство работало как источник времени для NTP (п.2), в него надо либо встроить аппаратный NTP-сервер с выходом Ethernet, либо (что хуже) сделать аналогичный программный модуль и подключить устройство к какой-то отдельной машине, которая будет играть роль сервера более высокого уровня для ntpd. Есть еще третий вариант - сделать драйвер reference clock для ntpd под Олегово устройство; но это для него чересчур много чести
Вторую же возможность я в свое время предусмотрел в FORTE, но ни разу не было повода ее использовать, поэтому она была совершенно не отлажена, и я вообще не думал, что она когда-либо может пригодиться - потому что не софтовое это дело
А до приезда Олега Р. я был в полной уверенности, что, раз устройство пока одноканальное (об этом они договорились весной с Володей Я., иначе разработка затянулась бы еще дольше), оно будет в четырех экземплярах, будет вешаться на каждый телескоп (два - на спарку), управлять каждое своей камерой и выдавать мне время в FORTE для нужд наведения, чтобы не зависеть от системного времени и NTP. То, что оно одно (ну, два, но второе нужно самим разработчикам для отладки) и поэтому не решает задачи, выяснилось 21-го числа, когда Олег поднялся на гору. Вот такая веселая история.
Конечно, временный выход придумать было несложно. Я его уже описал: PPS от устройства один на все камеры, привязка к секунде по системному таймеру от NTP. Другой вопрос, что тогда городить такое устройство было, в общем-то, и не надо: тот же PPS можно получить хоть от старого GPS, хоть от имеющегося рубидия. А запустить софтовый NTP на нем мне так и не удалось - Олег приехал поздно, и мне, параллельно остальным задачам, не хватило времени на отладку. Тем более - на третий вариант, с драйвером для ntpd. Да и все равно это было бы без толку - при наличии интернета NTP и так дает вполне достаточную для привязки секунды точность - гораздо лучше требуемой плюс-минус полусекунды. Свой аппаратный NTP лучше в этом смысле только тем, что он дает независимость от интернета. В общем, Олег всем нам добавил головной боли, и только чудом его не повесили на телескопе
Т.о. при текущем состоянии прибора Олег Р. мог, строго говоря, вобще не приезжать - временный выход, такой же, как сейчас, был бы найден и без него. С другой стороны, устройство как таковое само по себе уже работает и обеспечивает ту функциональность, которая мне нужна для управления камерами. Поэтому мы с Володей Я. придумали компромиссный вариант того, как довести устройство до требуемой степени законченности с минимальными усилиями со стороны Олега (и, соответственно, за разумное время - скажем, осенью). А именно, устройство Олега интегрируется с предлагаемым Володей готовым решением NTP-сервера, так что Олегу остается только 1) доработать устройство до 4-канального варианта и 2) поменять распознавание меток времени от GPS с протокола TSIP на NMEA. Такой гибридный девайс сможет одновременно и управлять камерами в нужном нам режиме, и выдавать время по NTP аппаратно прямо в LAN комплекса, подключаясь при этом по одному Ethernet-кабелю. Я считаю, что совсем отказываться от устройства Олега не надо - все-таки, свою подзадачу (управление камерами) оно решает, и это лучше, чем простая привязка к PPS, хотя бы тем, что ликвидируется полусекундная в среднем задержка экспозиции, т.е. на полсекунды на каждый кадр на каждую камеру повышается итоговая производительность комплекса, а также появляется возможность, если нужно (и если позволяет скорость камеры), делать экспозиции чаще секунды.
(Как это можно было бы сделать даже сейчас, по PPS - это отдельная история; если коротко, это позволяет Apogee, а FLI - нет; надо пинать их, чтобы расширяли функциональность, и вряд ли они сделают это на уже выпущенных камерах.) Пока же Олег не сделал всего, чего нужно, единственным
временным вариантом, чтобы не зависеть от него, остается использовать только предлагаемый Володей NTP-сервер и для синхронизации системного времени в сети, и для привязки затворов по PPS. Это наиболее реализуемый вариант. Использование в этом же качестве старых тримбловских приемников на ЭОП исключается хотя бы потому, что NTP очень плохо работает с протоколом TSIP (см. мои объяснения по поводу проблем со временем в первых пробных наблюдениях). И, повторяю, совсем отказываться от устройства Олега тоже, по-моему, не очень правильно, потому что оно дает полезную функциональность. Надо только сделать временный независимый от него вариант, который будет, обеспечивая минимальную функциональность (PPS + NTP), работать, пока Олег доделывает свою часть, и потом легко состыкуется с ней. Это - мое мнение, но прошу его учесть, если обсуждение по этому поводу на днях будет без меня.
На попытки получить аппаратное время (и на утрясание протокола управления) я убил достаточно много своего собственного времени
С остальным проще. Я доводил не доведенные в предыдущий раз элементы системы управления: 1) автофокусировку, 2) поддержку ручной фокусировки из веб-интерфейса, 3) автоматическое определение параметров ориентировки с возможностью досрочного прерывания из веб-интерфейса по необходимости, 4) более продвинутую реакцию на софт-лимиты. И, конечно, мелочи, которых всех не упомнишь. Пп.1 и 3 я, в основном, доделал еще в прошлый раз, но тогда не хватило ясных ночей их проверить. В этот, правда, тоже не повезло - первую неделю неба не было практически вообще, оно появилось прямо перед приездом остальных, но убедиться, что оба пункта работают стабильно, я все-таки успел. Алгоритм автофокусировки, правда, я еще попытаюсь ускорить (сейчас она занимает до 10 минут, а я хочу уложиться в минуту-две), но это уже при следующей итерации; главное, и сейчас автоматическая вполне работает на всех инструментах. Ручная фокусировка (п.2) тоже есть, но только на уровне FORTE - в веб-интерфейс она не выведена, группа Лапинского собирается сделать это при следующем большом обновлении. Автоалайнмент (п.3) из веб-интерфейса работает на ура. И теперь телескоп благополучно выбирается (п.4) из любых хитрых положений, в которые может попасть по ходу наблюдений - прежде всего, на севере в районе плюс-минус часа от меридиана. Кратчайшая траектория из таких положений может проходить под горизонтом; в этом случае срабатывают софт-лимиты, и труба раньше останавливалась в окрестности софт-лимита и могла выбраться из нее только при наведении в ту точку, траектория в которую не ведет через запрещенную область. Если проще, телескоп мог застрять в одном положении, пропустить часть объектов и выйти из такого положения только при удачном стечении обстоятельств. Это не касалось режима обзора ГСО, в котором труба движется на юге небольшими шагами - оно могло возникнуть при наблюдениях по ЦУ объектов, которые могут залезать на север и быть при этом достаточно низко. Сейчас FORTE корректно отработает перемещение из любой точки в любую, не застревая в окрестности софт-лимита.
Сразу отмечу, что это совсем не то же самое, что проблема наведения в пол и наматывания проводов, что произошло при бедных впечатлительных и неподготовленных египтянах
Та проблема была связана просто с некорректно проведенной процедурой ориентировки инструмента и с работой с телескопом из-под ХАОСа, который в принципе не понимает логику работы вилки. В FORTE с этим все в порядке (и было в порядке еще тогда), и я в очередной раз проверил все три инструмента, погоняв их в самой экзотической последовательности. Все крутится как надо, и будет крутиться и далее, если не трогать телескоп руками (25-ку можно запросто сдвинуть, задев трубу или противовес), не двигать его с пульта при неактивном состоянии системы управления (статус "выключено" в веб-интерфейсе) - для этого пульт убран в ПУТО, - не переключать контроллер приводов на другой компьютер и не крутить его из других программ. Полный набор функций, позволяющий настроить наведение с нуля, в веб-интерфейс не выведен. И, я думаю, выводить его туда и не надо - потому что а) это чисто пусконаладочная операция, не требующаяся в штатном режиме (никто ведь не собирается предусмотреть, например, настройку параметров приводов и знаков осей из интерфейса), и б) будет слишком велик соблазн нажать не туда (либо вероятность нажать не туда случайно). Минимальный набор элементов управления, которые могут потребоваться наблюдателю, там, все же есть, если не ошибаюсь: это кнопка старта из парковочного положения, которая нужна, если вдруг все же произошло что-то совсем из ряда вон, но ничего не сгорело, и только телескоп смотрит и едет совершенно не туда (тогда, чтобы сэкономить на поездке специалиста - меня, например - наблюдатель с пульта выводит телескоп примерно в парковочное положение и нажимает эту кнопку; после этого ситуация наведения в пол и закрутки через север исключена), и кнопка автоалайнмента, которая используется, если телескоп смотрит и едет примерно туда, но неточно - например, из-за того, что его задели, или он постепенно съехал из-за люфтов. Я, уезжая, сказал не пользоваться и этой кнопкой тоже - наверное, погорячился, и это все-таки слишком сильное требование. Ею не нужно пользоваться без необходимости - это да, но 40-ка, например, будет, видимо, постепенно понемногу съезжать, так что корректировка явно потребуется. Надо только проверить, действительно ли она нужна (снять, например, по координатам яркую звезду в окрестности начала отсчета алайнмента - часовой = дельта = 0 - и посмотреть, насколько она не в центре), и выполнять автоалайнмент по необходимости. Впрочем, если нет большого сбоя координат, он проходит достаточно быстро - около минуты. В дальнейшем я планирую инициировать алайнмент автоматически, по мере необходимости, если при обработке кадров обнаруживается большое несоответствие координат наведения и фактических. Пока же можно контролировать это самостоятельно - допустим, раз в несколько дней. Да, я не помню, запускал ли я алайнмент на 25-ке после того, как Олег Чекалин ее немного сдвинул после перепрокладки кабелей; Виталик с Димой, проверьте на всякий случай.
И, раз уж пошел такой разговор, озвучу еще раз то, чем насмерть запугал Диму и Виталика (особенно Диму
).
(Кстати, я не понимаю, чем это Виталий так заинтригован - он-то это слышал, и даже не один раз.) Речь о том, что ни при каких обстоятельствах нельзя вынимать USB разъемы на управляющих компьютерах. Даже ради самой благой цели, включая проверку работы камеры, наблюдение уникального гамма-всплеска и т.д. Причина проста: даже если воткнуть все обратно в те же разъемы, а трубу вернуть в исходное положение с точностью до щага энкодера, нет никакой гарантии, что сохранятся имена устройств. Это касается, прежде всего, бинокля, где запросто первый фокусер может начать крутить вторую камеру и наоборот; но и у сороковки возможна путаница фильтров с фокусером. Пока что управлять этим процессом мы не умеем, и можно настроиться только на то, что есть. Если разъемы не вытыкаются, все чудесным образом сохраняется от включения до включения (что само по себе удача). Дальше у Вовки Я. совместно с Лапинским есть идеи, что с этим делать, чтобы обеспечить уникальную привязку устройства к его имени в системе. Но пока с этим лучше не играться. Потому что самое вероятное последствие такой игры - телескоп просто перестанет запускаться, и продиагностировать это дистанционно будет крайне проблематично. В этом случае мы решили, что выезд на воды группы специалистов будет за счет виновника. Он был предупрежден...
Далее, я почти закончил модуль интерполяции эфемеридных файлов изнутри FORTE. Это нужно для того, чтобы обеспечить наблюдения по ЦУ с сопровождением. При этом эфемерида рассчитывается заранее в сегменте АСПОС с использованием нормального прогноза - а не упрощенного, как в Апексе. Я не особо торопился с этим модулем, потому что в веб-интерфейсе уже реализовано наблюдение по ЦУ: дается команда наведения на точку с координатами, равными текущим коорднатам объекта по эфемериде, ведения с его текущей скоростью и выполнения экспозиции. Это похоже на то, как ведет себя ХАОС, и несколько менее точно, чем хотелось бы, потому что не учитывает конечное время перенаведения - но это, по крайней мере, работает. Поэтому мы с группой Лапинского решили перенести полную реализацию этого механизма с моей стороны и подключение его к веб-интерфейсу на следующее большое обновление ПО, пока же они будут возиься в основном с софтом на стороне сегмента АСПОС. Ну а у меня там почти все дописано, осталось протестировать и написать спецификацию,
И пара слов о тех проблемах, которые непосредственно ко мне не относятся, но повлияли так или иначе на ход работы. Во-первых, на [bb]всех[/bb] телескопах в том или ином виде почему-то были проблемы с фокусерами. Ну ладно, на 25-ке просто сломался разъем - тут все понятно, заменили - работает. Но на 40-ке фокусер никак не мог найти нуль-пункт, а после замены на новый проявилось все ровно то же самое. Олег Чекалин обнаружил виновника - узел сопряжения камеры; он объяснит, если что, подробнее. Но в результате настроить и проверить автофокусировку на 40-ке удалось только ближе к концу поездки. А до кучи в последнюю ночь обнаружилось, что заклинило один из двух фокусеров на бинокле. Олег это быстро исправил утром, но проверить все в сборе мы уже не успели. Сложность в том, что вся система управления биноклем настроена на работу одновременно двух каналов, поэтому если не работает один, не работает весь телескоп. Был вариант вернуть его в одноканальный режим, чтобы еще раз полностью проверить его хотя бы в таком режиме, и в нем оставить. Но я решил, что это все-таки хоть и спокойнее, но менее правильно, а по исправлении фокусера все остальное должно работать, поскольку работало до того, так что мы оставили его в двухканальном варианте (первоначально, кстати, обе трубы бинокля смотрели строго в одном направлении, что меня очень повеселило). В результате он остался единственным инструментом, на котором я не успел полностью провести формальную проверку всего в сборе. Ко всему прочему, Олег Русаков всю последнюю ночь сновал туда-сюда, протаскивая кабели синхронизации - как всегда, в последний момент. Протащили их только утром, поэтому я успел до отъезда только проверить, что камеры 25-ки и 40-ки (вторая камера на бинокле к тому моменту еще не висела) работают в триггерном режиме от PPS, так что ближайшие наблюдения, как появится небо, будут уже с аппаратно привязанным временем.
Резюме. Мы, наконец, оставили комплекс в таком состоянии, когда наблюдатели могут получить измерения без участия электронщиков, механиков и программистов. Возможные проблемы ПО, которые не были выявлены при всех тестированиях (и те, которые выявили, но не успели исправить за их незначительностью), можно решить дистанционно. Некоторые возможные аппаратные поломки (например, опять заклинит фокусер), которые удастся решить самостоятельно на месте, могут тоже потребовать небольшой дистанционной настройки софта. Но и это решается. Остается надеяться на то, что фатальных поломок пока не будет. Хотя... блоки питания клиентов на телескопах, а потом крыша 25-ки... Да еще зная, что пока нет аппаратной блокировки движения крыши, когда телескоп не запаркован (из-за чего сломалась камера на 40-ке), а программное управление ею без выхода из ПУТО уже есть... Но будем все-таки надеяться.
И еще мой личный формальный отчет для Зайца ^^
1. Усовершенствованы алгоритмы автоматической фокусировки и ориентировки и реакции на софт-лимиты. Работа алгоритмов проверена на всех телескопах комплекса.
1а. Проверена сходимость алгоритма автофокусировки при различных метеоусловиях; требуемое количество итераций не превышает 15 на всех телескопах, что дает время фокусировки около 10 мин. Имеются идеи для дальнейшего и, вероятно, значительного ускорения работы алгоритма.
1б. Автоматическое определение параметров ориентировки может быть инициировано и прервано по команде оператора с помощью веб-интерфейса. Алгоритм устойчиво и быстро (ок. 1 мин.) работает на всех телескопах.
1в. Разработан, реализован и протестирован алгоритм коррекции положения трубы при срабатывания софт-лимитов. Алгоритм функционирует как на параллактических, таки на вилочных монтировках.
Пп. 1а-в позволяют проводить регулярные наблюдения на всех телескопах комплекса, пользуясь только веб-интерфейсом оператора и не прибегая к помощи консольного интерфейса FORTE.
2. Реализован на 80% модуль интерполяции эфемерид для расчета координат и скоростей объектов. Этот модуль позволит более точно осуществлять сопровождение объектов по ЦУ и упростить процедуру формирования задания на наблюдение веб-интерфейсом.
3. Реализован и протестирован модуль управления службой времени STM32 (О.Русаков, Ю.Маркелов).
4. Произведена настройка ПО управления комплексом с учетом текущей аппаратно-программной конфигурации и устранены мелкие недочеты различных алгоритмов, выявленные в ходе тестирования.
Очень надеюсь, что ничего существенного не забыл из предыдущего текста.
