АРДУИНО ГоТу/Тракинг система за EQ1

[desko]

Здравейте,
Тръгнах да правя системка за намиране и следене на обекти от ардуино дуо. Вече съм понаправил логиката за LST, HA, базата данни със Месие, зареждане, графичния интерфейс на главния екран тъч скрийна.

Въпроса ми е дали някой се е пробвал и докъде е успявал?

В интернет няма много неща, или тези които са описани са доста неточни за Ардуино Уно.

[plamen panayotov]

Здравейте,
Аз се бях заиграл с малко по-опростена система. Станаха нещата, но при мен уклона беше да свържа монтировката с компютъра и съответно да имам обратна връзка за насочването.(дигитални градуирани пръстени , извинете за грубия превод). Тогав видях зор със сървъра Инди, чиято компилация не работеше добре под уин. Сега проблемите със сървъра са изчистени, намерих си и доста по-качествени енкодери, но нямам време в момента за проби.
Проверете тук - http://sourceforge.net/projects/eqtrack ... =directory или други подобни на същата страница.
Дано съм бил полезен. Оставам на линия.
Поздрави,
Пламен

[plamen panayotov]

Здравейте,
Аз се бях заиграл с малко по-опростена система. Станаха нещата, но при мен уклона беше да свържа монтировката с компютъра и съответно да имам обратна връзка за насочването.(дигитални градуирани пръстени , извинете за грубия превод). Тогав видях зор със сървъра Инди, чиято компилация не работеше добре под уин. Сега проблемите със сървъра са изчистени, намерих си и доста по-качествени енкодери, но нямам време в момента за проби.
Проверете тук - http://sourceforge.net/projects/eqtrack ... =directory или други подобни на същата страница.
Дано съм бил полезен. Оставам на линия.
Поздрави,
Пламен

[desko]

Здравей Пламен,

Благодаря за линк-а, наистина оценявам помощта. Познавам сайта и съм търсил и преди там, но за съжаление нищо конкретно не намерих.... или това което намерих беше трудно приложимо в моя случай.

Скоро ще мога да кача снимки и филмче на системката.

[desko]

Здравейте,

Малко ъпдейт за системата:
- Самостоятелен Часовник с грешка 10 сек. годишно - ГОТОВО;
- Възможност за промяна на Дата и Час, Лятно и Зимно време - ГОТОВО;
- База Данни с МЕСИЕ и четене от нея - ГОТОВО;
- Изчисление на LST (точост до 5 знак) - ГОТОВО;
- Изчисление на HA (да се поправи точността - отклонение до 20 сек) - ГОТОВО;
- Графичен интерфейс + Тъч - ГОТОВО;
- Следене на Температура и Влажност - ГОТОВО;

Какво ми остава:
- Да оправя изчисленията на HA - сега имам проблем - малко бяга;
- Да пренапиша четенето на Базата Данни за да могат да се вкарват и други файлове - например План на Наблюдението който се изготвя предварително;
- Да Направя управлението на моторите (не е сложно, но си има писане);
- Да направя Тракинг-а (в момента работи само Celestial);
- Да опитам да направя АУТОГАЙДЕР - има информация, че не става, но пък имам идея която може да сработи и да имам Гайдинг без компютър);
- Дневен/Нощен режим - сега работи само нощен;

Размишления:
- Май няма да стане с EQ1! Трябва ми монтировка с лагери - най-малко EQ2 на която да сложа лагери;

Цена: ~150 USD (270 лв.)
- Ардуино-то: $ 33.00;
- Touch Screen + SD: $ 29.85;
- DHT22 (температура): $ 1.5;
- RTC (часовник): $ 2.54;
- Двигатели + датчици (x2): ~ $45.00
- Акумулаторче - ~ $ 30;

Малко снимки и филмче:

[youtube]UiPFnZDVafc[/youtube]

EXIF-Data show/hide

Original image recording time:

2015:04:07 21:31:06

Image taken on:

вт апр 07, 2015 18:31

Shutter speed:

1/9.9417413954228 Sec

F-number:

f/2

ISO speed rating:

800

Whitebalance:

Auto

Flash:

