oleg.milantiev.com

Как получить кадр с камеры (Linux+Python+INDI)?

Скажем, перед вами возникла задача… такая же, как когда-то передо мною. Или похожая. Задача получения кадра изображения с камеры, подключенной к мини-компу типа Raspberry Pi / Orange Pi и т.п. клона.

Все эти мини-компы (пока что), уверенно работают под разными клонами Linux. Я привык к RH-way дистрибутивам, поэтому с удовольствием установил не самую обновляемую Fedora 22 на мой Orange Pi компик.

Мне нравится идея универсализации, создания некой абстрактной прослойки меж астрооборудованием ил астрософтом. На винде это ASCOM (пусть он трижды кривой и тормозной, но свою функцию «универсализатора» он выполняет). На юниксах и, в частности, на Linux — это INDI.

Я довольно неплохо знаю ASCOM, писал и драйвера, и в клиентских прогах использовал как монтировку, так и камеры. Если не брать во внимание, что мне не нравится dotnet и win-программирование (да и сама винда как ось) в целом, то идеология ASCOM мне близка. Скажем, наша задача получения кадра с камеры решается так:

• есть аском. Он просто есть. Он есть центр этой вселенной. Всё общение происходит через него;
• есть драйвер камеры. Скажем, QHY5 камерки. Или симулятор. Или Starlight Oculus (именно её кадры я получал на Orange Pi), или … В этом и суть, что все драйвера всех камер реализуют ASCOM.iCamera интерфейс. Он декларирует, что все дрова должны поддерживать таки и такие вызовы;
• есть софтина, которую я пишу. Например, «получалка одного кадра длительностью 1с». В этой софтине я подключаюсь к COM-объекту ASCOM.Camera (написание не точное, лишь чтобы предать суть), то есть создаю экземпляр нужного класса. И у этого объекта уже есть методы/свойства задания выдержки, экспозиции и получения массива кадра. С виду всё логично.

В инди всё … по-Индийски, я думаю. Нисколько не хотя обидеть индусов, встреченные мною программисты часто из них … (нет-нет, я не буду ругаться матом сейчас) :).

• первым делом запускается INDI-сервер для моей камеры:
  /usr/bin/indiserver -v -m 100 indi_sx_ccd
  Можно сказать, что ASCOM сам это делает, подгружая нужный «драйвер».
  То есть в INDI, в отличии от ASCOM, нет центра. Есть один процесс под эту камеру. Второй — под другую. Третий под монти и т.п. В этом есть смысл, но есть и геморой, кмк;
• теперь на выбранном языке программирования (я выбрал Python) мы пишем INDI-Клиент. Это класс! Не в смысле, как классно, что мы пишем клиент, а в смысле, это именно объявление ООП-класса 🙂
  Собственно, экземпляр этого класса и общается с камерой… через callback’и.

import PyIndi
class IndiClient(PyIndi.BaseClient):
… и понеслось

Создаём экземпляр класса, запускаем коннект и дальше объект живёт своей жизнью:

• инди-сервер вызывает метод newDevice, типа появилось новое устройство;
• инди-сервер вызывает метод newProperty, передаёт им свойства. Все, что сам сочтёт нужным в последовательности, которую сам сочтёт нужным. В объёме, который именно ему будет интересен. Как в седьмом классе школы — тебе не интересно учить площадь треугольников, но никого это не волнует — тебе всё равно перечисляют все свойства треугольника и не только эту ненужную сейчас информацию;
• чтобы начать экспозицию, мы в newProperty получаем факт подключения и заполнения нужных свойств, даём команду серверу «смени число в свойстве CCD_EXPOSURE». Подняв его выше 0, начинается экспозиция. Правда, нужно крепко обкуриться в ГОА, чтобы так перевернуть простую клиент-серверную логику?
• получение кадра изображения — через callback вызов экземпляра класса, метод newBLOB. Типа ура, новый бинарник пришёл.

Мой исходник Python+INDI+Starlight Oculus AllSky камеры, чутка замусоренный в процессе поиска рабочего решения, я выложу сюда:
http://download.milantiev.com/astro/INDI/allsky.py.

И да, там огромный простор для чистки, оптимизации и улучшений. Но … мне хватило трёх дней борьбы с INDI, чтобы получив первый кадр больше не лезть в эту программу целый месяц. Нижняя часть программы вовсе не используется, но показывает неплохой диагностический пример использования INDI. Мопед не мой, моя адаптация под задачу.