AMount - система управления телескопом

[Faddey]

Запустили гидирование с помощь Firecapture по ST-4.
ST-4

Звёздное ведение Wemos (коррекция -250).
Wemos

[user340]

Запустили гидирование с помощь Firecapture по ST-4.

Спасибо! Было интересно и полезно посмотреть ваши эксперименты, для расширения кругозора.
Да и вобще интересно посмотреть, как у кого гидирование работает.
Подскажите, какое фокусное расстояние трубы-гида и какая гидирующая камера использовалась?

У меня пока вот такое самодельное/самописное гидирование:
Тест от 21.05.2023
Звезда Вега.
https://disk.yandex.ru/i/ydT9If5G2mvueA

(кликните для показа/скрытия)

Монтировка: ALT-AZ
Приводы монтировки: шаговые трёхфазные 0.6 град.
Передаточное число червячных редукторов: 1:70

Труба: МС МТО-11СА без корректора.
Фокусное расстояние: 700-800мм ("нативное").
Кмера гид: usb2 модуль-вебкамера imx290
FPS: ~30
Распознавание звёзд: OpenCV
Гидирование On-Axis, за "холодным" зеркалом, по ИК-спектру.

[Faddey]

1200мм Ньютон
Камера ZWO 120MC, она же и гидирует через основную трубу. Отдельной камеры гида нет, вся задумка в том, что бы и снимать и вести одной программой.
В тестах использовал редуктор 0,6 что бы быстрее наводиться (1200/10*0,6=72 крат).
Пока гидирование через ST-4 еще только тестируется, есть идеи как сделать так, что бы Firecapture  более плавно вёл.

[user340]

1200мм Ньютон
Камера ZWO 120MC, она же и гидирует через основную трубу. Отдельной камеры гида нет, вся задумка в том, что бы и снимать и вести одной программой.
В тестах использовал редуктор 0,6 что бы быстрее наводиться (1200/10*0,6=72 крат).

Спасибо за полезные данные по конфигу сетапа с которого велась съёмка!

[Faddey]

Настроили совместную работу Wemos и Firecapture через ST-4.
При смещении монтировки (например, настраиваем корректор атмосферной дисперсии), Firecapture вернет изображение в нужную точку.

Wemos
Ведение звездное с коррекцией -44...-47 (карандаш)
Скорость для ST-4: 2

Firecapture
Tolerance: 50...80
Correction time: 300
Guider cycle: 1

Wemos + Firecapture

[FlexLM]

Сейчас работаю над реализацией поиска объекта по спирали. Зачем это нужно? Не всегда объект оказывается в поле зрения окуляра или искателя. И чтобы его найти решили автоматизировать процесс поиска через спиральную траекторию движения трубы. В основе спираль Архимеда.
Для AltAz целевых координат:
AzTo=Az+k×phi×cos(phi),
AltTo=Alt+k×phi×sin(phi),
где Az, Alt - начальные координаты объекта;
k - шаг спирали;
phi - угол.

Возможно, кто-то изучал ранее подобные методы поиска и их особенности. Прошу поделиться информацией.

[FlexLM]

Для AltAz монтировок сделал поиск объекта по псевдоспирали: скечт и apk
Псевдоспираль - окружность с изменяемым радиусом.
Как запустить?
1. В приложении отключаем трекинг.
2. Длительный тап на кнопке спирали карты неба позволяет настроить параметры спирали (шаг и угол в радианах).
3. Делаем на карте формальную привязку к объекту.
4. Нажимаем кнопку спирали.
5. Для отключения поиска по спирали нажимаем любую кнопку оси на реальном или виртуальном пульте (РП или ВП).

[viktor0154]

мошечь помочь \

[Antielvis]

Доброго дня!
Подключил на столе ESP32, LV8729 и Nema17 17HS4401S. Залил скетч. Через телефон начинаю крутить двигатель, двигатель раскручивается и как будто заклинивает, издаёт свист. Потом при остановке отклинивает и останавливается. Я так понимаю он не справляется с большими скоростями? В шилде поставил:
 iSPEED_AXIS[]=
                                101,      //1 - 8X
                                50,       //2 - 16X
                                25,       //3 - 32X
                                12,       //4 - 63X
                                5,        //5 - 136X
                                2,        //6 - 273X
                                1         //7 - 409X
