Beiträge von ClearSkyHopper im Thema „Offene Steuerung mit Encoder und Autoguider“

  • Offene Steuerung mit Encoder und Autoguider

    Holla, ja wenn Du es eh neu machst, dann nagle gleich ohne Köppfchen. :) Also dann wrüde ich nen großen ESP nehmen und basta. Probiere, ob sich der Code vom Arduino Mickrig verwenden läßt. Oftmals spielen nur Timer-Sachen verrückt :) Den Rest des Codes kannst vielleichtn noch verwenden.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    genau wegen dem Arduino mini hab ich Dir den ESP-01 empfohlen. Den schließt Du an TXD RXD an und fertig. Der ESP-01 braucht auch 3.3V.
    Das ist bestimmt das schnellste. Ohne das Du was änderst. Halt nur ein "Goldblatt" an Deiner Baustelle. Mehr nicht. Probiers aus. Die Dinger kosten weniger als ein HC05. Wennst magst, schick ich Dir einen fertig "geflashten" zu. Ich hab noch 5 von den kleinen, die reichen. Und 5 von den großen für die Onstep. -> PN

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    wenn Du statt einen HC05 einen ESP8266 ESP-01 nimmst. Darauf ESP-LINK installierst, dann kannst Du auf Bluetooth verzichten.
    Um ESP-Link zu konfigurieren, kannst Du vom PI oder Deinem Tablet aus eine AP-Verbindung aufmachen (Soft-AP).
    Damit könntest Du Deinen Handcontroller dann Konfigurieren (Spezielle Webpages gibts dafür auf ESP-LINK).
    Bluetooth wäre Geschichte, wenn Du ESP-LINK Deinen Raspberry PI als AP point nennst.
    Probiers mal aus. Die Programmierung der ESP-01 ist in etwa ähnlich gewöhnungbedürftig, wie die der HC05.
    Vielleicht mach ich Dir mal ne kleine Anleitung hier hin.


    Weiter gedacht kann man einen möglichen Arduino auf dem Hand-Controller komplett durch einen höherwertigen ESP-8266 oder vielleicht einen ESP32 ersetzen. Die Programmierung kannst Du ebenso in ArduinoStudio machen.
    Hier mal ein Beispielangebot:
    https://www.ebay.de/itm/ESP32-…m:mUL4FBrgCcKQv0toMU96Pfg


    Für den stationären Betrieb kann ich mir nichts besseres vorstellen. Bluetooth auf Windows ist nicht gerade ergonomisch.

  • Offene Steuerung mit Encoder und Autoguider

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
    <br />hi!
    so - wieder ein bisserl weitergebastelt. weil mir die beschränkung auf die industrieboards etwas limitierend vorkam, habe ich mir auch ein kleines treiberboard mit 2 DRV 8825 und einenm arduino mini pro zusammengesteckt, dass vom raspberry via SPI gesteuert wird. idee hier war ersteinmal, auch zwei focusermotoren in der software zu inkludieren - für die montierung ist der mini doch ein wenig brustschwach.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Wolfi,


    erstmal herzlichen Glückwunsch für die bisher absolvierten Entwicklungschritte. Gerade den hier dokumentierten Schritt halte ich für sinnvoll.
    Die Anregung kam ja primär auch aus dem schwarzen Forum
    http://forum.astronomie.de/php…tellen_-_TSC_#Post1282023


    Und das war auch bisher meine Anmerkung, daß der erste Aufsatz sich erstml zu stark auf eine Treiber konzentriert. Klar man muß auch irgendwo mal anfangen. Und ich denke, Dein Projekt ist auf einem guten Weg.
    Weiter so :)


    Hast Du nicht mal darüber nachgedacht, die UI in eine Weboberfläche zu packen?
    Auf dem Raspberry PI hast Du ja Ressourcen frei. Ein einfacher Webserver ist schnell installiert.
    Dann könntest Du Remote vom PC aus oder mobile Device auf die UI zugreifen.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    ich glaube eher, daß Problem steckt in Deiner Software. Ich kann mich z.B. nicht daran erinnern, mit dem Classic LX200 Treiber mit der FS2 oder auch der Gemini Pulsar ein Problem gehabt zu haben.
    Und auch an der OTE II Steuerung nicht. Also irgendwas machst Du falsch.
    Nur was?Tipp: Du kannst Dir über ASCOM ganz einfach Testskripte schreiben. Z.B. in Javaskript.


    Eigentlch sollte klar sein, daß der Onestep Treiber an Deiner Steuerung nicht funktioniert. Übrigens das Konzept der Onstep ist ja an vielen anderen Steuerungen auch im Prinzip umgesetzt. Der Microcontroller zeichnet sich für die Teleskopsteuerung verantwortlich (FS2, Pulsar I, II, Littlefood, und viele mehr). Der Teensy Microcontroller arbeitet mit einer sehr hohen Taktzahl.
    Und es läuft gut.


    Kritik am ASCOM-Standard hagelt es gerne von mir an der grundsätzlichen Architektur.
    Schlechter gehts nimmer. Da ist INDI echt der Zeit voraus gewesen.

  • Offene Steuerung mit Encoder und Autoguider

    Hi Wolfi,


    leider nein. Der Verdrahtungsaufwand ist ziemlich gering und auch bekannt. Obwohl ich den Ansatz interessant finde.
    Der Ansatz, den Arduino mit dem 8825 oder RAPS128 zu erwenden, wurde ja schon auf A.de diskutiert. Im Rahmen der Diskussion zum Software-Design.
    Aber die Onstep mit dem Teensy 3.2 leistet schon mehr. Und schließt die Verwendung eines PI natürlich nicht aus.
    Da läuft auch der ASCOM-Treiber. Ich favorisiere den Weg: Lieber gemeinsam etwas weiter entwickeln, als das Rad neu erfinden.
    Auch wenns Spaß macht, zu schrauben.
    Ich verfolge dennoch Deine Anstrengungen aufmerksam. Und finde Deinen Ehrgeiz lobenswert.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    ist ja nett, daß Du die Arbeit anderer als gebastel ansiehst. Bis lang war die Sache ja noch Sympathisch.
    Aber an der Stelle muß ma eigentlch das Diskustieren aufhören.
    Ich denke Du bist im Moment noch weit davon weg abschätzen können, worin der Mehrwert in der Blackbox Namens "Sitech" besteht.
    Im übrigen sogar unterhalb von 1000 Euro die fortschrittlichste Steuerung auf dem Markt.


    Schau Dir mal die Doku an.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    die Encoderauflösung auf der Montierungsachse sollte schon Sinn machen. Während für den visuellen Einsatzzweck vielleicht Auflösungen im Bogenmintuenbereich ausreichend sind und
    die Steuerung manuelle Schwenks dann erlaubt (EQ8 z.B.), dann ist das ok.
    Photographisch machen aber nur hochauflösende Encoder Sinn. Und da kannst Du mit den Dingern in Deiner Liste nicht landen.
    Solltest Du die Encoder via Übersetzung an die Achse anschließen. Freu Dich nicht zu früh. Dann hast Du i.d.R. den Getriebefehler des Vorgeleges zum Encoder im System.
    Damit kann man Guiding nicht umsetzen oder verbessern.


    Hier sollte man also auf hochauflösende Encoder setzen. Z.B. einen Gurley R158, Heidenhain ERN180 oder ERN480 und Renishaw.
    PRoblem bei den Dingern ist aber, daß man mit einem Iterpolation Error zu tun hat, den es zu kompensieren gilt.
    Herausforderung ist auch: Die Dinger sind intern Sin-Cos-Encoder und werden via Interpolation ausgelesen (vereinfacht: Aus dem Sin-Cos Signal wird eine Position ermittelt).
    Für diesen Zweck gibt es dann Interpolatoren, die wiederum ein RS422 A/B signal ausspucken. Der Gurley hat sowas "On Board".


    Was heißt das für die Steuerung? Man berechnet die Anzahlt der Ticks pro Gesamtumdrehung genau einmal und liest die aktuelel Position über die A/B Kanäle über anschließende
    Quadratur aus.


    Ich wrüde mal sagen: Bis dahin hast Du noch einige Hausaufgaben zu machen, denn das ist schon eine Herausforderung.


    Und das gibt es fertig: Sidereal Technologies Sitech Steuerung. Die unterstützt: Encoder an den Motoren (Servos) und Achsencoder.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    ich selbst mache beim Autoguiding keine Darks.
    DEC: bißchen backlash ist nicht schlimm. Gemessen hab ic es nie. Ich balanciere aber das Teleskop so aus, daß es ein wenig auf der Schneckenflanke schwimmt.
    DAs ist beim Guiding einfacher. Wenns zu stramm ist, isses auch nix.


    Tolles Projekt! :)

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Wolfi,


    die können maximal 2.6 A essen Es kommt auch drauf an, wieviel Strom Du da durch jagst.
    Selbst die SECM4 werden mit 2.8A angegeben (wenn ich mich recht erinnere), aber mit einem Phasenstrom von 1.8 Ampere (Pulsar Steuerung) laufen sie auch super gut.


    Ist doch beruhigend oder?

  • Offene Steuerung mit Encoder und Autoguider

    Nachtrag:


    Die Königsklasse mit absolutem Luxus, sowohl für Stepper als auch BLDC Motoren liefert Nanotec u.a. das hier:
    http://de.nanotec.com/produkte…op-schrittmotorsteuerung/
    Die kannst Du über UART3.3V ansteuern. Hab ich mal mit einem Beaglebone ausprobiert (NanoJ auf dem PC über Ser2Net auf dem Beaglebone), dann später Nachführung über die Timer-Klasse der C++ Boost Library.
    Dann bleibt es einigermaßen portable. Das Ding kann einiges. Nur: Für den Preis baut man schon dicke zwei Onsteps.

  • Offene Steuerung mit Encoder und Autoguider

    Hi Wolfi,


    weit bevor die RAPS128 für die Teleskopsteuerungen bekannt wurden, habe ich diese Treiber mit der Onstep verwendet.
    http://www.ebay.de/itm/FMD2725…26221?hash=item58c51b5a6d


    Für den Fall, daß dir der Phasenstrom zu gering ist. Die Dinger treiben meine G41 sehr ruhig an. Und da sind recht starke Motoren drinn.
    Es hängt also davon ab, welche Motoren Du wirklich brauchst. Und welche Getriebe.
    Der Vorteil der Onstep ist, daß man sie entsprechend konfigurieren kann. Im Code und auf der Hardware-Seite.

  • Offene Steuerung mit Encoder und Autoguider

    Hallo Koto,


    eine schöne Lösung. Doch ich denke, man muß hier auf den Anwendungsfall achten.
    "braucht also der Motor 313600 Mikroschritte für eine 360° Drehung des Teleskops. Ergibt: 360*60*60/313600 = 4,13."
    D.h. Deine Steuerung nebst Getriebe hat eine sehr grobe Auflösung! Das mag fürs Visuelle jau auch ausreichen. Der Auflösungsbereich in dem Igor und ich von Timingproblemen sprechen
    ist weit unterhalb von 1"/Schritt. D.h. hier hat man höhere Schrittfrequenzen.
    Das was Du mit Guiding bezeichnest, sehe ich unter dem Begriff "Tracking". Guiding ist etwas, was dem Tracking überlagert ist.