Универсальная система управления телескопом на Arduino

[Iovch]

На форуме уже имеется несколько тем, посвященных системам управления монтировками, собранных на базе компонентов ардуино, в частности:

Простая система управления монтировкой на Arduino
Управление монтировкой на ШД Arduino + grbl
GOTO на Arduino практическая реализация "Импортозамещение"

   В результате изучения этих, и многих других источников, у меня сложилось четкое представление, как простейшим образом, на базе компонентов Ардуино можно решить некоторые вопросы, связанные с управлением телескопом.
   В настоящий момент собран действующий образец управляющего блока на базе Ардуино нано и драйверов А4988 для монтировки на шаговых двигателях с выходом для подключения электрофокусера, с индикацией координат наведения и прочей информации на двухстрочном LCD, с возможностью выполнения команд GOTO задаваемых с ПК, с возможностью подключения проводного устройства управления. Реализовано прямое подключение к плагину «управление телескопом» программы Stellarium. Разработано программное обеспечение для управления экваториальной и альт-азимутальной монтировками, масса тестовых программ. Собранная система управляет монтировкой из комплекта Деагостини «Собери свой телескоп» (аналог Astro-3, на фото), но система подойдет для управления любой монтировкой на шаговых двигателях. Пришло время собрать окончательный вариант изделия уже с беспроводным управлением. В процессе переборки системы, попытаюсь систематизировать и показать в этой теме, от простого к сложному, как простейшим образом, на Ардуино можно реализовать тот или иной функционал. Думаю, материал будет полезным.

Для удобства ориентирования в теме привожу здесь ссылки на основные моменты и программы:

Астротрекер или привод оси прямого восхождения, описание электронной части:
Универсальная система управления телескопом на Arduino
Астротрекер или привод оси прямого восхождения, скетч GOTO1 + драйвер ch341ser.zip:
Универсальная система управления телескопом на Arduino
Привод оси склонений и элемент управления (джойстик), ускорение перемещений, описание:
Универсальная система управления телескопом на Arduino
Привод оси склонений и элемент управления (джойстик), ускорение перемещений, скетч GOTO2:
Универсальная система управления телескопом на Arduino
Система управления экваториальной монтировкой с функциями GOTO, описание и скетч GOTO3:
Универсальная система управления телескопом на Arduino
Прикручиваем управление фокусером к джойстику
Универсальная система управления телескопом на Arduino
Подключаем LCD, описание электронной части:
Универсальная система управления телескопом на Arduino
Подключаем LCD, скетч GOTO4 + драйвер LCD 1602:
Универсальная система управления телескопом на Arduino
Скетч GOTO4 с автоопределением и автоюстировкой джойстика:
Универсальная система управления телескопом на Arduino
Пульт ИК часть 1 (Slave), описание электронной части:
Универсальная система управления телескопом на Arduino
Пульт ИК часть 1 (Slave), скетч GOTO5SLAVE, программа настройки и драйвер пульта ИК:
Универсальная система управления телескопом на Arduino
Пульт ИК часть 2 (Master), описание электронной части и скетч GOTO5MASTER:
Универсальная система управления телескопом на Arduino
Шаговый электрофокусер, описание электронной части:
Универсальная система управления телескопом на Arduino
Шаговый электрофокусер, скетч GOTO6MASTER.zip:
Универсальная система управления телескопом на Arduino
Версии GOTO6MASTER и GOTO6SLAVE для штатного ИК пульта ардуино:
Универсальная система управления телескопом на Arduino
Энергонезависимые часы реального времени:
Универсальная система управления телескопом на Arduino
Скетч для управления альт-азимутальной монтировкой GOTO7MASTER:
Универсальная система управления телескопом на Arduino

Ссылка на яндекс-диск со всеми материалами и стабильными версиями: https://yadi.sk/d/f1jTO1AohCtbz

[FlexLM]