Flash did not fire, compulsory flash mode

Camera-manufacturer:

Nokia

Camera-model:

Lumia 920

Exposure bias:

0 EV

Metering mode:

Average

Coordinates:

N 42 39 28.045/ E 23 23 56.905

Google Maps:

Click here to open map

EXIF-Data show/hide

Original image recording time:

2015:04:07 21:30:47

Image taken on:

вт апр 07, 2015 18:30

Shutter speed:

1/24.997500249975 Sec

F-number:

f/2

ISO speed rating:

400

Whitebalance:

Auto

Flash:

Flash did not fire, compulsory flash mode

Camera-manufacturer:

Nokia

Camera-model:

Lumia 920

Exposure bias:

0 EV

Metering mode:

Average

Coordinates:

N 42 39 28.045/ E 23 23 56.905

Google Maps:

Click here to open map

EXIF-Data show/hide

Original image recording time:

2015:04:07 21:30:58

Image taken on:

вт апр 07, 2015 18:30

Shutter speed:

1/11.07873658088 Sec

F-number:

f/2

ISO speed rating:

800

Whitebalance:

Auto

Flash:

Flash did not fire, compulsory flash mode

Camera-manufacturer:

Nokia

Camera-model:

Lumia 920

Exposure bias:

0 EV

Metering mode:

Average

Coordinates:

N 42 39 28.045/ E 23 23 56.905

Google Maps:

Click here to open map

[Yoddha]

Респект!

[bobo]

Понеже аз нищо не отбирам от електроника и програмиране много се впечатлявам от такива неща

[tishovsx]

Браво!!!
Аз съм първия ти клиент за една бройка.

[desko]

Благодаря за коментарите. Карат ме да се чувствам страхотно
Забавен начин да практикуваш астрономия през cloudy nights.

[NNN]

Здравей колега . Аз съм се замислил върху това

[grozmaistor]

Аз снощи тествах GoTo-то, което си сглобих по проекта на Кевин Фераре. Роботи отлично и при сносно съосие на монтировката със земната ос, обектите са винаги в центъра на полето. Това е като се ползват "заводските" мотори за EQ4-5 монтировка. Единственият засега недостатък е че моторите са бавни, макс x8 спрямо стандартното въртене на Земята. От лоптопа софтуерът за управление е Cartes du Ciel/Sky charts под Windows (за съжаление). Все още чакаме indi driver(за Linux) за връзка между ардуиното и софтуера.

Следващият проект ще е като този на brymchik - OnStep GoTo. Той го е направил и му се е получило по-добре от купешките.

Изпратено от моят GT-I8190

[grozmaistor]

Здравей Деско, да попитам дали работиш още по този проект? Дисплеят с touchscreen 3.2 инчов ли е и с каква резолюция?

Sent from my GT-N7000 using Tapatalk

[desko]

Здравейте,

Миналата седмица "размразих" проекта - някой знаят, че правих къща и трябваше да си отделя там времето.

От миналата седмица накупих стъпкови двигатели и драйвери за да мога да направя управлението защото прецених че няма да се справя с ДЦ моторите (оригиналните).
Екрана е 240/400 и е 3.2.

Надявам се да мога да пусна скоро ново филмче с прогреса, защото преди да го "замразя" успях да добавя още доста интересни нещица в софтуерчето.

[BoByS]

Много е готино!
Имай впредвид следните неща (чисто механически):
1. Стъпковите мотори имат главен недостатък - много лошо съотношение тегло/момент. Но за сметка на това са евтини, управляват се лесно (особено с Ардуино) и могат прецизно да се закарат до определена позиция без наличието на енкодер.
2. DC моторите са по-скъпи, защото задължително им трябва енкодер, за да ги закараш до определено положение. Другият вариант е да се управляват по време, но е безумно неточно. За 125$ може да се намери сносен мотор с енкодер 0.1-0.6 Nm. За сравнение, стъпков мотор с 0.6 Nm е около 20-30$.

