Знание — сила, а незнание — мощный велосипедогенератор.
За 5 дней опытной эксплуатации демоны, обслуживающие болтвудовский датчик и all-sky почему-то наплодили уйму неотмерших потоков (хотя в коде выход из потока правильный), в результате несчастный кубитрак был загружен на 170%, и компиляция элементарного кода длилась две минуты! Эту проблему решил добавлением перезапуска демонов в cron.daily.
Вчера все это хозяйство разместили на Цейссе (но пока не устанавливали на крыше), включив во время отсутствия электричества (на Цейссе-то упсы, которые не меньше двух часов даже с рабочим телескопом выдержат). В итоге время на кубитраке получилось неправильным. По идее, это должно было устраниться, как только появится сеть — ведь на кубитраке запущен ntp-демон. Как бы не так! Решил опять велосипедно: отменой автозапуска бесполезного ntp-демона и добавления ntpdate в cron.hourly.
Удивился куче логов в /var/log (хотя это одноплатник — он вообще логи в оперативке должен хранить, или даже лучше в /dev/null). Т.к. проблема глубокая, решил ее лишь настройкой logrotate ротировать ежедневно, оставляя по 1 логу.
Ну и вообще, до сих пор негодую, что дебилиан перешел на systemd! Хоть у меня и есть репа генты для кубитрака, собранная в чруте, но очень проблематично обновляться: надо вынимать флешку и перезаливать образ. Что долго и совсем неудобно, когда эта флешка черт-те где. Пришлось вместо генты ставить эту дрянь. Судя по выхлопу systemctl, запущена толпа ненужных сервисов. Что-то поприбивал, но как бороться с автозапуском ненужного wpa_supplicant, не убивая идиотский нетворкманагер, не понимаю. Вообще логика создателей армбиана не ясна для меня: какой идиот на сервер будет пихать нетворкманагер или системД? А уж тем паче, если это — сервер на одноплатнике!

Тьфу! Выпустил пар. Отдохну, а после обеда продолжу накапливать гнев — мне еще на серваке с Scientific Linux (ага, тоже с поцтерошлаком) разворачивать логгирующие демоны и апач с proftpd настраивать… Ну почему наши информатики используют это порождение Красной Шапки? И сами же матюкаются на костыли с поцтерошлаком. Как те мыши с кактусом!
Благодаря помощи [profile] alextutubalin, код утилиты для работы с all-sky теперь полностью свободен. Я добавил дебайеризацию посредством libraw. Вот такие jpeg'и теперь может генерировать сетевой клиент (помимо сохранения "сырых данных" в tiff, fits и raw dump):

Камеру можно будет водрузить на ее законное место, временная заглушка для информационных панелей уже будет работать, останется настроить сервер БД для хранения данных (чтобы иметь возможность оценить небо в любой момент времени из архивных данных).
Еще остается подключить болтвудовский датчик, но это не так критично, как нормальный all-sky.
Выжимка из man 3 daemon (кстати, в армбиан почему-то отсутствует, читал в генте):
daemon(): _BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
Так что, оказывается, _BSD_SOURCE и _XOPEN_SOURCE не эквивалентны, и указывать нужно обе! Потому как некоторые вещи требуют _XOPEN_SOURCE > 600, из-за чего у меня в Makefile значится -D_XOPEN_SOURCE=1111.

Но, честно говоря, такого поворота, чтобы нужно было меньше определенного числа feature_test_macros выставлять, я не ожидал!

В догонку:
/usr/include/features.h:148:3: предупреждение: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"

Я ваш дом труба шатал!!! Еще и в Makefile делать проверку версии gcc?

Ну, вроде бы все заработало. Сейчас запустил на кубитраке серверный процесс, работающий с all-sky, а на ноутбуке из дома — клиент. Если что-то отвалится, увижу. Пока вроде слаженно работает.
Обновил репозитории на гитхабе-сосфорже-битбакете-гитлабе.

Глюки

