Offene Steuerung mit Encoder und Autoguider

hi!
ich habs eh schon vor ein paar wochen angesprochen. ich hab ja eine littlefoot für mein grossfernrohr und bin eigentlich auch glücklich damit, nur ist der support dafür ein wenig ... naja, sagen wir mal eingeschlafen. wie dem auch sei, ich hab ja noch immer ein seit 5 jahren auch etwas statisches selbstbauprojekt, das ich gern beenden würde, und dafür würde ich für guiding/steuerung/andere blödheiten gern den laptop loswerden (bei mir am grossen fernrohr besorgen das phd - guiding, ein shoestring adapter, die littlefoot vpower etc. pp.).

und deshalb hätt ich gern alles auf einmal in klein, mit encodern, und zwar so dass es der C++ kundige nicht-elektroniker auch dafür entwickeln kann. wenn ich da grad das rad neu erfinde, sagts mir bitte bescheid (und nein, ich werd nicht mit einem arduino herumkämpfen ...)

mein vorschlag wäre daher C++ mit verwendung von qt als entwicklungsumgebung auf raspian mit einem raspberry pi 3; die encoder und schrittmotorendstufen habe ich von http://www.phidgets.com (http://www.phidgets.com/docs/1047_User_Guide für das Encoderinterface und http://www.phidgets.com/produc…gory=13&product_id=1067_0 ). die schrittmotorendstufe ist sicher etwas teurer (100 €), es gibt aber auch ein kleineres board für 4 unipolare motoren. das interfacing erfolgt über usb, und die programmierung hab ich ausprobiert.

an zwei verregneten nachmittagen habe ich jetzt also einmal die toolchain zum kompilieren am raspberry aufgebaut und hab ein kleines video gemacht - das 3.2" display ist sicher zu klein fürs guiden. im moment hängen ein motor und ein encoder dran, kamerasupport mach ich noch. im moment kann man nur die rampe, die maximale drehgeschwindigkeit und die anzahl von mikrosteps einstellen (also 0.1125°/s², 0.1125°/s und 1/16*1.8° steps für den motor). der encoder gibt derzeit 6 bogenminuten heraus, da muss man auch schauen, was es sonst noch gibt)

da ist das video - mein zwergdackel ist herumgelaufen, daher das geklimper: https://www.youtube.com/watch?v=7Argsy_nbnQ

natürlich kann man argumentieren, dass C++ ein overkill ist, aber meine erfahrungen im job haben gezeigt, dass mikrocontroller auch ihre grenzen haben. ganz nett ist auch, dass mein mein programm aynchron läuft, d.h. der encoder wird genaus wie ein zweiter motor asynchron betrieben, und das geht mit der kamera auch ...

also - was denkts ihr? gute idee oder rad-neuerfindung?

lg wolfi

<font color="limegreen">Aus dem ATM-Optikforum verschoben von Caro</font id="limegreen">