За съжаление живея в чужбина, иначе бих ти подарил 2 стъпкови мотора 0.6Nm, които лежат резерва от самоделния ми 3D принтер - тук ако ти трябва нещо за прототипиране, пиши Л.С., ще ти го принтирам и пратя по пощата.
Ако ти трябва помощ с механиката - казвай, няма проблем.
Поздрави!

[desko]

Много е готино!
Имай впредвид следните неща (чисто механически):
1. Стъпковите мотори имат главен недостатък - много лошо съотношение тегло/момент. Но за сметка на това са евтини, управляват се лесно (особено с Ардуино) и могат прецизно да се закарат до определена позиция без наличието на енкодер.
2. DC моторите са по-скъпи, защото задължително им трябва енкодер, за да ги закараш до определено положение. Другият вариант е да се управляват по време, но е безумно неточно. За 125$ може да се намери сносен мотор с енкодер 0.1-0.6 Nm. За сравнение, стъпков мотор с 0.6 Nm е около 20-30$.

За съжаление живея в чужбина, иначе бих ти подарил 2 стъпкови мотора 0.6Nm, които лежат резерва от самоделния ми 3D принтер - тук ако ти трябва нещо за прототипиране, пиши Л.С., ще ти го принтирам и пратя по пощата.
Ако ти трябва помощ с механиката - казвай, няма проблем.
Поздрави!

Имам оригиналните мотори - японски с енкодери, но понеже ми е трудно да ги управлявам, ги смених със стъпкови 200 стъпки 4,4 кг/см. Сега пиша управлението за тях, но повече ме затрудняват прекъсванията на Ардуиното.... нещо не "щракват" както трябва и пропускат такт. Пуснал съм ги на 25Hz, но Ардуиното ли, моторите ли нещо не смогват да постигнат тази скорост.

[BoByS]

Привет!
За стъпкови мотори, най-добре е да имаш някакъв драйвер, с който да ги "караш". ULN2004 е добра възможност при униполярен режим на работа (нямам опит при този режим). Лично аз, ги управлявам в биполярен режим, с някакъв драйвер - A4988 (max 2A) или DRV8825 (max 2.5A) - като те позволяват и микростепинг (тук имай впредвид, че микростепинга пропорционално намалява момента), което никак не е лошо при по-точно позициониране. Имат и настройка на входното напрежение към драйвера, което се подбира така, че да не греят при работа моторите, но лично при моите 0.44 Nm (4.4 kg/cm) ги пържа на почти 2 Ампера и никога не съм забелязвал да греят, а ги ползвам доста. Пропускат ти стъпки при товар или на празен ход - т.е. вързал си ги вече към платформата и пропускат стъпки или просто ги тестваш на въртене? Най-добрият вариант за мен е ако ардуиното и моторите имат различни захранвания - обикновено ако не искаш да ползваш втори източник (което е напълно разбираемо при този проект), най-добре е да се върже през т.нар. шийлд - де-факто елементарна платка със стабилизатор на напрежението, който да може да подава 12V на моторите (V на захранването) и 5V на ардуиното.
П.С. Силно препоръчвам използването на биполярен режим на работа, моторите нагласени по определен начин (много зависи от типа на мотора, ако се спреш на този вариант - мога да ти предоставя програмка, която съм направил на Ексел за целта), за да не греят, DRV8825 драйвери и 12V захранване - това е режимът, който ползвам от години и мога да гарантирам, че работи и ще ти свърши работа (тук автоматично считам, че моторите са достатъчни за съответната работа, т.е. моментът им е достатъчен, за да въртят платформата).
Поздрави!

[desko]

Здравей BoByS,

Всичко което описваш по-горе е абсолютно правилно... т.е. и аз достигнах до същите изводи
Ползвам DRV8825 в момента с отделни захранвания, но след време ще е едно от което ще се дели за Ардуиното и за моторите.

Имам проблеми с "прекъсванията" на Ардуиното... в момента са без товар, само се опитвам да ги управлявам. Искам да направя тракинг-а, а отиването на позиция е лесно защото имам готов кода който изчислява броя стъпки. Тракинг-а разчита на времето, и когато правя прекъсванията, нещо не работи както трябва самото Ардуино.... или изходите може би не могат да се "палят-гасят" толкова бързо.

[Nazarov]

