Schrittmotor auch als Encoder verwendbar?

Status
Es sind keine weiteren Antworten möglich.

joetaiga

Aktives Mitglied
Hallo zusammen,

ich bin gerade an der Planung meinen Dobson mit AltAz Antrieb auszustatten. Ziel ist es den Dobson auf den Polarstern auszurichten, dort die Steuerung auf den Himmelspol zu resetten und danach mit Encodern und Arduino die Position zu protokollieren, sodass der Arduino die genaue Nachführgeschwindigkeit für die Schrittmotoren in beiden Achsen berechnen und an die Motoren weiter geben kann.

Dafür bräuchte ich je einen Encoder und Schrittmotor in beiden Achsen. Theoretisch müsste ein Schrittmotor aber doch auch als Encoder verwendet werden können, insofern man es schafft den Arduino die Schrittzahl protokollieren zu lassen. Damit könnte man auf die Encoder verzichten und ich hätte an meinem Arduino Uno etwas mehr Reserven an der 5V Versorgung und den Pins. Mit Motoren, Encodern, der IR Fernbedingung und einem einfachen I2C Display ist der Arduino fast komplett voll.

Wie ist eure Erfahrung? Funktioniert das? Ich kann dem Motor dann ja keine konstante Geschwindigkeit übergeben, da ich sonst die Schrittzahl nicht bestimmen kann. Ich müsste die Motoren über die Loop Funktion immer eine feste Schrittzahl fahren lassen. Gibt es passende Libraries, die das Problem umgehen? Wie sieht es mit Schrittverlusten und Backlash aus?

Danke und Grüße,
Joachim
 
Hallo Joachim,
im Prinzip verlassen sich ja die Montierungen, die mit Schrittmotoren betrieben werden und keine zusätzlichen Encoder verwenden ja darauf, dass die Pulse die der Motorcontroller bekommt, auch vom Motor ausgeführt werden. Allerdings ist üblicherweise die Auflösung eines Schrittmotors nicht sehr hoch (z.B. 1.8° pro Schritt), so dass man ein paar Tricks anwendet, um kleinere Schrittweiten zu ermöglichen. Problematisch wird das halt, wenn der Motor bei zu hohem Drehmoment Schritte verliert. Das zu detektieren ist nicht ganz trivial. Einige Treiberbausteine von Trinamic können das so einigermaßen gut über die Messung der Gegen-EMK. Aber grundsätzlich funktioniert das mit dem Schritte zählen so.
Zur Programmierung:
Du musst einmal berechnen, wie viele Schritte für einen bestimmten Winkel in Azimut bzw. Elevation erforderlich sind (ggf. kommt ja auch noch ein Getriebe dazwischen). Bei einer Alt-Az Montierung hast Du ja keine konstante Geschwindigkeit der Achsen. Beim Tracking würde in einer Schleife kontinuierlich berechnen, um welchen Winkel Azimut und Elevation zum jeweiligen Zeitpunkt verfahren werden müssen, damit die Position am Himmel erreicht wird und dem Motorcontroller diese Anzahl von Pulsen senden. Ohne Encoder kann man sich dann eben nur darauf verlassen, dass diese Schritte auch ausgeführt werden.

Ich würde mir an Deiner Stelle mal die Controller von Trinamic anschauen. Die haben interessante Teile.
Gruß
André
 
Hi Joachim,

also ich hab die Erfahrung gemacht das meine Stepper trotz Untersetzung 300 /1 noch zu grobmotorisch sind, deswegen hab ich mir die Treiber drv8825 und a4988 zugelegt um die Microsteps zu nutzen ( 32 & 16 ) , das wird sicher meine Auflösung nach vorne bringen aber ich wüste nicht wie ich zwei Spulen eins Motores auslesen sollte wenn diese gar mit Haltestrom beaufschlagt sind und dann auch schon gar nicht im zustand eines Microsteps.

Würde ich das ganze nochmal bauen wollen dann würde ich auf Bürstenmotoren setzen und den Achsen einen hochauflösenden Encoder Spendieren., aber mach mal wie du denkst vielleicht profitiere ich ja auch noch davon.

Seit dem ich aber mit der Spiegelschleifmaschine zu Gange bin hab ich keinen Handschlag mehr an meiner Steuerung gemacht, das werde ich später nachholen. wenn du bei den Steppern bleibst dann lege sie so aus das sie wesentlich mehr Power haben als benötigt und verlass dich drauf das es keine Schrittverluste gibt.. der blanke Rest ist Rechen Arbeit des Adruinos.