hallo!
ersteinmal danke der caro fürs verschieben - ich hab den beitrag mit schon sehr kleinen augerln zuerst ins optikforum getellt. ich hab mir noch ein paar mehr gedanken gemacht, nachdem ich meine steuerung fürs stationäre teleskop wieder unter grossen leiden in betrieb genommen hab mit neuem betriebssystem; meine erfahrungen waren:
- nicht einfach, V4control noch einmal zum laufen zu kriegen unter windows 7 (ActiveX Komponenten von anno fuffzehn werden da dringend benötigt). andere chance hab ich aber nicht, in meine littlefoot vpower zu schauen, aus bekannten gründen.
- nicht einfach den rs232 adapter noch einmal zum laufen zu kriegen.
- wiederinbetriebnahme der alccd5 ... KATASTROPHE. hardwarentwickler sollten keine software schreiben, weil dann kommt sowas dabei heraus (http://www.zen81542.zen.co.uk/…HY5%20install%20notes.pdf - wobei man sagen muss, jetzt tut sie ja). ich finde ASCOM ja gut, obwohl ich auch nicht versteh, wieso ich die funktionalität, meine sternwartenkuppel robotisch zu öffnen installieren muss für a blöde mini ccd kamera.

in summe muss ich sagen, dass das installieren der treiber etc. nicht weniger komplex war als den qtcreator mit diversen ARM -libraries aufm raspberry zu starten.

das jetzige setup wird die nächsten jahre auf einem kleinen windows 7 rechner in der sternwarte eingefroren, alle updates werden beharrlich verweigert, und wenn irgendwas hin wird, wars das.

daher bin ich um so entschlossener, das ganze selber in die hand zu nehmen. hier nun meine idee:
- 2 bipolare oder 4 unipolare motoren (was spricht eigentlich gegen unipolare motoren, die schneckentriebe haben ja eh genug haltemoment?)
- brauchen wir zusätzlich noch DC-motoren für fokus oder so?
- encoder auf wunsch, wobei man sich deren genauigkeit anschauen muss (ich bin halt von den phidgets hier abhängig, ich kann keine elektronik machen).
- das softwaremodell: es gibt eine SD-karte bzw. ihr image, auf der ist die entwicklungsumgebung (qtcreator, gcc, libraries, INDI, raspian), das image darf jeder haben (ich bin ja nicht mr. littlefoot) und kann damit machen, was er will. updates der raspberries müssen halt portiert werden (das ding kostet eh nur 40 € ....)
- das hardwaremodell: genutzt wird der HDMI ausgang fürs display, weil die touchscreens wie der in meinem video zwar lieb sind, aber zuviel vom GPIO bus wegnehmen. was mich zum nächsten problem führt.
- die schnittstellen: ich will ST4 und LX200, der rest ist mir wurscht. braucht man eine RS232 (wenn ich mir cartes du ciel anschau fürcht ich fast, ja)? man braucht ein paar digitale IOs, weil ich die ST4 direkt und auch endabschalter implementieren möchte. sollte die steuerung bluetooth und TCP/IP zumindest anbieten? kameras über INDI, USB oder gorned, würd ich sagen ...

kurz gesprochen - mir ist der derzeitige zustand - steuerung hier, guider da, laptop mit windows 7, usb-auf-ST4 adapter etc. pp. zu komplex und zu nervig, und ich will eigentlich nur mein zugegebenermassen mit 80 kg etwas dickes rohr mit einer planetariumssoftware steuern und mit einer webcam guiden. und ich seh im moment auch nicht allzuviele steuerungen auf dem markt, die mein bedürfnis (2 ziemlich grosse schrittmotoren zu einem diskutablen preis treiben) decken. mein vertrauen in proprietäre lösungen ist vor allem im hinblick auf die littlefoot schwindend, und wenn wir uns ehrlich sind - kommerzielle entwicklungen sind kostenintensiv und zahlen sich wahrschienlich nicht wirklich aus ....

no - was meints ihr?

lg
wolfi

servus steffen!
ja, das unipolare board ist ein bisserl klein. ich muss einmal schauen, wie das mit der eingangsspannung an dem grossen board ausschaut - da wollens 10-30v, meine nanotecs wollen aber nur ~5 v. auf der anderen seite fahr ich in die littlefoot auch mit 12 V rein (glaub ich).
phython is gut, aber am ende des tages gehts mitm qtcreator auch recht gut, wenn man ein paar spumpanadln am pi behebt. c++ ist halt c++, und der code lässt sich problemlos von ubuntu auf den pi transferieren - der cross compiler von ubuntu macht hingegen nur probleme. ich mach jetzt einmal ein programm, dass 2 stepper asynchron treibt, dann schau ich weiter.
lg wolfi

hi!
ja, genau so, man siehts ja im video. in meinem erstling läuft das aber in einem QtConcurrent thread, d.h. die applikation lebt weiter ...
lg
wolfi

hallo! cross-compiling geht gut, solange man sich nicht aus der comfort-zone bewegt, also nix komisches macht wie die phidgets lib einbinden etc. ich finde es auch ganz charmant, die umgebung direkt am pi zu haben. ich melde mich auf jeden fall, wenn 2 motoren laufen
lg
wolfi

servus martin!

"Schön, dass Du wieder im Astrotreff dabei bist!"

danke und ja, weisst eh, die zeitzyklen des hobbyoptikers sind ein bisserl länger - ich hab mit 12 meinen ersten spiegel gemacht, der war kaum 12 jahre später im fernrohr, da hab ich den houghton 1996 angfangen, der war 2010 fertig ... ich hab also noch zeit fürs brachymedial bis mindestens 2022 ... dafür hab ich zumindest einen sohn durch die matura gebracht, meinen vater beerdigt und mit meiner frau, einem freund und dem maturasohn eine von wiens erfolgreichsten instro-surfbands geründet!

"Vor kurzer Zeit hab ich mir für den Raspi den Original 7" LCD mit
Touchpad zugelegt, der über die interne Monitor-Schnittstelle angeschlossen wird und daher keine IO-Pins belegt.
Dieser Monitor ist recht komfortabel ..."

der ist ok, es gibt aber auch kleinere hdmi-monitore z. b. von adafruit. ich denke, man kann mit dem touchpad auskommen, ich programmier ja das GUI eh selber und will das raspian dahinter garnicht sehen...

"IO-Erweiterung sollte z.B. über I2C bei Bedarf keine große Sache sein."

ich kan auch über die phidgets gehen, das basismodul ist eine 8x i/o digitalschnittstelle mit einem 8x 10bit ad wandler ... das teil kostet aber auch geld, und eigentlich braucht mans ja nicht weil eh der GPIO bus da ist ...

"RS232 kannst Du entweder per USB-&gt;RS232 einbauen, oder den im Raspi integrierten seriellen Port über die IO-Pins verwenden, ggfs. mit einem einfachen Pegelwandler."

es gibt auch einen RS232 für den pi direkt, die frage ist eher - wollen wir das? gibts ecterne software, die den unbedingt braucht, wenn ich eh ethernet und bluetooth on board hab? USB-&gt;RS232 wandler will ich eher nicht, ich will eben weg von dem irrsinnigen schnittstellen-gebastel (usb auf st4, usb auf rs232 etc. pp.) wie ichs jetzt grad hab.

"Den grundlegenden Ansatz, lieber einen etwas leistungsfähigeren Rechner zu verwenden, finde ich hier sehr sinnvoll. Der Aufwand liegt hauptsächlich beim Programmieren, die Hardwarekosten sind heutzutage kaum der Rede wert."

es ist halt so - ich kann ganz gut programmieren, aber ich bin kein elektroniker. und wenn ich ehrlich bin - ich hab in der arbeit grad so einen fall - ich halte auch nix von lösungen, wo mikrocontroller mit 3 rechnern, die halt grad irgendwas können, kommunizieren. ich bin ganz happy, wenn ich ein interface hab, das mit meinem compiler redet - und aus. die phidgets sind sowas, es ist echt nett und halbwegs ausgereift - das zeug gibts seit 15 jahren...

"Falls Du eine geeignete Guiding-Kamera findest, die Du am Raspi betreiben kannst, könnte der Raspi bis auf die Verarbeitung der eigentlichen Aufnahmen alle anderen Aufgaben komplett übernehmen!
Das ist wohl nur eine Frage der passenden Treiber; USB2 sollte für eine Guiding-Kamera ja wohl auch für die Bilddaten-Übertragung genügen"

naja, da bin ichs halt durchgegangen. usb2 (webcam und analogframegrabber) sind trivial, der rest muss über INDI gehen, sonst seh ich da keine chance.

"Mit einem Arduino "rumkämpfen" müsstest Du nur, wenn Du das gesamte Projekt in so ein Teil reinzwängen wolltest."

nein, das find ich nicht. der pi sollte das, was ich will (autoguiding, steuerung und LX200 interface zu einer planetariumssoftware) können. er hat 4 cores, 1 GB ram - das reicht fürs meiste ....

"Das würde ich nicht tun. So nahe an der Hardware zu programmieren, ist in Zeiten der Steppermotoren mit USB-Interface auch nicht mehr wirklich nötig."

find ich auch ...

"Es hat ja schon mehrfach Ansätze gegeben, eine Open Source Teleskopsteuerung auf die Beine zu stellen. Auch hier im Forum gabs mal einen Thread dazu, immerhin bis zum professionell designten Steuerplatinen-Prototypen."

ich weiss, ich war anfangs sehr angetan, hab dann aber original nix mehr gemacht dafür

"p.s. Ich erinnere mich dunkel an einen spannenden Selbstbauoptik-Thread von dir vor ein paar Jahren. Was ist eigentlich aus dem Brachymedial-Projekt geworden?"

2022? ist jedenfalls noch alles da, inkl. einer selbstgebauten montierung, die ich vielleicht zum leben erwecken kann

lg
wolfi

hi! kurze technische frage - es ist bald 1 in der früh und ich muss ins bett - hat wer schon einmal einen INDI-Klienten gebastelt? ich hab das tutorial zum laufen gebracht aber ich häng grad bei der einbindung total und brauch a bisserl C++-hilfe

... aber immerhin rennt die Alccd 5 schon am pi, in kstars sehe ich sie

lg
wolfi

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
<br />
ist zwar schon lange her bei mir ... aber wo klemmt es denn gerade?
Gruß,
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

... ich bin zu blöd, den &lt;unique_ptr&gt; schas aus dem beispiel zu lösen, und der creator sagt, er will das nicht - u got mail ...
lg
wolfi

... dieser mann ist ein schatzi! ich meld mich, sobald die alccd5 laut gibt - der ccd-simulator geht lg wolfi

hi!
habs mir angeschaut, sit herzig; aber ich will halt weg von dem schnittstellenirrsinn; mir schwebt noch immer ein kasterl vor, mit LX 200 für die planetariumssoftware, von mir aus ST4, und der rest ist onboard, also guider & motorensteuerung.

dazu gleich eine frage - braucht man encoder? hochgenaue direktencoder kann ich mit der phidget schnittstelle eher nicht lesen und vor allem kann ich sie mir nicht leisten, wenn ich sie an die achse hängen wollte. meiner meinung machen sie nur direkt am motor sinn, um die genauigkeit der endstufe zu kontrollieren und gefallene steps zu kompensieren (beim goto z. B.). allerdings brauchen sie auch gar nicht so wenig strom

lg
wolfi

so ... qhy5 rennt wieder ... ich darf vorstellen: INDI aufm raspberry, zeigt den schatten eines radiergummis auf dem chip (mangels optik kann ich nicht mit eindrucksvolleren bildern aufwarten). youtube video mit bild vom kleinen touchscreen gibts hier:
https://youtu.be/Wwys-VfzK34

lg
wolfi

hallo!

naja, wie direkt sind deine direktencoder? 1:1 von der achse, dann müssten sie 130 000 steps für 10" genauigkeit haben; wenn man sie z. B. mit einem reibrad mit 200 mm durchmesser auf eine 8 mm achse überträgt, brauch ich dafür auch noch ~ 5000 steps. bescheide ich mich mit 1' genauigkeit und einem reibrad von 10 cm durchmesser auf 8 mm brauch ich noch immer ~1700 steps. oder ich nehm ein getriebe, aber das macht mir vermutlich den vorteil des direkten asnetzens des eoncoders auf der achse zumindest teilweise wieder kaputt.

mein grosses baby mit seinen 300 - 400 kg bewegter masse hat keine encoder, und dank grosser untersetzungen und kräftiger motoren geht das goto auch ohne encoder gut. wenn man probleme damit hat, schritte zu verlieren, dann hilft einem ein encoder auf der motorachse schon, aber das sollte halt eigentlich nicht passieren ...

lg wolfi

hi!
soooo ... kleinen parser geschrieben, jetzt habe ich als katalog 400 Bright Stars, Messier, Caldwell, NGC, IC und Herschel 400 aus konfigurierbaren .csv-dateien. brav ist der kleine raspberry, er haut sich den NGC in &lt; 2 sekunden ins hirn und liest dabei tapfer 1 s exposures von der QHY5 ein. jetzt muss ich nur noch das kamerawidget so umbauen, dass man gscheit reinklicken kann um einen leitstern zu markieren, und dann werden die stepper angehängt und parametrisiert

lg
wolfi

hi!
kein problem, glaub ich bis dato; ich lass mich gern eines besseren belehren, aber mit 4 cores kann ich immer mehr machen als 1 mikrocontroller
lg
wolfi

hi!
naja - für was? zum treiben der motoren sicher; ich werd auch keine choppersignale über die digitalen ios schicken (da würde der gute pi in sekunden in flammen aufgehen). dafür hab ich aber einen microcontroller, der sitzt auf dem treiberboard für den motor. dem mikrocontroller schicke ich nur, wie weit ich fahren will.

fürs reine guiding seh ich das etwas entspannter. klar muss ich regelmässig ein paar schritte ans die steuerung schicken, aber nicht im 1 ms takt mit 1 ms latenz (meine steuerung z. B. tickert so 2 mal pro sekunde). und genau da helfen mir die 4 cores schon, weil ich einen genau für die aufgabe abstell, und der macht sonst nix - ohne threading wäre das schwierig, da hast recht.

wenn das guiding so echtzeitkritisch wäre, dann könnte niemand mit PHD o. ä. autoguiding machen; überleg einmal: kamera hat 1 s oder mehr expositionszeit, schickt frame zum rechner (USB); ASCOM oder INDI empfangen das, schicken das dann über den localhost an den internen socket vom PHD, das stellt das dar, macht ein bisserl processing, schickt das ergebnis der korrektur via USB an einen shoestring adapter, der schickts im fall meiner littlefoot vpower dann zur ST4 schnittstelle. das geht sicher nicht in einer millisekunde.

aber du hast schon recht, ob die steuerung nicht zuviel latenz aufbaut wird interessant. im moment (im trockenbetrieb) kann ich eine motorenendstufe betreiben und gleichzeitg auf einem 2. core indiserver, ccd-akquisition etc. laufen lassen. dann ist der pi laut top bei 205% auslastung (d.h. 2 der 4 cores sind permanent beschäftigt, 2 habe ich noch frei - kritisch wirds, wenn ich mich den 400% annähere...)

time will tell

lg
wolfi