Имам проблеми с "прекъсванията" на Ардуиното... в момента са без товар, само се опитвам да ги управлявам. Искам да направя тракинг-а, а отиването на позиция е лесно защото имам готов кода който изчислява броя стъпки. Тракинг-а разчита на времето, и когато правя прекъсванията, нещо не работи както трябва самото Ардуино....

Струва ми се, че това не е най-удачният подход за реализация на тракинг с Ардуино. Ардуиното е направено така, че непрекъснато "цикли" потребителския код, при което обаче, имаме глобални променливи, които се запазват между циклите. Аз съм реализирал следния алгоритъм, който работи със субпикселна точност:

1. Запаметявам началното време на тракинга Т1 (в милисекунди). Може да се работи и в наносекунди, но за целите на тракинга е излишно.
2. Запаметявам началните ъглови позиции на системата.
3.1. При всяко завъртане на цикъла изчислявам разликата между началното и текущото време и от там, изчислявам тригонометрията за нужните ъглови позиции към текущия момент. В сметките отчитам коефициент на температурно разширение на конструктивните елементи на системата спрямо показанието на температурен датчик.
3.2. Изчислявам разликата между текущите и необходимите ъглови координати на системата в брой моторни стъпки.
3.3. Ако разликата е по-голяма от половин стъпка, подавам съответната команда към моторите. Ако не, изпълнението на цикъла приключва и се завърта следващия цикъл (3.1.) Така кодът работи еднакво добре независимо от скоростта на хардуера.
3.4. Проверявам чрез магнитен енкодер дали моторите са изпълнили правилно командите и, при необходимост, коригирам грешки. (При правилно оразмеряване на системата грешки не се случват.)
3.5. Запаметявам новите ъглови позиции като текущи и се завърта следващ цикъл (3.1.)

Оразмерявам кинематиката на системата по такъв начин, че са необходими повече от 2 моторни стъпки, за да бъде отместването оптически видимо за снимащата матрица. Това разбира се е функция от фокусното разстояние на оптиката, което в моя случай е 1000 мм. В крайна сметка ми се получават повече от 30 стъпки в секунда за компенсиране въртенето на Земята. Кинематичната схема е екваториална маса. Използвам 32-битови процесори, при които "Double" типът е 64-битов, което е необходимо за постигане на нужната точност при тригонометрията.

[ymn]

Нямам опит с Ардуино. Доколкото знам платформата е на Атмел микроконтролери. Като всеки микроконтролер и те трябва да имат прекъсвания и вградени таймери. Та питам не е ли по-добре тракинга да е на високоприоритено прекъсване активирано от таймер ? Преварително се изчислява необходимото време между две стъпки примерно в милисекунди, това време се коригира според латентността на системата и после се инициализира таймера. Той пък генерира серия от прекъсвания на точните моменти. Така без значение с какво в момента е зает процесора, той ще спре, ще направи стъпка и после ще си продължи другата задача.

[desko]

Нямам опит с Ардуино. Доколкото знам платформата е на Атмел микроконтролери. Като всеки микроконтролер и те трябва да имат прекъсвания и вградени таймери. Та питам не е ли по-добре тракинга да е на високоприоритено прекъсване активирано от таймер ? Преварително се изчислява необходимото време между две стъпки примерно в милисекунди, това време се коригира според латентността на системата и после се инициализира таймера. Той пък генерира серия от прекъсвания на точните моменти. Така без значение с какво в момента е зает процесора, той ще спре, ще направи стъпка и после ще си продължи другата задача.

Това беше и моето решение, но нещо не се държи както трябва прекъсването. Губи цикъл(и) когато е закачен на мотора, а когато се тества без мотори, си върви идеално.


Nazarov: Човек, докато четях се осетих че разбирам само половината от това което си написал Можеш ли да го обясниш като на "стрител" с Лего .

[Nazarov]