Feb. 17th, 2017 06:05 pm
Поставил на кубитрак армбиан (нет уже сил с гентой: собирать пакеты можно лишь на компьютере, несерьезно это). Почти час убил в попытках понять, почему же у меня перестало работать считывание изображения с all-sky. Затык обнаружился здесь:
size_t read_tty(uint8_t *buff, size_t length){
    ssize_t L = 0;
    fd_set rfds;
    struct timeval tv;
    int retval;
    FD_ZERO(&rfds);
    FD_SET(comfd, &rfds);
    tv.tv_sec = 0; tv.tv_usec = 50000; // wait for 50ms
    retval = select(comfd + 1, &rfds, NULL, NULL, &tv);
    if (!retval) return 0;
    if(FD_ISSET(comfd, &rfds)){
        if((L = read(comfd, buff, length)) < 1) return 0;
    }
    return (size_t)L;
}

Строчка "wait for 50ms". Функция эта выполняется до тех пор, пока полностью нужное количество байт не считается, или не выйдет таймаут. Почему-то на компьютере все нормально работало, а на кубитраке стали "теряться" данные. Пришлось увеличить tv.tv_usec до 500мс.

А еще я намучился с форматом для printf: на компьютере uint64_t выводится как %lu, а кубитрак хочет %llu. Неужто нет нормальных обозначений printf, общих для любых архитектур? Идиотизм какой-то...
В рамках бодания с таймером на STM32F030 родил морзянку: фразы, пришедшие по USART1 (до '\n') выпискиваются в коде Морзе пищалкой, висящей на PA6 (TIM3CH1). Короткое видео паршивого качества.
Вот что за ненормальные придумали git? Почему простое изменение файла по умолчанию не отражается в git commit? Обязательно нужно флаг -a писать! Задолбался уже лишние коммиты делать!
А делал я коммит опять в Sbig340. Теперь туда добавлена полная "демонизация" и клиент-серверное взаимодействие: сервер высылает клиенту по запросу шапку вида "параметр=значение", где "параметры" — все необходимое для сохранения изображения, в том числе и оно само ("imdata=...").
Решил, что пока не добью, домой не пойду. И полезли всякие гадости: то malloc где-нибудь забуду, то, наоборот, free лишнее, то проверку не воткну...
Теперь работает. Сервер получает изображения, клиент их собирает и сохраняет в условленный файл. Экспозиция пока управляется только сервером. Но можно добавить при желании и управление клиентом.

В общем, минимум по обслуге камеры выполнен почти полностью (еще нужно запустить кубитрак, на котором будет крутиться сервер). На подходе болтвудовский датчик. Ну, а с завтрашнего дня надо вплотную заняться лекциями, которые мне уже скоро читать аспирантам, а их нет. Думал IRBIS'ом заняться (течи поискать), но это уж точно некогда.
В "дебайеризатор" я добавил мониторинг на inotify+poll на событие IN_CLOSE_WRITE (файл модифицирован и закрыт) — теперь файлы автоматом преобразуются в цветные картинки, как только обновятся.
К сожалению, лицензия "дебайеризатора" не позволяет выложить модифицированный исходный код. Вся надежда на libraw.

Как все это будет смонтировано. Решили воткнуть компьютерный БП (чтобы было и 12В, и 5В с хорошим током) и кубитрак в электрощиток подкупольного Цейсса. К кубитраку по USB присоединить преобразователь интерфейсов all-sky и болтвудовского датчика (я, кстати, не то слово как офонарел, узнав, что самопал обойдется максимум тысяч в 10 рублей, а цена этого без разтаможки и накладных — почти 2 килобакса!). В итоге получится эдакий сборщик информации, с которого можно будет брать последние данные любым компьютером саовской сети. Для хранения уже есть сервер, надо будет к нему прилепить веб-морду, чтобы можно было скачивать толпой архивные данные.
Итак, поковырявшись немного с libraw, я плюнул: разобраться в недрах такого бешеного количества кода просто нереально! Поэтому пока выбираю более медленную, но все-таки работающую "Self Similarity Driven Demosaicking". В принципе, цветопередача получается вполне нормальная, я вывел на монитор эту картинку и после обработки получил:
img

Саму утилиту тоже чуть подправил: добавил простой "калькулятор экспозиций" (надо его по звездному небу проверить, в комнате он давал сходимость на 3-5 итерациях).
Еще )
После обновления генты отчет обсерватории (он на скриншоте в предыдущей заметке) перестал компилироваться. Латех ругался на непонятные ошибки (знак =, например) до \begin{document}. Методом постепенного включения \endinput был обнаружен проблемный участок:
%
% Degrees, minutes and seconds above the decimal point
%
\def\@rmpt#1.{#1}
\def\put@pt#1#2.#3{\ifx#3\empty\@rmpt#2#1\else #2.\kern-.25em\relax#1\@rmpt#3\fi}
% magnitude
\def\mag#1{\ensuremath{\put@pt{^m}#1.\empty}}
% degrees
\def\arcdeg#1{\ensuremath{\put@pt{^\circ}#1.\empty}}
% arc minutes
\def\arcmin#1{\ensuremath{\put@pt{'}#1.\empty}}
% arc seconds
\def\arcsec#1{\ensuremath{\put@pt{''}#1.\empty}}