Скорость MAX_RATE снизил до 10000. Начиная с 5й скорости всё равно начинает заклинивать. А на 1й не тикает, а тарахтит довольно громко. Пока снижал MAX_RATE были случаи, когда двиг не останавливается при отпускании кнопки, а продолжает крутиться пока не обесточишь. Дальше снижать MAX_RATE? Или явно что-то не так?
Всё это пока без редуктора. Редуктор в комплекте 1:100, общее передаточное число будет ~1500.

[Antielvis]

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

[Antielvis]

Наконец то и я собрал свою систему! Не с первого раза, но благодаря консультациям Олега всё заработало. Осталось красоту навести. Фотки тут https://disk.yandex.ru/d/f2E4jVGxyreZBQ
В качестве механизма использовал маховик от opel astra (GM) и бендикс от УАЗ. Шестерню бендикса сажал "нагорячую" на воротную петлю. Венец маховика оказался несъёмным, пришлось резать сваркой. Была вероятность, что может повести, но всё обошлось.
Пульт взял от старой приставки, на кнопки наклеил металлический скотч, развёл свою монтажную плату. Можно подключать родную плату от денди и обрабатывать цифровой сигнал с кнопок, там всё для этого есть. Писал для этого тестовый скетч, кнопки отрабатывают. Но времени на изменение скетча AMount не оказалось.
При первом испытании пульта, почему-то пульт не работал, хотя с телефона всё крутилось как надо. Через какое-то время телефон перестал "видеть" Wemos, думаю блютуз модуль на плате помер. У Олега оказалась свободная плата, отправил доставкой (еще раз выражаю огромную благодарность Олегу!). Как раз успел в срок, чтоб сын мог пользоваться. Теперь не нарадуется ))

[FlexLM]

Все новинки пока в папке debug: Скетч и Апк
1. В скетче для ESP32 переделана кривая разгона-торможения (см. вложение). Теперь ШД осей активнее проходят фазу ±ускорений.
2. Сделано три пользовательских трекинга (3 карандаша).
3. Ещё в Андроид-приложении в настройки добавлен чек-бокс "Автоподключение". Это сразу позволит автоматически подключаться к ранее выбранному ВТ-устройству после запуска приложения, минуя стадию выбора из списка устройств.
3. Теперь при выключении экрана смартфона большинство потоков переводится на паузу. Это съэкономит заряд аккумулятора телефона и разгрузит контроллер от лишнего запроса координат и т.п., когда пользователь не видит интерфейс.
4. При сопряжении сделана менее строгая проверка на соответствие NexStar-протоколу. Это должно снизить частоту сообщений "AMount не подключен".

Обратил внимание, что после включения блютус на телефоне первое сопряжение происходит дольше.

Для себя определил следующий алгоритм сопряжения смартфона с контроллером:
1. Включаем блютус на телефоне, чтобы он в дальнейшем не замедлял подключение своими внутренними алгоритмами.
2. Подаём питание на систему управления. Ждём 5с (желательно, но необязательно).
3. Запускаем приложение AMount на смартфоне.
4. Радуемся или думаем "почему что-то пошло не так".

[FlexLM]

Faddey (в карму +1) экспериментально обнаружил, что труба телескопа перестаёт заметно опережать объект, если к звёздной скорости добавить приблизительно +4сек./сут (это ≈15.04 угловых сек. в сек). Для этого в апк есть пользовательский трекинг (значок карандаша). Сейчас доступно три карандаша. До вчерашнего дня я никак не мог понять откуда берётся эта прибавка. Оказывается, что для определённого диапазона высот объектов над горизонтом существенное влияние на их видимую скорость оказывает атмосферная рефракция. Она как бы "замедляет" нисходящий объект. Есть даже такой трекинг King Rate. Его средняя величина 15.041 угловых секунд в секунду (см. Калькулятор). Более подробная теория.

Обновления скетча и апк я пока размещаю в папке debug.

[FlexLM]

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

[FlexLM]

