Teleskopsteuerung mit Raspberry Pi ?

  • Hallo zusammen,


    ich hatte heute einen Geistesblitz, bei dem ich mal euren Input bräuchte, weil ich schon fast zwei Jahre nicht mehr aktiv in der Szene dabei bin.


    Ich hatte mir vor Jahren eine Montierung gebaut und war dann an der Entwicklung einer eigenen Steuerung gescheitert (Hard- und Software waren irgendwann lauffähig aber wirklich komfortabel war das ganze nicht). Ich habe auch den "Steuerungskrieg" mit offenem Mund staunend verfolgt und mich schließlich für ein Kaufprodukt entschieden und bin damit seitdem glücklich. (hier bitte keine Diskussion dazu)


    Trotzdem lässt mich das Thema "moderne, frei parametrierbare Steuerung für ein Teleskop" nicht los. Zufälligerweise wurde mir zu Weihnachten ein Raspberry geschenkt und der liegt seit dem eigentlich nur rum und da kam mir jetzt eine Idee: Viele der Projekte die man so verfolgen konnte: kommerzielle(Boxdörfer), teilkommerzielle (LF), komplett offene (open drive) krankten immer daran, dass die Leistungselektronik und das was softwaretechnisch da drauf kam in einem Gerät integriert wurde. Sprich da war vllt ein Entwickler, der zwar die Leistungselektronik prima zusammen bekam, die Benutzeroberfläche war aber irgendwie aus einem anderen Jahrhundert. Oder andersherum sah die Benutzeroberfläche sauber aus, die Leistungselektronik war aber dann etwas schwach auf der Brust. Alle Entwickler hatten die gleichen Herausforderungen zu meistern: Koordinaten umrechnen, Sternenkataloge richtig interpretieren und und und.


    Jetzt kam mir die Idee mit dem Raspberry. Im Prinzip ist alles schon tausendfach in allen Geschmacksrichtungen vorhanden: Planetariumsprogramme, die jeder nach seinen Vorlieben einrichten kann mit Katalogen noch und nöcher (und größtenteils auf dem Raspberry lauffähig) und alle größtenteils mit einem gemeinsamen Protokoll: die LX200 Schnittstelle. Ich träume schon länger davon, eine Steuerung zu bauen die total "dumm ist", also von einer Hardware lediglich Stepperfrequenzen bekommt und diese dann per Transistoren verstärkt an die Motoren weitergibt (also eine typische Schrittmotortreiberkarte, wenn man so will). Diese Frequenzen (also Drehrichtung und Drehgeschwindigkeit) könnte doch ein Raspberry aus LX200 Befehlen, die aus einem Planetariumsprogramm kommen, generieren, oder?


    Nötig wäre also ein kleines Programm, in dem durch eine kleine Eingabemaske Getriebedaten und Schrittmotorauflösung eingegeben werden. Anschließend müssen die von einem X-beliebigen Planetarium kommenden LX200 Befehle nur noch in Stepperimpulse umgerechnet werden, die per Ausgabepins den Raspberry verlassen und dann zur Treiberkarte laufen, die die Motoren entsprechend befeuern.


    Ich habe das Gefühl dass die gesamte Hardware für eine unendlich individuell einstellbare Teleskopsteuerung zu einem unschlagbar niedrigen Preis schon vorhanden ist und es nur an einem kleinen Programm fehlt. Per VNC könnte man dann am Smartphone oder Tablet die Steuerbefehle eingeben (GOTO oder Richtungstasten wie am Gameboy). Wenn jemand Bock hat zu basteln, könnte man sich sogar noch eine robuste mit Winterhandschuhen bedienbare Handsteuerbox basteln oder man könnte sich sogar ein Interface bauen welches es ermöglicht, LX200 Hardwarebefehle einzulesen (und entsprechend der verwendeten Montierung im Raspberry nur umrechnen zu lassen), sodass man eine etwaige Handsteuerbox weiter benutzen kann, an deren Menüführung man sich schon gewöhnt hat.


    Warum finde ich dazu nichts, wenn ich Teile dieser Idee per Stichwortsuche bei Google eingebe? Denke ich zu einfach? Wo ist der Haken? Oder gibt es keinen Bedarf mehr für solche Technik?


    Würde mich freuen von euch zu hören!
    Viele Grüße
    Michael

  • Gut, gute Idee, Der_Michael!


    Dann fang schon mal an und mach....


    Also im Prinzip brauchts du ja nur ein wenig sphärische Trigonometrie, um lx200-Positionierbefehle (Rektaszension/Deklination) auf Stundenwinkel umzurechnen (für äquatorial montierte Teleskope) oder auf Azimut/Horizonthöhe umzurechnen (für azimutal montierte Teleskope). Am Besten, deine Steuerung kann beides. Ausgehend von der momentanen Teleskopposition, also dem momentanen Wert des Stundenwinkels bzw des Azimuts/Horizonthöhe auf der das Teleskop momentan steht, ergibt sich eine Winkeldifferenz in Form von Schrittmotorschritten, die das Telekop zu bewegen ist um die neue Position zu erreichen. Universelle Motor- und Getriebeparameter sind ja leicht parametrierbar in deiner Software zu verwalten. Der Stundenwinkel bzw. Azimut/Horizonthöhe ändern sich ständig mit der Zeit. Diese Änderung ist die Winkelgeschwindigkeit der erforderlichen Nachführung und sie ist auch während einer laufenden Positionierung zu berücksichtigen, da du ja nicht unendlich schnell auf die neue Position hinfahren kannst. Sobald deine Steuerung erkennt, dass die Zielposition bald erreicht wird, nimmst du die Positioniergeschwindigkeit in deiner Software langsam zurück, bis du bei erreichen der Zielposition nur mehr die Nachführgeschwindigkeit(en) hast.


    das wäre im Prinzip alles!


    Oder nicht?


    Sagen wir mal so: Es gibt gewisse Vorraussetzungen: Da hätten wir einmal die Startposition des Teleskops, also die momentane Teleskopposition zu Beobachtungsbeginn. Da musst du entweder einen bekannten Stern manuell einstellen, dann hast du deine Startposition. Oder deine Software parkt am Beobachtungsende dein Teleskop irgendwo (beispielsweise im Zenit) und du startest in der nächsten Beobachtungsnacht von dort weg (wohl nur bei stationären Sternwarten-Telekopen brauchbar).


    Als nächste Vorraussetzung haben wir die Aufstellgenauigkeit. So wie ich es eben beschrieben habe, funktioniert es nur bei exakter Nordung (für äquatorial montierte Teleskope) bzw. exakter Ausrichtung mit sehr genauer Wasserwaage (für azimutal montierte Teleskope).


    Zuguterletzt brauchst du noch die genauen Standortkoordinaten und die genaue Uhrzeit, sonst kommst du mathematisch ja nicht auf den Stundenwinkel.


    Also dass ist aber jetzt doch wirklich alles!


    Oder nicht?


    Na ja, für eine amateurhafte Steuerung reicht es aus. Professionell ist es jedoch immer noch nicht, weil wir stillschewigend 2 weitere Winkelwerte vorrausgesetzt haben: Nämlich den exakten 90°-Winkel zwischen Rektaszensionsachse (bzw. Azimutachse) und Deklinationsachse (bzw. Höhenachse) bei deinem Teleskop.


    Dann brauchen wir noch einmal weitere 90° zwischen Deklinationsachse (bzw. Höhenachse) und optischer Achse, auch dieser Winkel wird bei deinem Teleskop nicht ganz genau stimmen.


    Das ergibt insgesamt 6 Parameter (4 Winkelwerte und die Startposition), deren genaue Einhaltung über die Genauigkeit deiner Positionierung entscheiden wird.


    Was jetzt immer noch fehlt, ist die Korrektur der atmosphärischen Refraktion. Nun die kann deine Himbeere leicht auch noch dazu ausrechnen. Dann ersparst du dir die blöde "King-Nachführrate"


    So, jetzt ist deine Steuerung aber ganz genau, zumindest wenn dein Telekop so genau aufgestellt und so genau gebaut ist, oder nicht?


    Doch, doch, da kann ich dich beruhigen. Nur noch Kleinigkeiten hätten wir noch: Eine eventuelle Durchbiegung deines ganzen Teleskops hast du nicht berücksichtigt. Weiters den Schneckenfehler deiner Getriebe und den Getriebe-Totgang (neudeutsch backshlash), na ja dass sind aber wirklich Kleinigkeiten. Zumindest in einem aufgeflanschten Sucher wirst du dein positioniertes Himmelsobjekt sicher schon finden, sofern es nicht zu lichtschwach ist.


    Was ich noch tun würde, wenn ich ein stationär montiertes Teleskop hätte?


    1.) lx200 ist zwar nett, aber primitiv! Du hast keine Möglichkeit, die Eigenbewegung von Himmelsobjekten bei der Positionierung mit anzugeben. Üblich sind Eigenbewegungsgeschwindigkeit in Bogensekunden pro Zeitsekunde sowie der Positionswinkel. Ordentliche Planetariumssoftware rechnet dies für Objekte des Sonnensystems mit aus (Guide9).


    2.) Die Epoche, auf die sich die Himmelskoordinaten beziehen, sollte bei einem Positionierbefehl ebenfalls angegeben werden (schon wieder Fehlanzeige bei Lx200).


    Alternativen zu Lx200?
    Nimmst du statt Lx200 das Celestron-Nexstar-Protokoll, dann bist du zwar "Hardware-näher", aber flexibler. Nicht umsonst bauen die Chinesen da drauf auf (Skywatcher). Du kannst ja locker beides in deiner Himbeere implementieren.


    3.) Schon mal was von Tpoint gehört? Tpoint modelliert die oben erwähnten 6 Parameter in einem Teleskopmodell. Da brauchst du weder ganz exakt einzunorden, noch muss dein Teleskop mechanisch so genau gebaut sein. Die 6 Parameter werden "eingemessen" und die Koordinaten des einzustellenden Himmelsobjektes danach entsprechend "verfälscht".


    4.) Noch besser wie das depperte Tpoint ist es, du verwaltest dein Teleskopmodell selber in deiner Himbeere. Mathematisch zwei weitere Koordinaten-Transformationen der Himmelskoordinaten (wieder sphärische Trigonometrie). Dann macht du auch den Fehler nicht, den Tpoint immer noch macht: Du kannst die Missweisung deines Teleskops und die beiden (oben beschriebenen) Konusfehler (zusammen mit der atmosphärischen Refraktion) nicht nur bei der Positionierung, sondern auch bei der Nachführung berücksichtigen!


    Wenn du das geschafft hast, wirst du (sofern dein Sternwarten-Teleskop hinreichend mechanisch stabil montiert ist) ohne einen Guider auch bei hohen Brennweiten (>2m) eine oder sogar mehrere Minuten lang mit einer CCD-Kamera belichten können. Jetzt ist deine Himbeeren-Teleskopsteuerung wirklich professionell und hebt sich von all den "Produkten" ab, um die sich dieser "Steuerungskrieg" seinerzeit gedreht hat.


    Woher weis ich das alles?
    Naja, ich war ein paar Mal auf der Sternwarte Harpoint (Österreich, Salzkammergut) zu Besuch und hab mir dass eben erklären lassen. Die haben dort auch eine Montierung gebaut. Nicht nur die Montierung, das ganze Teleskop.

  • Moin,


    ...er hat ja davon geschrieben, eine einfache Steuerung zu bauen - kein ASA-Teleskop;-)


    Ich sehe da beim Pi ein ganz simples Problem, weshalb damit Steuerungsaufgaben dieser Art eher sinnlos sind:


    Wovon mein Vorredner sprach, betrifft ja eigentlich nur die Goto-Funktion. Will heißen "Ist-Wert wissen, in beiden Achsen Differenz zu Soll-Wert errechnen und ab die Post". Das ist mit dem Pi soweit überhaupt kein Problem...


    Was ich für problematisch halte, ist die total simple Nachführung, die dafür aber leider sehr genau sein muss. Dafür ist der Pi m.E. überhaupt nicht geeignet.


    Auf dem Pi läuft irgendein Linux - also ein Multitasking-OS. Eine Schrittmotor-Steuerung für eine saubere Nachführung muss den Stepper immer ganz exakt zum richtigen Zeitpunkt zu einem Schritt veranlassen. Dazu ist es wenig hilfreich, wenn das Multitasking-OS in diesem Moment meint, etwas völlig anderes tun zu müssen.


    Deshalb nimmt man dafür eher einen Arduino. Daran habe ich mir allerdings auch schon die Ohren gebrochen...


    Beim Arduino läuft ja das komplette Programm immer in einem Endlos-Loop - u.a. auch die Routine, die den Schritt auslöst. Das ist für den Nachführbetrieb auch wunderbar - limitiert aber die Goto-Geschwindigkeit bei steigender Komplexität immer mehr. Vor allem, wenn man im gleichen Loop noch Eingänge abfragt (Seriell LX-200, ST4-Eingang, etc.)
    Bei meinem letzten Versuch wurde die max. Goto-Geschwindigkeit immer langsamer, bis ich aufgegeben habe.


    Ich habe mir dann angeschaut, wie es andere machen und bin schnell darauf gestossen, dass niemand so etwas im normalen Arduino-Basic/C (ist ja irgendwie eine Mischung) macht, sondern nur direkt im Maschinen-Code. Dazu habe ich aber definitiv keine Lust...


    Ich wollte das ganze demnächst nochmal mit einem der neuen schnellen Arduinos (Duemillenova) angehen. Der wird's wohl packen...


    Gruß
    Klaus

  • Glaubst du wirklich, dass ASA-Teleskope so gut sind? Na wie dem auch sei, zu dem was (==>)watchgerar geschrieben hat, gibt es folgendes zu ergänzen:


    Die eigentliche Schrittausgabe kann der Arduino mit seinem einfachen single-Task-Betriebsystem wirklich besser, da hat (==>)watchgear Recht. Da funkt dir kein anderer Interrupt dazwischen, wenn du es nicht willst. Du musst nur dafür sorgen, dass deine Schrittmotor-Schrittausgabe die höchste Priorität bekommt. Der Arduino wird allerdings nur Integerzahlen vernünfig rechnen, für Gleitkommaoperationen ist er zu schmalbrüstig. Du brauchst letztere jedoch für die von mir beschriebene(n) Koordinatentransformationen, wenn du rechnergesteuert positionieren und nicht nur nachführen willst.


    Am Besten du nimmst beide, den Arduino für die direkte Schrittmotor-Ansteuerung und eine einfache Bedienoberfläche zur Motor/Getriebe-Parametrierung, sowie die Himbeere (bzw. gleich einen PC) für den Rest und die Schnittstelle zum Planetariumsprogramm. Oder du verwendest statt dem Arduino eine fertige Schrittmotorsteuerung mit asynchroner Positions- oder Geschwindigkeitsvorgabe an der Schnittstelle zum überlagerten Rechner.


    Der Clou einer guten Teleskopsteuerung ist aber nicht die Ansteuerung des Schrittmotors selber, dass kann fast Jeder. Der Kern liegt in den von mir einfach beschriebenen Berechnungen, die auch asynchron, also ein klein wenig unregelmäßig durchgeführt werden können. Das geht sehr wohl unter Linux oder auch unter (Sch)windows, wenn du willst.


    Soweit alles klar?

  • Moin,
    die Probleme fangen an, wenn man ins Detail geht.
    Z.B. das LX200-Protokoll ... Die Schnittstelle ist nicht so eindeutig, dass man sie auf Anhieb funktionierend hinkriegt, denn im Detail backen die Planetariumssoftware-Pakete da ihre eigene Brötchen. Wie z.B. erkennt die Software, dass das Teleskop überhaupt "betriebsbereit" ist? Im Ergebnis muss man sich einlesen in fremde Programmcodes und nachvollziehen, was die Entwickler gemacht haben und das für viele Kleinigkeiten. Das kann frustierend sein und wird die meiste Zeit beanspruchen.


    Die eigentliche Benutzerführung ist auch nicht "ohne". Man braucht ja ein Eingabgegerät und will sein Projekt nicht davon abhängig machen, dass man nur ein ganz bestimmtes Gerät akzeptiert. Jeder hat da seine eigene Bedürfnisse: Der eine bevorzugt einen Joystik, der andere Cursortasten, mal mit einzeiliger Anzeige, mal per Bluetooth via Android-Smartphone oder Remote vom Rechner. Der eine will guiden können, der andere nicht, der dritte legt Wert darauf bestehendes Equipment nutzen zu können und muss deshalb zu bestimmten Produkten kompatibel sein.


    Die eigentliche Koordinatentransformationen oder Prozeduren zum Einnorden/Aligment und die Generierung von Steuerungsbefehlen sind fast noch das geringste Problem. Die setzen allerdings etwas überdurchschnittliche Mathematiklenntnisse voraus. (Da gibt es übrigens verschiedene Herangehensweisen. Und wirklich flexibel ist man erst, wenn man auch exotische Probleme abfangen kann, wie z.B. Montierungsachsen, die nicht orthogonal zueinander sind oder nicht linear arbeiten (z.B. EQ-Plattformen oder Selbstbau-Barndoor-Montierungen).


    Fazit: Bevor man loslegt, muss man sich ein Pflichtenheft erstellen, was man eigentlich will. "Frei parametrierbar" ist ein hoher Anspruch.

  • hi!
    kann dem nur beipflichten. externe schrittmotorsteuerungen gibt es zuhauf und seit jahrzehnten (ich kann mich an eine erinnern, die über einen rs 232 terminal seriell von einer VAX angesteuert wurde). die von mir verwendeten phdiget-boards sind nur ein beispiel.


    die von dir genannten berechnungen klingen jetzt ehrfurchtgebietender als sie es sind. ich habe zum beispiel die korrektur auf das aktuelle äquinoktium eingebaut. das sind 7 zeilen c-code. refraktion ist ähnlich gelagert. ich pflichte dir aber bei, dass ich das am arduino eher nicht machen würde...


    meine steuerung läuft übrigens sowohl am raspberry als auch am pc. nachteil vom pc ist halt die fehlende GPIO schnittstelle fürs ST4. pi reicht aber kapazitätsmässig vollkommen.
    lg
    wolfi

  • servus kalle!


    "die Probleme fangen an, wenn man ins Detail geht.
    Z.B. das LX200-Protokoll ... Die Schnittstelle ist nicht so eindeutig, dass man sie auf Anhieb funktionierend hinkriegt, denn im Detail backen die Planetariumssoftware-Pakete da ihre eigene Brötchen."


    das protokoll ist eigentlich ganz sauber definiert, auch wenn es hier kritikpunkte gibt. das problem ist eher das mit den eigenen brötchen ...


    "Wie z.B. erkennt die Software, dass das Teleskop überhaupt "betriebsbereit" ist? Im Ergebnis muss man sich einlesen in fremde Programmcodes und nachvollziehen, was die Entwickler gemacht haben und das für viele Kleinigkeiten. Das kann frustierend sein und wird die meiste Zeit beanspruchen. "


    die, die ich kenne, schicken einfach eine anfrage für deklination und ra los. korrekterweise müsste die planetariumssoftware am anfang ASCII 6 ("<ACK>") schicken und eine antwort erwarten, die den montierungstyp entspricht (z.B. "P" für eine gabel). das macht allerdings niemand ausser vielleicht kStars, mit dem ich mich nocht nicht soviel gespielt habe. klassischer fall von eigenem brötchen - der standard gibt vor, wie es gemacht gehört, und keiner kümmert sich drum ...


    "Die eigentliche Benutzerführung ist auch nicht "ohne". Man braucht ja ein Eingabgegerät und will sein Projekt nicht davon abhängig machen, dass man nur ein ganz bestimmtes Gerät akzeptiert. Jeder hat da seine eigene Bedürfnisse: Der eine bevorzugt einen Joystik, der andere Cursortasten, mal mit einzeiliger Anzeige, mal per Bluetooth via Android-Smartphone oder Remote vom Rechner. Der eine will guiden können, der andere nicht, der dritte legt Wert darauf bestehendes Equipment nutzen zu können und muss deshalb zu bestimmten Produkten kompatibel sein."


    naja, für anfang liefern LX200 und ST4 da hinreichend ansätze. extrawürschtl kann man dann ja noch immer machen. meine bluetooth - handbox verwendet ein privatprotokoll, aber das ist halt auch meine handbox und meine steuerung. man könnte sie ohne grosses theater auf LX200 commands umstellen.


    "Fazit: Bevor man loslegt, muss man sich ein Pflichtenheft erstellen, was man eigentlich will. "Frei parametrierbar" ist ein hoher Anspruch."


    naja, aus eigener erfahrung würd ich sagen, man kann nur das implementieren, was man debuggen kann ;)


    lg
    wolfi

  • Hallo zusammen,


    da kamen ja schon coole Beiträge! Danke dafür!


    (==>)schmorbraten: interessante Einwände und ich glaube genau dieser Blumenstrauß an Wünschen ist es, der solche Projekte immer scheitern lässt. Meine Idee war viel schmaler gestrickt: Wenn es eine frei programmierbare Plattform gibt, die sich jeder einfach kaufen kann (ohne vorher löten zu lernen o.ä.) erhöht man schonmal die Zahl potenzieller Mitentwickler bzw. User. Wenn die Basis läuft (RA+ RA- DEC+ DEC-) und vllt einfaches GOTO mit Stellarium sind schon 90% aller User zufrieden. Da nachher softwareseitig zusätzliche Features draufzusetzen (Temperaturkompensation, Drehgeber, 5 CNC Kameras mit jeweils 8 Filterrädern, Kühlerregelung für den Chip und Getränkehalter), ist dann jedem selbst überlassen. Bei freiem Codeaustausch könnte so ein Basispaket mit optional installierbaren Addons entstehen (wie ein Browser).


    (==>)Klaus: dein Einwand ist schon eine ganz andere Hausnummer, da zweifle ich ja schon an der technischen Realisierbarkeit der Basisfunktionalität...


    auch den anderen Danke für die Einwürfe. Der Arduino scheint eine Alternative zu sein, nur das man da schon wieder fast die Komfortzone vieler Leute verlässt...


    Wenn wir mal die Berechnungen und zu lösenden Softwaregeschichten beiseite lassen und uns auf den Raspberry konzentrieren gäbe es da halt die einfache Frage: Kann der Raspberry eine saubere, hohe Schrittmotorfrequenz auf bestimmte Pins ausgeben? Wenn das verneint wird, ist die ganze Geschichte schon jetzt tot. Man könnte zwar eine Schrittmotorkarte schaffen, die auf Befehle reagiert und sich selbst die Frequenzen generiert (vllt dann Arduino-gesteuert) aber dann sehe ich das Projekt in die gleiche Richtung laufen wie die anderen guten Ansätze...


    Würde mich weiter auf Antworten freuen!


    Michael

  • Hi Wolfi,


    danke für deinen Link!


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Independent controller boards are necessary as a Raspberry Pi does not feature a real-time operating system, therefore it cannot provide switching pulses to the driver of a stepper. Rather than that, the driver boards are connected via a serial connection (in the case of the Phidget 1067, this is USB 2.0), and basic parameters - the number of steps, the acceleration and the final velocity of the rotation motion - are provided to a separate microcontroller on board of the Phidget 1067<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Da bin ich dann leider raus. Das ist ja dann ein richtiges Lötprojekt. Was mir vorschwebt ist eher: Zusammensteck- und etwas Programmierung - fertig. Aber das scheint der Raspberry wohl nicht leisten zu können. Nicht schlimm! :)


    Viele Grüße
    Michael

  • Hallo wolfi, Hallo Gert,


    danke für eure Beiträge!


    Ich hatte das mit dem Raspberry und dem Treiberboerd vollkommen falsch verstanden. Da hat jemand praktisch also schon genau das gemacht, was ich vorhabe. Danke für die Erklärung, manchmal muss ich mit der Nase reingedrückt werden.


    Das mit dem Arduino werde ich mir auch mal was genauer angucken, ich bin ein totaler Fan von solchen Spielereien!


    Viele Grüße
    Michael

  • hi!
    wennst es probieren/anschauen willst, kann ich dir gern entweder ein raspian image oder eine ubuntu xerius version vom tsc geben. ohne phidgets bewegt sich natürlich nix, aber man kann sichs halt einmal ansehen. st4 geht natürlich nicht, weil linux die wiringpi-library nicht kennt ...
    lg
    wolfi

  • (==&gt;)Der_Michael: genau dieser Blumenstrauß an Wünschen ist es, der solche Projekte immer scheitern lässt...


    Eben nicht immer: An dieser von mir mehrmals besuchten Sternwarte in Österreich funktioniert das alles. Hab ich selber gesehen. Was dort seit vieleicht 20 Jahren unter DOS auf einem 25 Jahre alten 486-PC (Teleskop-Server), zusammen mit einer kleinen WIN7-Kiste als Teleskop-Client mit Windows-Bedienoberfläche und diversen Schnittstellen funktioniert (Kuppelsteuerung, spezielle Planetariumsprogrammanbindung, sehr praktische Bedienoberfläche mit Sprachausgabe, Remote-Access über Netzwerk), dass müsste heutzutage doch mit einem Pärchen Arduino/Himbeere genauso realisierbar sein. Nur eben ohne die mühsame Beschäftigung mit uralter Hardware und Software, die dort zumindest beim Server noch immer eingesetzt wird. In der Steiermark gibt es jetzt angeblich ein fast baugleiches Projekt, sowohl was das Teleskop (50cm Cass) als auch was die Steuerung betrifft. Hab ich mir sagen lassen.

  • hi!
    ich war sträflicherweise noch nicht in harpoint, aber ich kenn die beschreibung. im grunde würde man das heute mit ekos und einer leistungsfähigen steuerung machen.
    lg
    wolfi

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!