Hier ein kleiner Einblick in meinen Aufbau allerdings noch mit Steuerung die nur Vollschritte kann.

SAM_5466.JPGSAM_5471.JPG

Zahnrad Stepper 16 zu Zahnrad 160 Zähnen ( 10 zu 1 ) , das Riem Rad auf der Zahnradachse hat 10 mm durchbesser zur Sichel 300 mm Durchmesser ( 30 zu 1 ).

Abgesehen davon das die Stepper ein Haufen lärm machen sowie halte Strom benötigen wärst du mit einem Schneckengetriebe das sich selbst hemmt und einem Encoder der sagt Hallo ich bin auf Position so das die Steuerung den Saft zum Motor kappt meines Erachtens bei so einem selbst bau Projekt besser dran.

Gruß

Werner
 
Hallo Andre und Werner,

danke für eure Antworten. das hört sich eher so an als ob man auf der sicheren Seite ist, wenn man zusätzlich zu den Motoren noch Encoder verwendet.

Zu den anderen Problemen...die Trinamic Treiber arbeiten intern wohl generell mit 256 Microsteps und liefern damit praktisch eine mehr oder weniger homogene Sinuskurve. Der Treiber selbst kann nur bis 1/16fach ansteuern. Da aber soweit ich das verstanden habe, der Motor unabhängig von der über den Treiber eingestellten Unterteilung intern sowieso mit 1/256stel Steps arbeitet, müsste er trotzdem sauber genug laufen. Daher will ich als Treiber einen TMC2208 verwenden. Probieren werde ich das erst mal an meiner EQ Plattform. Wenn es da rund läuft, sollte es auch für einen AltAz Antrieb reichen. Verwenden will ich NEMA 17 Motoren. Die kann ich über 12V noch gut ansteuern. Der, den ich hier habe, hat einen Nennstrom von 0,4A und kommt damit auf 4,8W. Für meine EQ Plattform reichen sogar 1W am EQ2 Motor. D.h. wegen Drehmoment mache ich mir weniger Sorgen bei der großen Untersetzung.

Die Trinamic Treiber lösen auch gleich das Problem mit der Lautstärke. Durch die kleinen Unterschritte wird die Lautstärke der Motoren offenbar deutlich reduziert. Kann man alles hier nachlesen:

Ist eine deutsche Firma, produziert wird in DE und EU. Das ist dann auch noch sowas, wo ich gerne unterstütze. Abgesehen davon ist es eh die beste Lösung, die ich gefunden habe.

Die Untersetzung ist damit also nicht mehr das Problem. Allerdings müssen die Motoren halt entsprechend gut auflösen. 400 Steps ohne Untersetzung sollten es schon sein. In meinem Fall werde ich die Lager über Zahnriemen antreiben. Eine Umdrehung in Alt entspricht ca. 4° Verstellweg am Dobson, in Az sind es 6°. Ohne Untersetzung ist ein Step dann aber immer noch 36" bzw 48". Das ist noch viel zu viel. Mit den internen 1/256 Steps komme ich auf ca. 0,14" bzw. 0,19". Das ist schon unter der Auflösung meines 12"ers, aber meiner Meinung läuft das immer noch ziemlich rau. Das wird ja nicht alles komplett homogen sein und gerade in Dec muss ich mit der Geschwindigkeit nochmal deutlich runter. Ich hätte da schon gerne mindestens meine 30 Steps pro Sekunde, damit für das Auge ein flüssiges Bild entsteht. Mit der Kamera brauche ich eher noch mehr. Oder eben eine Auflösung, wo das definitiv nicht mehr stört. Von daher plane ich noch einen Motor mit Getriebeuntersetzung zu nehmen. Ich habe jetzt mal einen mit 1:27 Planetengetriebe hier. Ob das übertrieben ist und ich dann Probleme mit der Geschwindigkeit bekommen kann, werde ich ausprobieren müssen. Für den AltAz Antrieb müssten 1:5 eigentlich reichen, wenn der Treiber das hergibt, was drauf steht. 1:10 wäre wohl ideal. Gegen Süden habe ich in Az mit 30 Steps pro Sekunde eine Auflösung von 0,5". Das reicht also alles locker. Soweit die Theorie. Mit DC Motoren habe ich schon gearbeitet, mit Steppermotoren habe ich aber noch keine praktische Erfahrung.