По просто казано, идеята е, че имаш една процедура, която непрекъснато се изпълнява отново и отново от Ардуиното. В зависимост от скоростта на хардуера и тежестта на процедурата, може да се изпълнява стотици пъти в секунда. Нас не ни интересува точно колко пъти в секунда ще се изпълни процедурата, защото всичко над 30-40 пъти в секунда ни задоволява. При всяко изпълнение, процедурата изчислява с висока точност дали е настъпил моментът да се направи следваща стъпка на мотора. Ако да, правим стъпката, а ако не, нищо не правим и процедурата се завърта отново. Така, процедурата се изпълнява много пъти в секунда и в отделни (правилните) моменти подава команда за следваща стъпка към мотора. Понеже фактът, че моторът е стъпков, дискретизира много точно възможните механични състояния на системата, максималната грешка, която може да се получи от флуктуация във времето е половин моторна стъпка. Това е така също и поради причината, че стъпковите двигатели не натрупват периодична грешка във времето. Следователно достатъчно е да оразмерим кинематиката на системата така, че най-малката оптически видима грешка за снимащата матрица да бъде >= на 1 моторна стъпка и постигаме субпикселна точност на воденето. Това е по отношение на управлението на мотора и Ардуиното. Отделно от това механиката може да има или да няма периодична грешка, но ако тя може да бъде измерена, може да бъде и компенсирана математически при управлението на мотора с Ардуиното.

Сигурно пак не е много ясно обяснението, но питай по-конкретно.

[desko]

Напротив... абсолютно ясно е вече Благодаря.
Лично аз се притеснявам да се правят проверки на всеки цикъл на ардуиното. По-чистия вариант е с прекъсвания, от часовника на ардуиното.
В моя случай мога да определя прекъсванията с точност до микросекунда.

Това което ме притеснява, е че Ардуиното в момента смята сложни неща в паралел - Превръща координати в Часови ъгъл, мери температури, управлява екрана, тъч скрийна и т.н. И в момента е претоварено и циклите му са нещо от рода на 20 Hz. Поради тази причина искам да "изкарам" управлението на мотора на хардуерно прекъсване, а основния код колкото и да се забави... дори да стане 2-5 Hz, пак ще е достатъчно за да работи системата. На двигателите обаче няма да им е достатъчно

Разбирам какво ми предлагаш и ако беше само Тракинг-а, определено така щях да подходя!

[Nazarov]

Работата е там, че хардуерните прекъсвания на Ардуино контролерите не са хардуерни, а се емулират програмно от фърмуера. И както ти сам си установил експериментално, при високо натоварване прекъсванията стават доста неточни и хаотични. Ако правилно съм разбрал, че цикълът ти се изпълнява около 20 пъти в секунда, значи хардуера не е достатъчно производителен за работата, с която го товариш. Дори при това положение, ако се откажеш от прекъсванията и оптимизираш основната процедура да се изпълнява по-кратко и по-на често, пак ще постигнеш по-добра точност.

[ymn]

при високо натоварване прекъсванията стават доста неточни и хаотични. Ако правилно съм разбрал, че цикълът ти се изпълнява около 20 пъти в секунда, значи хардуера не е достатъчно производителен за работата, с която го товариш. Дори при това положение, ако се откажеш от прекъсванията и оптимизираш основната процедура да се изпълнява по-кратко и по-на често, пак ще постигнеш по-добра точност.

Все пак си мисля, че за тракинга използването на прекъсване е правилния подход. Няма друг начин процесора да прави нещо в реално време, на точно определени интервали време заедно с други процеси. Но ако хардуерните прекъсвания не са точно хардуерни както пише Nazarov, то излиза, че тоя микроконтролер въобще не е предназначен за реални процеси. Не го вярвам.
desko би ли обяснил по-подробно какво значи

Губи цикъл(и) когато е закачен на мотора, а когато се тества без мотори, си върви идеално.

Това аз го разбирам като проблем в драйвера или мотора, а не в Ардуино-то. Ползваш STEP и DIR на драйвера, това ясно. Но какво правиш с RESET, ENABLE, MODEn, SLEEP ?

[desko]

Все пак си мисля, че за тракинга използването на прекъсване е правилния подход. Няма друг начин процесора да прави нещо в реално време, на точно определени интервали време заедно с други процеси. Но ако хардуерните прекъсвания не са точно хардуерни както пише Nazarov, то излиза, че тоя микроконтролер въобще не е предназначен за реални процеси. Не го вярвам.
desko би ли обяснил по-подробно какво значи