Для Arduino в своём проекте вместо стандартного analogRead() я использую более быстрый analogReadFast() [код функции в спойлере].
Т.е. в функции InitControl() и AskControl() пишете analogReadFast(CX_SENCE) и т.п.

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

  // ВНИМАНИЕ! Нужное опорное установлено DEFAULT, можно изменить на своё
  unsigned int analogReadFast(byte pin)
  {
    pin=(( pin<8 )? pin:pin-14); //analogReadFastdFast(2) = analogReadFastdFast(A2)
    ADMUX=(DEFAULT<<6) | pin;  //set analog MUX & reference
    bitSet(ADCSRA,ADSC);       //start
    while (ADCSRA&(1<<ADSC));  //wait
    return ADC;                //return result
  }

[AndyNigmatec]

Большое спасибо!

Обязательно попробую, правда теперь не известно когда следущее небо будет, но общую работоспособность я и так увижу))

[AndyNigmatec]

На analogReadFast() подменил, скетч работает, скажется ли это как-нибудь на гидеже - не знаю )))

[FlexLM]

Здесь мы боремся за выигрыш в мкс. На данном этапе вы перешли к постепенной оптимизации кода скетча от Iovch.
Допустим, выполнялся analodRead() за 112мкс, а analodReadFast() - 68мкс-16мкс.
Аналогично можно оптимизировать digitalWrite()(с 3.5мкс до 0.5мкс), работая непосредственно с портами.
Пример для Arduino Nano:
digitalWrite(13, LOW) заменяете на bitClear(PORTB,13), т.е. где LOW используете bitClear()
В распиновке Arduino Nano пину 13 соответствует PB5, это порт PORTB.

digitalWrite(ENABLE_XYZ_PIN, HIGH) заменяете на bitSet(PORTB,ENABLE_XYZ_PIN), т.е. где HIGH используете bitSet()
Пояснение:
в Config.h (или CFGMyCG4.h): #define ENABLE_XYZ_PIN 8
В распиновке Arduino Nano пину 8 соответствует PB0, это порт PORTB.
Для ардуино мини смотрите свою распиновку: PB будет обозначать PORTB, PD = PORTD.

[AndyNigmatec]

у меня нано ... значит пользуюсь такой распиновкой?

[FlexLM]

Да. Серым обозначен ID пина, т.е. пины 8÷13 относятся к порту PORTB, а 2÷7 =  PORTD. На порт PORTC мы не обращаем внимание, т.к. для него используется analogRead()...
Ещё пример. В функции StepperTone() вместо digitalWrite(uDirPin,  HIGH) запишем bitSet(PORTD,uDirPin), т.к. в функцию передаются номера пинов 2÷4.

[AndyNigmatec]

Потестил по небу вариант с analogReadFast() и вызовом AskControl() раз в 5 циклов - все работает, и, кстати, мне пришлось в скетче увеличить параметр

double dVMSPSS = 69000000; //Виртуальных милисекунд в солнечных сутках = 86400000+lDMSS

до внесения изменений я его подгонял до звездной скорости и у меня стояло 68000000, т.е. похоже на то что монтировка стала вести чуть быстрее после внесения этих изменений, или иными словами предположение о том что ардуинко захлебывается получает косвенное подтверждение.

Может я и не прав, пишу как могу понять работу системы.

Сейчас внес еще корректировки в скетч: bitClear() и bitSet() вместо digitalWrite() - как будет возможность проверю и с этими изменениями.

Спасибо вам за помощь!

[FlexLM]

Продолжим облегчать жизнь Arduino...
По умолчанию в loop() постоянно выполняется проверка/чтение нашего виртуального COM-порта с помощью функции serialEventRun() (см. спойлер 1).

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

int main(void)
{
   init();

   initVariant();

#if defined(USBCON)
   USBDevice.attach();
#endif
   
   setup();
   
   for ( ;; ) {
      loop();
      if (serialEventRun) serialEventRun();
   }
       
   return 0;
}