Versuch macht kluch, wie es so schön heißt ;) Hoffentlich geht das auch so, wie ich mir das vorgestellt habe. Wenigstens kann man da keine größeren Beträge in den Sand setzen...

Grüße
Joachim
 
Hallo Andre und Werner,

danke für eure Antworten. das hört sich eher so an als ob man auf der sicheren Seite ist, wenn man zusätzlich zu den Motoren noch Encoder verwendet.

Zu den anderen Problemen...die Trinamic Treiber arbeiten intern wohl generell mit 256 Microsteps und liefern damit praktisch eine mehr oder weniger homogene Sinuskurve. Der Treiber selbst kann nur bis 1/16fach ansteuern. Da aber soweit ich das verstanden habe, der Motor unabhängig von der über den Treiber eingestellten Unterteilung intern sowieso mit 1/256stel Steps arbeitet, müsste er trotzdem sauber genug laufen. Daher will ich als Treiber einen TMC2208 verwenden. Probieren werde ich das erst mal an meiner EQ Plattform. Wenn es da rund läuft, sollte es auch für einen AltAz Antrieb reichen. Verwenden will ich NEMA 17 Motoren. Die kann ich über 12V noch gut ansteuern. Der, den ich hier habe, hat einen Nennstrom von 0,4A und kommt damit auf 4,8W. Für meine EQ Plattform reichen sogar 1W am EQ2 Motor. D.h. wegen Drehmoment mache ich mir weniger Sorgen bei der großen Untersetzung.

Die Trinamic Treiber lösen auch gleich das Problem mit der Lautstärke. Durch die kleinen Unterschritte wird die Lautstärke der Motoren offenbar deutlich reduziert. Kann man alles hier nachlesen:

Ist eine deutsche Firma, produziert wird in DE und EU. Das ist dann auch noch sowas, wo ich gerne unterstütze. Abgesehen davon ist es eh die beste Lösung, die ich gefunden habe.

Die Untersetzung ist damit also nicht mehr das Problem. Allerdings müssen die Motoren halt entsprechend gut auflösen. 400 Steps ohne Untersetzung sollten es schon sein. In meinem Fall werde ich die Lager über Zahnriemen antreiben. Eine Umdrehung in Alt entspricht ca. 4° Verstellweg am Dobson, in Az sind es 6°. Ohne Untersetzung ist ein Step dann aber immer noch 36" bzw 48". Das ist noch viel zu viel. Mit den internen 1/256 Steps komme ich auf ca. 0,14" bzw. 0,19". Das ist schon unter der Auflösung meines 12"ers, aber meiner Meinung läuft das immer noch ziemlich rau. Das wird ja nicht alles komplett homogen sein und gerade in Dec muss ich mit der Geschwindigkeit nochmal deutlich runter. Ich hätte da schon gerne mindestens meine 30 Steps pro Sekunde, damit für das Auge ein flüssiges Bild entsteht. Mit der Kamera brauche ich eher noch mehr. Oder eben eine Auflösung, wo das definitiv nicht mehr stört. Von daher plane ich noch einen Motor mit Getriebeuntersetzung zu nehmen. Ich habe jetzt mal einen mit 1:27 Planetengetriebe hier. Ob das übertrieben ist und ich dann Probleme mit der Geschwindigkeit bekommen kann, werde ich ausprobieren müssen. Für den AltAz Antrieb müssten 1:5 eigentlich reichen, wenn der Treiber das hergibt, was drauf steht. 1:10 wäre wohl ideal. Gegen Süden habe ich in Az mit 30 Steps pro Sekunde eine Auflösung von 0,5". Das reicht also alles locker. Soweit die Theorie. Mit DC Motoren habe ich schon gearbeitet, mit Steppermotoren habe ich aber noch keine praktische Erfahrung.

Versuch macht kluch, wie es so schön heißt ;) Hoffentlich geht das auch so, wie ich mir das vorgestellt habe. Wenigstens kann man da keine größeren Beträge in den Sand setzen...