Сразу подумал, что что-то новенькое сделали на макрос \mag, и действительно: он уже давно был, только в предыдущих версиях texlive не вылезало никаких проблем. В общем, заменил его на \Mag и sed'ом переделал все файлы:
find . -name '*.tex' -exec sed -i 's/\\mag/\\Mag/g' {} \;

Вот хоть бери и меняй все \def на \newcommand!
В попытке выяснить, кто же виноват, и что с этим делать, я собрал в кучу заголовочные файлы от ST с инициализацией от opencm3 и сделал "безбиблиотечную" среду.
Для проверки деления набросал «мыргалку», которая либо равномерно мигает диодом с периодом 4 секунды (если надета перемычка между землей и PA12), либо морзянит "SOS".
arm-none-eabi-gcc, собираемый кроссдевом в генте на этом примере обломался: как только я снимал перемычку, микроконтроллер уходил в глубокие раздумья.

Гугол подсказал мне, что эта проблема возникала далеко не у меня одного. И решения ее стандартным gcc просто нет! Но есть пропатченные тулчейны. Отсюда я скачал тулчейн, распаковал директорию в /opt и попробовал.
Теперь в директории arm-none-eabi/lib/thumb появились раздельные библиотеки для разных архитектур ARM. Вот эта строчка Makefile
LDLIBS		+= $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
позволяет слинковаться с правильной библиотекой (v6-m/libgcc.a). В итоге деление работает без проблем!

Жаль, что в генте так плохо с разработкой под микроконтроллеры!
сделаю свою среду под STM32F0. Возможно, со временем и под F1 запилю. USB, lwIP и прочих библиотек (правда, кроме файловых систем: я так и не нашел кодов простого модуля для работы с EXT2 или любой другой ФС, не имеющей дурацких ограничений vfat и в то же время не требующей десятка килобайт бинарника тупо для поддержки базовых операций) в интернете полно — за 2-3 вечера каждую, думаю, можно прилепить как-нибудь.
Для начала надо будет создать из ld-скриптов, болтающихся на просторах интернетов, и базового набора ST'шных "сниппетов" что-то рабочее. Как минимум — удалить ассемблерный startup-файл и system_stm32..., да подшаманить с ld-скриптами.

Надеюсь, вечера за 3-4 базовую надстройку слеплю.
Итак, вчера я написал базовый функционал для управления турелью "High Speed Filter Wheel" от Edmund Optics, сегодня добавил функцию смены имен колес/фильтров и более-менее дополировал. Код лежит на гитхабе (т.к. утилитка мелкая, я ее в сниппеты запихал, чтобы отдельную репу не делать), а также в одноименных репах на сосфорже, гитлабе и битбакете. Функционал сброса имен в "умолчательные" значения пока не добавлял (не думаю, что нужно).
Дальше )
Видео:


UPD


Сегодня взял вторую турель и доработал утилиту: избавился от вышеназванных багов, добавил возможность сброса имен в значения по умолчанию, добавил возможность установки в позицию "дом" той турели, в которой есть указанный фильтр. Да и вообще, оказалось, что все купленные колеса промаркированы как 'A', т.е. обращаться надо будет либо по идентификатору (что не очень удобно), либо по именам (что удобней). Хотя, конечно, плохо, что колеса одноименные: если колесо воткнуть в "чужую" турель, понять об этом можно будет лишь после пробных снимков (и то, возможно, не сразу)...