Това аз го разбирам като проблем в драйвера или мотора, а не в Ардуино-то. Ползваш STEP и DIR на драйвера, това ясно. Но какво правиш с RESET, ENABLE, MODEn, SLEEP ?

Аз не разбирам защо прекъсванията не са хардуерни. Не знаех че има и не хардуерни.
Може би Nazarov има предвид, че не са от външен брояч/часовник защото Ардуиното може да работи с 2 типа прекъсвания - 1) Собствения часовник, 2) външен сигнал.
По мое мнение прекъсванията на Ардуиното трябва да са достатъчно точни - разчитата на часовника на ардуиното който в моя случай е 84MHz, и аз го деля както ми трябва и го ползвам.


Ъпдейт: Колкото до прекъсванията и моторите - Готово! Вече управлявам моторите с прекъсвания точно както са ми нужни. Сега само трябва да направя замерванията за да съм сигурен, че двигателя не губи стъпки/точност по време. Скоро ще пусна ново филмче за GoTo системата "rDUINO SCOPE"

[BoByS]

Здрасти пак!
Поздравления за проекта! Принципно, когато използвам някакви сензори, харесвам да ползвам Real time clock (часовник в реално време) модул. Не съм от най-добрите софтуеристи и ми е доста трудно да ползвам вградените функции на, в случая, Ардуиното.
Радвам се, че си изгладил пречките, но обикновено е така в проектите - сблъскваш се с пречки и намираш начин да ги разрешаваш. Впечатлен съм от познанията ти по програмиране. Следя с интерес!
Поздрави!

[Insomniac]

3.1. При всяко завъртане на цикъла изчислявам разликата между началното и текущото време и от там, изчислявам тригонометрията за нужните ъглови позиции към текущия момент. В сметките отчитам коефициент на температурно разширение на конструктивните елементи на системата спрямо показанието на температурен датчик.]

Е кажи честно... Това експериментално ли го определи или по разни таблици? Другото всякак мога да си го представя, ама тази част ми идва в повече Ако е експериментално - отчита ли се в коя част на небето си, съответно рефракцията там и огъването на тръбата (отделно от разширението)?

Калкулирал ли си с колко точно се забавя изпълнението на една итерация на цикъла, ако трябва да направи преместване, както и, ако е достатъчно дълго, вкарано ли е в сметките между начално и текущо време (Тсега - Tстарт + Т итерация).

Професионална деформация ми е да търся евентуални проблеми в кода и това си набелязвам като източници на такива

[Nazarov]

Е кажи честно... Това експериментално ли го определи или по разни таблици? Другото всякак мога да си го представя, ама тази част ми идва в повече Ако е експериментално - отчита ли се в коя част на небето си, съответно рефракцията там и огъването на тръбата (отделно от разширението)?

Ами честно, не съм сигурен какво точно ме питаш. Ако е за температурното разширение, конструкцията (екваториална маса) е от плексиглас и стоманен винт. И двата материала имат известен коефициент на температурно разширение и формули, по които се изчисляват измененията. Тоест, температурното разширение не го измервам експериментално, а го изчислявам по паспортни данни на материала. И понеже изчислявам на колко оборота трябва да се завърти винта, за да отвори рамената на масата на определен ъгъл, и дължините в триъгълника са ми от порядъка на 25-30 см, и фокусното ми е 1000 мм, грешката от температурното разширение на конструкцията се натрупва с времето и много бързо става осезаема, ако не се компенсира. От това, което питаш за участъци от небето и огъване на тръба, стигам до извода, че си мислиш за деформация на дълга тръба която се мандахерца в различни посоки. Моят случай не е такъв. Имам МТО 1000 и правя екваториална маса за дълги експонации. Плексигласов детайл с дължина 260 мм. променя дължината си с около 0.6 мм. при промяна на температурата от 25 градуса.

Калкулирал ли си с колко точно се забавя изпълнението на една итерация на цикъла, ако трябва да направи преместване, както и, ако е достатъчно дълго, вкарано ли е в сметките между начално и текущо време (Тсега - Tстарт + Т итерация).