Grüße
Joachim
Hi Joachim,
Als Startpunkt empehlen wuerde Ich dir eine "ausgereifte" Bastelloesung wie die Onstep. Die verwendet auch Trinamic Stepper Treiber und ist im open-loop Betrieb ziemlich ausgereift. Kann man fuer alle Uebersetzungsverhaeltnisse anpassen.
Arduinomaessig gibt es dafuer verschiedene Hardwareplatformen die man realisieren kann, die von preiswerten Blackpills bis zu schnellen Teensy 4.1 reichen und fertig aufgebaute boards g8bt's auch (wenn's sein muss). Der Code ist open source, kannst also spaeter darin rumhacken, wie Du lustig bist, um dein Ding zu machen.
Vorteil ist dass "langweilige" Sachen wie Ausrichten, GPS-Position und Zeitanpassung ueber z.B. Android-apps die dazupassen schon implementiert sind, ein Katalog ist auch schon da, ueber preiswerte Wifi- boards gibt's einen Webserver, etc....
Da muss man viele (sehr zeitaufwendig in eigener Implementation) Raecer nicht mehr neu erfinden und kann man sich auf das Wesentliche konzentrieren, z.B. die mechanische Umsetzung.
Neuere Versionen der Onstep kann man auch im closed-loop Betrieb verwenden (sowohl mit encodern am Stepper/Servo) sowie mit hochaufloesenden Encodern direkt an der Achse. Damit wuerde Ich aber nicht unbedongt anfangen, sondern erst mal open-loop zum Laufen bringen (und mal schauen, ob's das nicht schon tut) und spaeter erweitern. Die groesseren Onstep PCBs sind dafuer vorbeteitet.
Schau's dir halt mal an: main@onstep.groups.io | Wiki
Gruss & CS
 
Hi Hoachim,

also ich betreibe meinen 12 Zoll Martini Dobson mit Schrittmotoren und mache damit selbst programmiertes GoTo über Stellarium.

Selbstverständlich benötigt man bei Einsatz eines Schrittmotors keine Encoder.
Der Schrittmotor muss allerdings so arbeiten, dass er keine Schritte verliert und die mechanische Konstruktion darf keinen oder nur wenig Schlupf haben.
Das ist mM normalerweise bei einem Antrieb der Dobson Montierung über grosse Sichelräder und grosser Grundplatte und aufgeklebten Zahnriemen, wie ich es mache, der Fall. Die Übersetzung ist ja sehr hoch und der Schrittmotor benötigt nicht viel Haltemoment, wenn alles schön ausbalanciert ist. Man kann auch einen Schrittmotor mit Getriebe einsetzen.
Bei einer Dobson Montierung kann mM übrgigens sowieso keine hohe wiederholbare Positionierungs-Genauigkeit erreichen, da die Montierung selber aufgrund der Konstruktion einige Schlupf-Bereiche hat. Aber wer macht heutzutage kein Plate-Solving, also alles kein Problem ;) .

Ausserdem sollte man unbedingt die üblichen TMC Treiber einsetzen, also zB TMC 2208. Ich habe auch andere, billigere probiert. Das lohnt sich nicht. Die TMC machen sauberes zuverlässiges Micro-Stepping und sind super leise. Wenn man sehr komfortables, aber aufwendiger zu programmierendes Controling und Einstellen des Schrittmotors haben will, dann kann man auch die Varianten mit IC2 Bus einsetzen.
(Sehe jetzt erst, dass du das ja selber geschrieben hast. Alles gut. ;) )

Zum Programmieren würde ich statt der originalen Arduino IDE gleich Visual Studio Code mit der PlatformIO Extension nehmen und mM unbedingt vorhandene Schrittmotor-Libraries einsetzen und nicht selber machen. Ich benutze die Library "waspinator/AccelStepper@^1.61" (Angabe aus PlatformIO). Die zählt selbstverständlich in jedem Betriebszustand die durchgeführten (Micro)-Schritte. Also man hat immer Kontrolle an welcher Schritt-Position der Schrittmotor steht.
Es gibt auch eine Library mit IC2 unterstützung. Damit kann man dann die Micro-Schritte über IC2 einstellen. Ich mache das aber einfach über HW-mäsig verdrahteten zusätzlichen PINs des Arduinos. Die Library berücksichtigt leider nicht Micro-Schritt Umstellungen. Sie zählt einfach nur Schritte, egal welche. Das muss man dann selber verwalten.