Помогая со скетчем от Iovch, случайно обнаружил глюк в своей системе. А именно: подвисание/не выполнение части команд ардуиной (нет привязки, готу, переключения трекинга). Всему виной оказались новые формулы (вероятно, время расчёта?!) местного звёздного времени. Они появились после апреля. Esp32 новые формулы прекрасно тянула, а ардуина - нет. Игры с настройкой времени обмена данными через порт ни к чему не привели, поэтому в новом скетче сделал автоматический выбор формул в зависимости от типа платы.

[Толан]

Пока гидирование через ST-4 еще только тестируется, есть идеи как сделать так, что бы Firecapture  более плавно вёл.

Там есть настройки, длительность импульса и величина отклонения, при превышении которого сработает гидирование. А вообще-то там так грубо всё. Для Луны допустим ещё сгодится, но для чего нибудь посерьёзнее лучше использовать отдельные программы. Но для начала поиграйтесь с настройками в Firecapture.

[Толан]

Всему виной оказались новые формулы (вероятно, время расчёта?!)

Была похожая проблема при программировании PIC контроллеров, формулы и вычисления с плавающей запятой. Обработку прерывания по ошибкам, как всегда, не заморочился включить... были зависания иногда. Оказалость ошибка в том, что под acos оказывалось число 1.000...1  в последнем знаке 1, что допускают все мат библиотеки (+-1 в последнем знаке), а acos естественно уже не переваривал этого. Сделал предпроверку перед вычислением функции, всё нормализовалось. Может и у вас нечто подобное?

[FlexLM]

У меня ардуина спотыкалась на числе 360.98564736629 в выражении:  double theta0=280.46061837+360.98564736629*(JD-2451545.0)+0.000387933*T*T-T*T*T/38710000.0;
Если отбрасывал дробную часть и записывал просто 360, то считала нормально...

[Толан]

Если отбрасывал дробную часть и записывал просто 360, то считала нормально...

Странно... А JD какой формат? У меня было что-то подобное. Вот это выражение выдавало билиберду, если явно не указана размерность UL (остальные переменные double)  tmp=Agrad*3600ul; Причем только при умножении. Выражение Agrad=Asek/3600; вычисляется абсолютно правильно. 

[FlexLM]

Я тоже не понял почему esp32 нормально считает по новым формулам, а arduino - нет. Возможно, в каких-то случаях работа с вещественными числами ардуине не по зубам.
Тип данных: double JD

(кликните для показа/скрытия)

//===================================================================
// Юлианская дата                                                                             01.06.23
//
//hour=[0], minutes=[1], seconds=[2], mounth=[3], day=[4], year=[5], timeZone[6], standart time=[7]
//===================================================================
double julianDay(int Y, int M, int D, int h, int m, int s)
{
  if(M<=2) {M+=12; Y--;}

  int A=(int)(Y/100.0);
  int B=2-A+(int)(A/4.0);

  return (int)(365.25*(Y+4716))+(int)(30.600001*(M+1))+D+
         ((double)h/24.0)+((double)m/1440.0+((double)s/86400.0)+((double)dMillis/86400000.0))+B-1524.5;
}

//===================================================================
// Универсальное время из локального                                                          01.06.23
// byte iZH = часовой пояс
//===================================================================
double localToUniversalTime(double jd)
{
  return jd-(double)iZH/24.0;
}

//===================================================================
// Гринвичское звёздное время, град.                                                          01.06.23
//===================================================================
double siderealTime(double JD)
{
  double T=(JD-2451545.0)/36525.0;
  double theta0=280.46061837+360.98564736629*(JD-2451545.0)+0.000387933*T*T-T*T*T/38710000.0;
  return theta0;
}

//===================================================================
// Местное звёздное время, Рад.                                                               01.06.23
// DT[0]=hour, DT[1]=minutes, DT[2]=seconds, DT[3]=mounth, DT[4]=day, DT[5]=year
//===================================================================
double RLST()
{
  double jd=julianDay(2000+DT[5],DT[3],DT[4],DT[0],DT[1],DT[2]);
  double lUT=localToUniversalTime(jd);
  double dLST=(siderealTime(lUT)-dLongitude)/15.0;
  while(dLST>=24.0) dLST-=24.0;
  while(dLST<0.0)   dLST+=24.0;
  return TWO_PI/24.0*dLST;
}