Систему управления фотометром планируем только под линукс писать (Тимур говорит, что "родной" линуксовый SDK для быстрой камеры присутствует и есть истории успеха работы с ним), архитектура будет клиент-серверная. А вот клиенты уже будут кроссплатформенными (для себя, наверное, консольную сделаю, а для народа тимур на Qt нарисует). Самой интересной и сложной будет методическая работа: как обрабатывать "кубы данных" с быстрой камеры, чтобы реализовать работу Lucky imaging. Заодно думали про фокусировку: если у цейсса нет каких-нибудь характерных асимметричных дефектов изображения (скажем, комы) с амплитудой выше полуширины первого максимума функции Эйри (но, понятное дело, меньше сиинга, иначе эти дефекты давно заметили бы), то определить знак изменения фокуса без перефокусировки (или установки в сходящемся пучке асимметричной маски) будет невозможно!
Появилось у нашей лаборатории желание создать фотометр для Zeiss-1000 с минимумом разработок железа/софта и т.п. Одной из частей фотометра будут две турели High Speed Filter Wheel. Как обычно, железо огороженное. В отличие от предшественника Intelligent Filter Wheel (у которого вполне нормальный последовательный интерфейс с описанным в документации протоколе), у этой железяки только мастдайнутый установщик и никакой документации о протоколах!

При подключении к компьютеру железяка создает устройство /dev/hidrawX. На основе примера работы с этими устройствами из ядра я попытался определить, как же им управлять. И, в принципе, основные вещи реализовал (установка в "дом", установка на заданную позицию), но без понятия, как реализовать сброс (в отличие от usbdevfs эмуляторов последовательных портов здесь простым ioctl'ом перезапустить соединение не вышло). А сброс очень важно реализовать, т.к. любая проблема в протоколе вызывает "глухоту" контроллера: он перестает реагировать на управляющие команды.

Кстати, в опытах выяснил интересную вещь: если в первую десятку регистров hidraw под ведром 3.12 писать ненулевые данные, ядро (случайным образом, кстати: можно десяток раз так сделать без последствий, а можно с первого раза попасть) уходит в глубокий kernel panic, перезагрузка после которого чревата десятиминутным fsck'ом (это еще хорошо, что у меня один винт и небольшой)!

Протокол )

Вот таким жутким велосипедостроением приходится порой заниматься, потому как разработчики железяки закрысили описать протокол (заодно передаю привет Canon'овцам)! То ли еще будет с ПЗС…

UPD


Пока вендокомпьютер был свободен, я поставил софт управления турелью и попытался проанализировать трафик сниффером.
Регистры изменения положения турели )

UPD-2


Я вспомнил, что у меня есть вендокомпьютер для работы с Шаком-Гартманном (да, каюсь: я уже 6 лет не могу собраться, и написать нормальное ПО без огораживания). С его помощью была проделана оставшаяся работа.
Регистры работы с EEPROM и сброса )
Все, как только напишу полноценную управлялку, создам новую тему.
Мой старый велосипед для обработки параметров командной строки перестал меня устраивать, т.к. не давал возможности указывать один и тот же параметр несколько раз (скажем, для сложных конвейеров), поэтому на его основе родился новый велосипед.
Велосипед изобилует ужасами вроде
void **aptr = *((void***)paptr);
...
result = (*((void**)aptr) = (void*)strdup(optarg));

и т.д., и т.п. (можно почитать код вместо принятия рвотных веществ ☺).
пример )
Так как у нас с субботы идут технические наблюдения, погоды уже три ночи не было, а караулить хотя бы до полвторого (позже открываться смысла нет: рассвет слишком близко) все равно нужно, я навелосипедил утилитку для работы с GPS-модулем U-BLOX-6M (как здесь).
Думал, что получится более-менее точно синхронизовать часы просто при помощи GPS. Ан нет, факир был пьян: задержка между концом выдачи пакета по UART и началом секунды составляет порядка 20мс, чего и следовало ожидать на скорости-то 9600!
В общем, нужно будет еще привелосипеживать использование PPS, если захочется получать точное время на Raspberry Pi. Судя по руководствам из интернета, это — тот еще геморрой. Пожалуй, проще, наверное, будет свое что-нибудь еще довелосипедить. Скажем, сейчас при помощи команды date $(./gpstest -DS), выданной от рута, можно выставить часики с запозданием на пару-тройку десятков миллисекунд. Если еще добавить сюда поллинг GPIO, на которую будет подаваться сигнал PPS, то вполне возможно, что точность лучше миллисекунды будет обеспечена. А лучше и не надо.