Mit der PlatformIO kann man auch mit dem identischen Code verschiedene Microprozessoren (theoretisch auch nicht Arduinos) programmieren. Aber wie das in der Praxis dann funktioniert weiss ich nicht, da ich nur Arduino Clones einsetze, hauptsächlich den Nano. Der ist super praktisch, da er sehr klein ist und auch USB verbaut hat. Ich habe auch den Nano 33 IOT, der funktioniert jedenfalls mit dem selben Code. Das WLAN vom IOT habe ich aber noch nicht eingesetzt

Natürlich kann die Library nicht feststellen, wenn durch mechanische Einflüsse Schritte verloren gehen. Wobei es gibt auch Schrittmotor Treiber, die die Ausführung der Schritte aktiv kontrollieren können (closed Loop). Da kenne ich mich aber nicht aus, halte es auch bei unserem Anwendungsfall für unnötig.

Gruß
Peter
 
Zuletzt bearbeitet:
Als Startpunkt empehlen wuerde Ich dir eine "ausgereifte" Bastelloesung wie die Onstep.
Die Onstep Homepage hatte ich mir angeschaut. Allerdings war ich dort in der Masse an Informationen schnell verloren und auch das Level der Fachbegriffe war mir als Elektronikanfänger etwas zu weit weg. Da mir die Berechnungen und das Programmieren für mein Projekt keine größeren Probleme bereiten, hatte ich den Eindruck, dass komplett selber machen die zeitlich günstigere Variante ist. Ich schaue aber nochmal rein. Spätestens wenn ich in ferner Zukunft mal auf die Idee komme aus dem ganzen ein Goto System zu machen, werde ich ohne fremde Hilfe nicht mehr auskommen ;) Der Vorteil vom selber machen ist auf jeden Fall, dass man hinterher genau verstanden hat, wie das funktioniert. Das gibt einem dann in der Regel jedes mal neue Optionen. Z.B. das zu verstehen, was auf der Onstep Homepage steht. Die gehen immer davon aus, dass man in der Materie zu Hause ist. Bin ich aber nicht. Ich muss mir das alles erst mal von null erarbeiten.

Ich benutze die Library "waspinator/AccelStepper@^1.61" (Angabe aus PlatformIO). Die zählt selbstverständlich in jedem Betriebszustand die durchgeführten (Micro)-Schritte. Also man hat immer Kontrolle an welcher Schritt-Position der Schrittmotor steht.
Accelstepper kenne ich. Aber wie werden dort die Steps analog einem Encoder getrackt? Ich sehe da keine Funktion, die das macht. Ich hatte vor einfach die berechnete Geschwindigkeit für den Motor zu setzen und diesen Vorgang mit den neuen Positionen immer wieder zu wiederholen. Gleichzeitig wollte ich mir einen Parameter einbauen, mit dem ich die Geschwindigkeit manuell feintunen kann.

Visual Studio Code werde ich mit der Extension mal ausprobieren. Die Arduino IDE finde ich ziemlich sperrig, wenn es um das reine Codieren geht.

Wie kann ich mir das mit dem Plate Solver vorstellen? Synct der sich dann mit Stellarium?

Aber eins nach dem anderen. Erst mal die Schrittmotoren zum Laufen kriegen als Trockenübung. Dann EQ Plattform auf den Schrittmotor mit Gewindespindelantrieb umrüsten. Wenn ich das zum Laufen gekriegt habe, werde ich genug Grundwissen haben um einfach einen AltAz Antrieb realisieren zu können. Platesolving und Goto habe ich am Dobson bis jetzt noch nie vermisst. Aber wer weiß, es wachsen ja die Ansprüche. Eine Motorfokussierung für meinen Okularschlitten wäre mir aber erstmal wichtiger. Den Schlitten wollte ich an sich nochmal neu konstruieren. Wer weiß, vielleicht läuft die EQ Plattform dann so gut, dass ich gar keine Ambitionen mehr habe, einen AltAz Antrieb zu bauen. Aber egal wie, damit bin ich auf jeden Fall mehrere Jahre beschäftigt...
 
Hi Joachim,

also die Accelstepper Library speichert intern die Anzahl der ausgeführten Schritte, die Step-Position des Motors.

Mit den Aufrufen move(steps) oder moveTo(step-position) bewegt man den Schrittmotor.
Mit currentPosition() bekommt man die aktuelle step-position. Das kann man auch in Bewegung abfragen, sie verändert sich dann laufend.