Но в коде loop() от Iovch работу этой функции дублирует/расширяет Bytes=GetString(). Чтобы не ломать логику работы программы предлагаю создать пустой loop(), уже имеющийся loop() переименовать в loop1(). Затем вызов loop1() разместить в бесконечном цикле и дописать это дело в конце setup() (см. спойлер2). Пустой loop() теперь выполняться не будет, но он формально нужен.

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

void setup()
{
 код от Iovch

 //В конце этой функии дописываем
for ( ;; ) { loop1(); }
}

//Раньше это был просто loop()
void loop1() { код от Iovch, который был в цикле loop() }

//Создаем новый loop()
void loop() {}

[AndyNigmatec]

Не совсем понимаю что это дает ... получается наш пустой loop() теперь выполняться не будет, а будет выполняться тот же код что и раньше только в ручном цикле вызова loop1().
Единственно только раз уж из setup() мы не выйдем никогда, то наверное не будет выполняться выделенное вами:
if (serialEventRun) serialEventRun();

Это может немного разгрузить несчастное ардуинко?
 

[FlexLM]

Да, serialEventRun() выполняться не будет, но для универсальной системы он и не нужен. Подобный код уже есть в GetString(). В исходном коде от Iovch получается, что после loop() проверяется есть ли что-то в com-порте (но никак на это не реагируем), а потом переходим на начало цикла loop() и опять проверяем/считываем в GetString() из буфера данные в com-порте.

[AndyNigmatec]

Вчера кстати дали чутка неба (синг никакой, но для проверки хватило) - залил вариант с bitClear() и bitSet() вместо digitalWrite() - все работает!

Кстати, параметр - dVMSPSS - мне пришлось еще увеличить (с 69 000000 до 71 500 000) - т.к. стало вперед ведение убегать, т.е. в моем понимании предположение о перегруженности ардуины снова косвенно подтверждается, и заодно поставил скорость компорта 115200 - вроде стабильно все, полгода назад какие-то проблемы с этим помню были, сейчас не заметил.

Проверил также и гидирование - впервые увидел RMS 0.7-1.0" за минуту (ранее 1-1,5" было), был бы получше синг (а он был по индексам метеоблю 3 и 1) проверил бы нормально - а так звезды колбасило, и гидирование периодически "прыгало" на 2" и более, но тенденция мне нравится, тут надо поснимать в разные дни для статистики))

Сегодня если получится еще хочу ваше предложение с loop1() залить и посмотреть результат.

UPD. заметил еще одну особенность скетча - если на РП последняя нажатая кнопка была "вперед" по Ra - то скорость ведения норм, а вот если "назад" - то начинает оставать, делаешь ресет ардуины (или просто снова кнопу вперед) - скорость ведения опять становится норм - фиг знает что за фича )))

[AndyNigmatec]

Тут еще вот что мне подумалось:

Как я понимаю работу скетча в ардуинке: основной цикл loop() выполнятся по мере выполнения всех его команд, и соответственно частота его выполнения зависит от скорости выполнения этих команд (назовем это "загруженностью"), но не более 1,136 МГц.

Мысль у меня такая - а раз я по вашему совету от loop() ухожу и выполняю свой собственный цикл loop1() - то я могу наверное вызывать этот loop1() со строго определенной частотой заведомо меньшей упомянутой выше "загруженности".
Если я верно мыслю, то подскажите пожалуйста - как это правильно организовать?

пока приходит в голову только тупое:

Код: [Выделить]

  for ( ;; )
  {
    if(micros()-ulTimerWork>ulTimerWorkSet)
    {
      ulTimerWork=micros();
      loop1();
    }
  }
при ulTimerWorkSet=800 получается частота 1,25 кГц с погрешностью 0,5%

[AndyNigmatec]

Еще небольшой вопрос, могу я в этих двух процедурах также заменить analogRead() на analogReadFast() ?