Времето необходимо за изпълнение на една стъпка е няколко микросекунди. Тоест, 5-10 микросекунди е минимално необходимата продължителност на импулса, който трябва да се подаде към контролера на мотора. Това е по паспортни данни на конкретния контролер. Аз съм го фиксирал на 50 микросекунди и да, вкарано е в сметките, макар и да не е толкова критично важно в конкретния случай. При мен един цикъл се изпълнява за по-малко от милисекунда. Тоест, цикълът се върти хиляди пъти в секунда, от които само в тридесетина цикъла се пада да извършвам стъпка. Системата маса-обектив осцилира дискретно около идеалната равновесна точка с амплитуда <= 1 моторна стъпка, което като грешка е <= половин моторна стъпка. Тоест, дали ще се забави стъпката с един цикъл повече или по-малко, оказва пренебрежимо влияние от порядъка на 1/40 част от моторна стъпка. А кинематиката е проектирана така (на теория), че всякакво отклонение под 2 моторни стъпки трябва да е оптически невидимо за снимащата матрица.

[Insomniac]

Мноо яко

[BoByS]

Здравейте отново!
Реших, че вбъдеще би ми било полезно да направя подобен опит и аз, въпреки недостатъчните ми (поне така мисля де) познания по програмиране на Ардуиното, но имам почти всички елементи и мога да си позволя да направя една платка, за да тествам. Тук веднага ми изплува въпросът дали Нано-то би имало достатъчно входове-изходи за подобна система. Малко е и може да се помести на монтажна платка, на която да се поместят драйверите за стъпкови мотори, нано-то, стабилизаторите на напрежение и т.н.
Към този момент ми трябва механика, а и това е нещото, което мога да изработя достатъчно бързо и без особени главоболия. Технологията ми позволява (поне към този момент) единствено 3Д принтирани детайли, затова нагаждам конструкцията според нея. Целта е да се направи актуатор, който да може да се маха и монтира когато е угодно. Към този момент разполагам само с "дърво" на движещите се части. Остават ми 2-те части на корпуса, който ще държи въпросното "дърво" за монтировката на телескопа. Имайте впредвид, че към този момент нагласям нещата спрямо моя 10'' Добсън - бях преровил интернет да видя как изглежда разглобена задвижка на GoTo платформата за SkyWatcher (беше близо 3 пъти по-скъпа от самия телескоп). Според набързо направените изчисления, моментът на мотора би бил достатъчен за завъртане на телескопа, ако смятам правилно (моля да ме поправите, ако греша) - необходимо е да се преодолее единствено силата на триене, породена от валовете и лагерите на тръбата, защото системата е уравновесена. Тъй като нямам спирачка на моторите, ще е добре да се оразмери с възможно най-голяма разлика, за да не изпускат стъпки, когато тръбата не се върти. Имам мотор за тестване, затова ще ползвам него... Ако е недостатъчен, ще го сменя с по-голям (NEMA23 - 1.5 Nm по спомен).

Параметрите засега са следните:
1. Стъпков мотор NEMA17 с максимален момент 0.6Nm (60 Ncm); 200 ст/об; 1 стъпка = 1.8 градуса. 1/2 или 1/8 микростепинг на мотора.
2. HTD-3M ремъчна шайба с 16 зъба, монтирана на мотора.
3. HTD-3M ремъчна шайба с 48 зъба, монтирана за болт М8. (Предавателно отношение 1:3)
4. Безкраен ремък HTD, 9мм широчина - подсилен с метални влакна.
5. Олдхамов съединител с гумена вложка (максимум 6Nm), с който лесно ще се маха и слага на всякакъв вид монтировки. Въз основа на него може да се подбере и входния вал към системата (този, който е монтиран за монтировката на телескопа - 6,8,10 мм и т.н.).
6. Система за обратна връзка на крайните положения (ще има възможност да се настройват фино положенията), представляваща елементарна гърбица, закрепена за голямата ремъчна шайба.

Със сигурност за теста ще трябва да се направи изцяло нова поставка за телескопа.
Поздрави!