Wichtig ist, es gibt 2 Modi, einmal steuert man den Motor nur mit den Move-Kommandos, dann arbeitet er sozusagen so schnell es eingestellt ist, die notwendige Schritt-Anzahl ab. Dabei findet auch ein einstellbares Ramping beim Anlauf und beim Stoppen an der neuen Position statt.

Oder man benutzt setSpeed(steps/s), steps/s ist ein Kommawert und kann auch kleiner 1 sein (!), dann läuft er kontinuierlich. Aber die Step-Position wird dabei trotzdem getrackt.
Man kann im Prinzip zwischen den 2 Modi hin- und herschalten. Dabei verliert er nicht die Step-Position. Das ist also ziemlich komfortabel.

Allerdings habe ich keine Erfahrung wie man sauber zwischen Speed und Move-Mode umschaltet. Habe bisher nur das eine (EQ-Plattform) oder das andere (Az-Montierung) benutzt. Wahrscheinlich muss man ersteinmal sauber stoppen und abfragen und dann erst umschalten.

Einfaches GoTo ist eigentlich mit den Move-Kommandos keine grosse Sache. Man macht an einer Position, egal welche, ein Plate-Solving. Die Koordinaten entsprechen dann den Step-Positionen. Wenn man jetzt zu einer anderen Alt/Az Koordinate will, muss man das nur in Steps umrechnen und per Move hinfahren. Allerdings ist dann natürlich die weiter stattfindende Drehung des Himmels nicht berücksichtigt. Kann man aber natürlich auch korrigieren.
Man benötigt also nur den Faktor für beide Achsen, wieviel Grad ein Step entspricht. Ich habe dazu einfach den Winkel gemessen den eine bestimmte Anzahl an Steps an der Achse bewirkt. Daraus bestimmt sich dann der Umrechnungs-Faktor für die jeweilige Achse.
Die aktuellen Alt/Az Koordinaten von Objekten an meinem Standort frage ich einfach programmatisch aus Stellarium ab.

Gruß
 
Zuletzt bearbeitet:
Hallo Joachim,
um was geht es dir bei der Dobson-Motorisierung? GoTo-Fähigkeit oder primär Nachführung?

Nachführung lässt sich m.M. ja relativ einfach umsetzen. GoTo würde ich persönlich in Hinblick auf Lösungen wie Skysolve wahrscheinlich nicht mehr bauen wollen.
Aber das ist natürlich meine Meinung.

Grüße,
Alex
 
um was geht es dir bei der Dobson-Motorisierung? GoTo-Fähigkeit oder primär Nachführung?
Primär um den Bastelspaß :D Das ganze funktioniert ja mit der EQ Plattform auch heute schon. Aber ich will ihn hauptsächlich motorisieren, Goto habe ich wie gesagt noch nie wirklich vermisst. Meistens verwende ich den Dobson eh visuell. Was will ich da mit einem nervigen Display daneben? Das wäre für mich nur fotografisch interessant. Aber auch das geht ja heute schon (siehe meine Galerie).

Bei der Frage geht es mir darum, ob mein Arduino Uno reicht. Wenn ich nämlich zusätzlich Encoder brauche, dann reichen mir die Pins nicht.

Die Ansprüche an die Motorisierung sind allerdings höher als an Goto. D.h. wenn er motorisiert ist, dann ist er ausreichend genau um auch Goto zu machen...insofern man die Schnittstelle hinbekommt.
 
Bastelspaß ist als Motivation natürlich völlig in Ordnung und man lernt viel. Aber irgendwie Zeit sparen wirst Du nicht und den technischen Stand von 6 Jahren intensiver Entwicklung bei Onstep oder TeenAstro auch nicht erreichen. Was interessant wäre, ist eine minimalistische Lösung, die auf die bauteilseitigen Fähigkeiten der Trinamic Chips abhebt, das wollte Howard Dutton (Onstep Entwickler) nie. Der integrierte motion controller löst alle harten Echtzeitanforderungen zur Rampengenerierung. Der Rest sind zb ein paar passende Aufrufe der python Astro Bibliotheken. Nie war es einfacher :cool: Eventuell wäre das auch als OnstepX Plugin realisierbar.