Код: [Выделить]

void SetStDX(void) // Устанавливает направление шага Stepper_X_step(iStDX)в сторону увеличения X
{
 if(analogRead(DX_SW_PIN)>512) iStDX= 1; else iStDX=-1;
 if(iTMode==2) iStDX=-iStDX; // В экваториальном режиме Noth и в азимутальном, направления увеличения Х противоположны
 if(!bStDX)    iStDX=-iStDX; // Программный модификатор направления движения
}

void SetStDY(void)
{
 if(analogRead(DY_SW_PIN)>512) iStDY= 1; else iStDY=-1;
 if(!bStDY)    iStDY=-iStDY; // Программный модификатор направления движения
}

[FlexLM]

analogReadFast() можете использовать во всём скетче.
Искусственно занижать частоту loop1() я бы не стал. Скорее всего получите "тормознутую" реакцию работы системы управления. Например, нажмёте кнопку РП, а реакция не последует или будет заметно с опозданием.
Да, в цикле loop() команды выполняются последовательно в бесконечном цикле.
Вообще, вы находитесь на пределе быстродействия ардуино. Что-то можно ещё улучшить, конечно. В моём проекте даже используются прерывания для управления ШД. Но, например, при goto, когда работают оба ШД, по звуку слышна одна скорость. Если один из ШД перестаёт вращаться, то слышно, как второй начинает быстрее вращаться. Прерывания, ведь тоже в псевдопараллельном режиме выполняются. Если вы хотите решить вопрос с быстродействием, то надо переходить на ESP32! Поверьте, после этого перехода вы не захотите выполнять подобные задачи на ардуино
Убегание вперёд трубы - это хитрое влияние атмосферной рефракции. Можете в моей теме чуть подробнее почитать.

[AndyNigmatec]

Спасибо за информацию!

Переход на более производительный ESP32 заманчив конечно, но выглядит на первый взгляд проблематичным - это все нужно переделывать, и программный код и "железную" обвязку ...

Возможно подошел бы ваш вариант AMOUNT - но он как я понял для AltAz, EQ-режим там тестово, и еще не совсем ясно про гидирование и драйвер готового устройства под винду.

[AndyNigmatec]

Убегание вперёд трубы - это хитрое влияние атмосферной рефракции. Можете в моей теме чуть подробнее почитать.

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

[FlexLM]

А не может эта "фича" быть из-за backlash? Не зря же на заводских монти рекомендуют, чтобы последняя корректировка кнопками была в сторону ведения за объектом. Пока шестеренки не выберут люфт и происходит отставание.

[AndyNigmatec]

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

[FlexLM]

Пожалуй, проще всего перейти на Wemos D1R32 (форм-фактор uno) тем, кто построил систему на шилде v3 + arduino uno. Похоже, им достаточно заменить в коде Iovch  распиновку, взятую из моего проекта. Ну, может ещё что по мелочам вылезет.
Судя по тому, что после оптимизации кода вы увеличили продолжительность вирт. солнечных суток, чтобы монтировка перестала опережать объект, значит ардуина стала шустрее крутить код. Похоже, теперь вы в большей мере ощутили влияние атмосферной рефракции. Если будет возможность, обратите внимание, пожалуйста: для разной высоты объектов всегда ли монтировка движется практически за объектом или для более низких объектов начинает опережать?

[AndyNigmatec]

Сейчас тестово прицелился по ярким звездам примерно по одному азимуту и разной высоте над горизонтом - Вега (+31) и Денеб в Лебеде (+54) - смотрел в LiveView по минуте каждую в НИНе с прицелом - различий в ведении не заметил, обе чуть отставали (но это особенность моей колхозной конструкции - скорость ведения в разных положениях рычага гамона немного отличается, поэтому и выбрал примерно на одном азимуте).

UPD. небо ниже 30 в моей локации плохо доступно, а +31 наверное для вашего эксперимента высоковато ...