Следующий на очереди — модуль GSM. Как минимум надо будет научиться работать с USSD-запросами и SMS. А еще неплохо бы и звонить научиться + пользоваться телефонной книгой. И можно будет сделать какую-нибудь свистоперделку.
Я уже потихоньку ковырялся в "малинке", но теперь вот настала пора собрать все воедино и сделать простую систему управления с веб-мордой. Система позволит при помощи локального корректора ставить интересующий объект на щель спектрографа. Возможно, там еще и будет управление ПЗС-матрицей (но вряд ли, т.к. проще из командной строки скриптовать, чем кнопки тыкать).
Пока что реализован только интерфейс управления локальным корректором: гитхаб, сосфорж. Простая панелька, позволяющая менять скорость шаговых двигателей корректора, двигать его по XY в +/- и возвращать в ноль. Видео с камеры подсмотра тоже будет транслироваться через вебсокеты (получается где-то 5-7 кадров в секунду, что вполне приемлемо для этой задачи). Пока вместо видео — заглушка (чередуются 2 картинки), заготовка интерфейса к видеозахвату через ffmpeg у меня уже реализована, но возникла проблема с китайскими "фреймграбберами" ("под капотом" у них оказался совершенно дурацкий чипсет, под который нет работающего модуля ядра, так что, надо будет либо взять старый одноканальный фреймграббер и релюшкой переключать видео, либо пилить устаревший много версий назад модуль ядра).
Заодно вчера дома начал пилить заготовку, чтобы в будущем можно было быстро развернуть любой проект с веб-мордой на вебсокетах (кстати, надо бы еще с аутентификацией разобраться, а также с сегфолтами в случае отключения клиента во время передачи очередного кадра видео).
Сегодня целый день провозился с реализацией простого интерфейса управления подвижкой 8MT175-150 при помощи подключаемого к компьютеру по USB драйвера SMSD-1.5. Одной из "особенностей" документации к драйверу была досадная "очепятка" в протоколе управления.
Теперь остается разобраться с узлом крепления диагонального зеркала (да и само зеркало заалюминировать), и можно будет собирать и юстировать наш БТА-комбайн для измерения поправок АСУ и оценки качества поверхности главного зеркала.
И не могу не похвастаться )
В свете приемки нового старого зеркала БТА(наверное, через год уже примем) возник вопрос о разработке системы контроля качества поверхности (мы над этим работаем: это будет смесь классического Гартманна и Шака-Гартманна). А еще возник вопрос о реализации полноценного мониторинга распределения температуры по зеркалу, ведь даже сравнительно небольшой перепад температуры (оценочно около 0.15°C) даст заметное искажение волнового фронта (1λ для 500нм).
Здесь — небольшой обзор возможных решений системы мониторинга, полученный в результате опроса мнений на сайте kazus.ru, здесь, в ЖЖшке и при помощи google. Небольшой обзор )
Бился-бился я с ортогональными на кольце полиномами Цернике, но что-то сразу не подумал, что можно ведь другим путем пойти: ведь можно (пусть и неоднозначно) разложить функцию даже по базису не ортогональных полиномов! А для этого всего-то достаточно использовать метод наименьших квадратов.
подробности )
Решил я (в основном - для себя, чтобы не забыть) описать результаты тестирования светоприемника Apogee Alta U16M с матрицей Kodak KAF-16803 (судя по стоимости светоприемника — немногим более 10 килобаксов, матрицу эту подобрали на помойке). Начальство поручило нам с Тимуром проанализировать, насколько поганый этот светоприемник и можно ли его использовать для ненаучных задач (например, для оценки экстинкции). В конце марта-начале апреля мы провели нужные измерения, а потом долго их обрабатывали.
Подробности )
P.S. К сожалению, у ЖЖшки отвалилась функция добавления картинок в сам ЖЖ, так что пришлось все кидать на imageshack.
P.P.S. Сегодня (10 мая) я таки умудрился домучить libapogee2.2 (которую нашел где-то на просторах интернета), чтобы она считывала мне кадр с ПЗС. Однако, несмотря на то, что экспозиция протекает нормально, температура устанавливается какая надо, все пиксели полученных изображений содержат 65535.
Буду доламывать дальше: все-таки, эта камера нам нужна будет для работы и надо обязательно научиться полностью управлять ею.

July 2017

S M T W T F S
      1
23 4 5 6 78
9 101112 131415
16171819 202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 20th, 2017 02:42 pm
Powered by Dreamwidth Studios