Triggerwarnung (Boomer erzählt von früher):

Klassiker in dem Bereich sind die Bücher von Mark Trueblood und Russel Genet (Microcomputer Control of Telescopes, 1985) (Telescope Control, 1997). Mit ersterem Buch habe ich 1989 als noch Ingenieurstudent (TU Kaiserslautern) und einem BASIC Stamp (8052) meine erste Steuerung DC Servo plus Heidenhain Encoder gebaut....

CS, Markus
 
Einfaches GoTo ist eigentlich mit den Move-Kommandos keine grosse Sache. Man macht an einer Position, egal welche, ein Plate-Solving. Die Koordinaten entsprechen dann den Step-Positionen. Wenn man jetzt zu einer anderen Alt/Az Koordinate will, muss man das nur in Steps umrechnen und per Move hinfahren. Allerdings ist dann natürlich die weiter stattfindende Drehung des Himmels nicht berücksichtigt. Kann man aber natürlich auch korrigieren.
Wie schnell fährt denn dein Dobson eigentlich mit den Schrittmotoren? Wenn man weiß wieviele °/s das Teil fährt kann man die Himmelsdrehung ja einfach kompensieren, indem man entsprechend weiter fährt. Theoretisch kann man ja auch einfach das ganze nochmal wiederholen. Dann ist der Anfahrweg nur wenige Bogenminuten. Einen gewissen Reiz hätte das schon. Da es immer heller wird, fehlen mir immer öfter genügend schwache Referenzsterne um die Objekte auf die kleinen Chips zu positionieren.
 
Hi Joachim,

Wie schnell fährt denn dein Dobson eigentlich mit den Schrittmotoren? Wenn man weiß wieviele °/s das Teil fährt kann man die Himmelsdrehung ja einfach kompensieren, indem man entsprechend weiter fährt. Theoretisch kann man ja auch einfach das ganze nochmal wiederholen. Dann ist der Anfahrweg nur wenige Bogenminuten. Einen gewissen Reiz hätte das schon. Da es immer heller wird, fehlen mir immer öfter genügend schwache Referenzsterne um die Objekte auf die kleinen Chips zu positionieren.
habe im Code nachgeschaut, die Faktoren zwischen Steps und Winkel sind so um die 200 steps/grad (ohne Microsteps).
Der höchste Speed mit dem Arduino Nano und der Accelstepper Library ist so 400 steps/s, also sind es im Maximum so 2 grad/s.
Und klar die Himmelsdrehung kann man entsprechend berücksichtigen, aber ich mache einfach an der neuen Position wieder ein Plate-Solve und das ist dann schon sehr nah, so dass dann nur noch wenig korrigiert werden muss.
Die genaue Positionierung des Objekts mache ich dann sowieso mit der Live-View in SharpCap. Dazu kann ich in meiner SW einfach kleine Alt/Az-Korrekturwerte eingeben.

Übrigens der Dobson steht ja auch noch auf der EQ-Plattform. Wenn die korrekt läuft und gestartet ist, dann gibt es aus Sicht des Dobsons keine Himmelsdrehung mehr. Dann könnte man ab da in Stellarium auch einfach die Zeit anhalten. Aber das habe ich so konkret noch nie getestet.

Kleines Problem ist auch, dass ich das PS mit der Objekt-Kamera mache. Manchmal funktioniert dann das PS damit nicht, da ja das Feld relativ klein ist. Besser wäre eine extra PS-Kamera mit einem Sucher und grossem Feld. Könnte ich machen, bin aber zu faul ;) .

Man könnte auch ohne EQ-Plattform nach der Zentrierung auf das Objekt über die Speed Funktion eine ALt/Az Nachführung realisieren.
Bin da aber nie weiter gekommen, da ich keine einfache (für mich verständlichen ;) ) Berechnung der Alt/Az Himmels Geschwindigkeit einer Position gefunden habe.
Wenn ich mal wieder weitermache, da ich SW seitig einiges umgebaut habe, dann versuche ich das ohne Berechnung durch eine einfache manuelle Speed Regulierung hinzubekommen. Aber Alt/Az Nachführung finde ich inzwischen gegenüber einer EQ-Plattform sowieso nicht attraktiv, da man im Zenit nicht gut nachführen kann und genau der Zenit ist bei Lichtverschmutzung sehr wichtig.

Gruß
Peter
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben