Offene Steuerung mit Encoder und Autoguider

hi!

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: universe</i>
<br />Das autoguideing ist dabei kein Problem.
Da brauchstu bestimmt kein RTOS, dass stimmt.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

will ich schon machen, aber in einem eigenen thread, d.h. motortreiber läuft asynchron auf einem eigenen core ... das ist auch jetzt schon so ...

"1. Das eigentliche guiding (nich autoguideing) möchtest du also nicht mit Raspi machen."
doch, aber es läuft getrennt vom restliche programm auf einem eigenen thread.

"D.h du wirdst nicht zu deine Motoren sagen wollen , step, step, step in einem genauen berechneten abstand, sondern du willst den Treiber sagen wollen, fahre vorwärts mit sterngeschwindigkeit.
Das ist schon mal gut. Bedeutet aber das die raspi keine Ahnung hat wo gerade dein Motor stehet."

ich muss einmal ein sync auf eine bekannte position (stern) machen, dann habe ich die lokale sternzeit. genauso wie z. B. beim LX 200 protokoll. das ist der zeitpunkt null, hier starte ich einen lokalen timer, der in der applikation läuft und an der uhr vom pi hängt ...

"Wie willst du dann wissen wo grade dein Motor steht?"

in dem moment auf dem objekt, auf das ich gesynct habe. dann sschaue ich regelmässig auf den timer, weiss, wieviel zeit vergangen ist ist, und sag dem motor fahr x schritte nach.

"Encoder auslesen?
Musst du aber andauer machen und da wird es wieder Zeitkritisch."

naja, meine eventqueue fragt derzeit 20x pro sekunde nach, was so anliegt. der encoder hat eine responsetime von ca. 20 mikrosekunden. er ist aber nicht absolut, sondern er kann dzt. nur überprüfen, wieviele schritte die endstufe wirklich gemacht hat.

" Sagen wir mal du sagst zu dein Treiber er soll 800 000 Mikroschritte vorwärts fahren um an eine bestimmte Position ran zu kommen.
Er macht diese 800 000 Mikroschritte und er wird nicht treffen!
Aus einfachen Grund, weil sich während diese 800 000 Mikroschritte die Erde ebenso gedreht hat und genau für diese Zeit liegt er daneben."

da brauch (egal ob RTOS oder nicht) einen timestamp und merke mir, wann das goto angefangen hat. dann fahre ich, und wenn ich fertig bin, schau ich, wieviel zeit seitdem vergangen ist, und fahr die strecke in rektaszension nach.

"Die Lösung wäre wieder Encoder, aber auch da wird es Zeitkritisch weil du die ganze Zeit nur am auflesen bist und keine Zeit um das schicke Display hast oder andere schicke dinge die noch dabei sind."

nein, weil das asynchron ist - das display, die kamera, der indiserver laufen auf anderen cores und wissen von den motoren nix, solange deren thread sich nicht mit einem signal (z. B: ich bin fertig) meldet.

timestamps brauch ich immer, das ist keine realtime, oder nicht realtime frage.

aber du hast schon recht, die frage der latenz ist gegeben. ich denke, dass kann man nur ausprobieren und schauen

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: Birki</i>
<br />hi!

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: universe</i>
<br />Das autoguideing ist dabei kein Problem.
Da brauchstu bestimmt kein RTOS, dass stimmt.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

will ich schon machen, aber in einem eigenen thread, d.h. motortreiber läuft asynchron auf einem eigenen core ... das ist auch jetzt schon so ...

"1. Das eigentliche guiding (nich autoguideing) möchtest du also nicht mit Raspi machen."
doch, aber es läuft getrennt vom restliche programm auf einem eigenen thread.

"D.h du wirdst nicht zu deine Motoren sagen wollen , step, step, step in einem genauen berechneten abstand, sondern du willst den Treiber sagen wollen, fahre vorwärts mit sterngeschwindigkeit.
Das ist schon mal gut. Bedeutet aber das die raspi keine Ahnung hat wo gerade dein Motor stehet."

ich muss einmal ein sync auf eine bekannte position (stern) machen, dann habe ich die lokale sternzeit. genauso wie z. B. beim LX 200 protokoll. das ist der zeitpunkt null, hier starte ich einen lokalen timer, der in der applikation läuft und an der uhr vom pi hängt ...

"Wie willst du dann wissen wo grade dein Motor steht?"

in dem moment auf dem objekt, auf das ich gesynct habe. dann sschaue ich regelmässig auf den timer, weiss, wieviel zeit vergangen ist ist, und sag dem motor fahr x schritte nach.

"Encoder auslesen?
Musst du aber andauer machen und da wird es wieder Zeitkritisch."

naja, meine eventqueue fragt derzeit 20x pro sekunde nach, was so anliegt. der encoder hat eine responsetime von ca. 20 mikrosekunden. er ist aber nicht absolut, sondern er kann dzt. nur überprüfen, wieviele schritte die endstufe wirklich gemacht hat.

" Sagen wir mal du sagst zu dein Treiber er soll 800 000 Mikroschritte vorwärts fahren um an eine bestimmte Position ran zu kommen.
Er macht diese 800 000 Mikroschritte und er wird nicht treffen!
Aus einfachen Grund, weil sich während diese 800 000 Mikroschritte die Erde ebenso gedreht hat und genau für diese Zeit liegt er daneben."

da brauch (egal ob RTOS oder nicht) einen timestamp und merke mir, wann das goto angefangen hat. dann fahre ich, und wenn ich fertig bin, schau ich, wieviel zeit seitdem vergangen ist, und fahr die strecke in rektaszension nach.

"Die Lösung wäre wieder Encoder, aber auch da wird es Zeitkritisch weil du die ganze Zeit nur am auflesen bist und keine Zeit um das schicke Display hast oder andere schicke dinge die noch dabei sind."

nein, weil das asynchron ist - das display, die kamera, der indiserver laufen auf anderen cores und wissen von den motoren nix, solange deren thread sich nicht mit einem signal (z. B: ich bin fertig) meldet.

timestamps brauch ich immer, das ist keine realtime oder nicht realtime frage. aber du hast schon recht, die frage der latenz ist gegeben. ich denke, dass kann man nur ausprobieren und schauen

lg
wolfi
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: universe</i>
das hast du nicht sobal du es mit lx200 machst, ein sync gibt ihr nur die RA und DEC des Objekts.
Was statisch ist. An HA (Hour Angle) kommst du damit nicht ran.

Der einzige Befehl der dir die Lokale Siderische Zeit liefert wäre :SSHH:MM:SS# und diese kannst du nicht anfordern oder erfragen und wird mit wenigen Astro Programme mitgeschickt.

<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

hallo!
naja, also ich stell immer einen stern ein, dann fragt mich z. B. cartes du ciel brav, ob das teleskop auch wirklich dort ist, und dann setze ich ein sync ab.
- zu dem zeitpunkt (t0) habe ich eine position, und schalte die nachführung ein. ich habe also zu t0 eine relative position, nämlich stundenwinkel = 0 und deklination = 0;
- die nachführroutine schaut, wieviel zeit seit t0 vergangen ist und führt dementsprechend in RA nach; das macht sie sehr oft (20x por sekunde dzt).
- dann mach ich zu t1 ein goto, z.B 5° in RA und 5° in dekl. ich stell die nachführung ab, lass die motoren drehen (ich weiss auch, wie lang die brauchen, weil ich rampe und geschwindigkeit kenne) und fahre dorthin. jetzt ist das teleskop dort, wo das objekt zu t1 gewesen wäre. ich messe wieder die zeit = t2.
- ich fahre die differenz t2-t1+dauer der nachführung in RA nach und messe, ob dieser zeitpunkt (t3) auch der ist, wo mir der motor sagt, dass er fertig ist , oder ob ich weiter korrigieren muss.
- ich beginne von vorn und schalte die nachführung wieder ein.

ganz im vertrauen - so wird das in allen steuerungen, die ich kenn, gemacht. die frage ist, wie genau die systemuhr ist - hier sollte ich laut posix standard zumindest 1/60 sekunde auflösung haben.
lg
wolfi

hallo!

ja, klar, natürlich helfen dir position und uhrzeit, und alignment ist nocheinmal eine andere sache, ich geh ersteinmal von einem festaufgestellten eingescheinerten fernrohr aus.

das entspricht dann deiner variante 1. in dem moment, wo du so einer steuerung sagst, wo sie gerade hinschaut und du dich "auf null" stellst, weisst du wo du bist solange du die steuerung nicht abschaltest, weil du weisst, um wieviel du dich beim goto bewegt hast und wieviel zeit vergangen ist. die nicthbetrachtung der nachführungsbewegung ist in dem fall natürlich nicht sehr sinnvoll, ich versteh auch nicht, warum man das ignorieren sollte.

deine variante 2 ist für mobile geräte natürlich sinnvoll, geht aber darüber hinaus.

ich werde einmal mein kleinfernrohr anhängen und dann über die erfahrungen berichten

lg
wolfi

hallo!

ja, schon. nur was hält mich davon ab, deine frage aus zeile drei ist ganz einfach zu beantworten:
"Sagen wir mal dass die RA nach sync 18h 36m 56s war. Jetzt läuft die montierung 5 minuten lang.
Wie ist RA nach diese 5 Minuten?"
sind wir noch ein bisserl grosszügiger: das sind 279.2333°
- 5 minuten später sollten das 280.4833° sein - je nach händigkeit.
ich muss also in den 5 minuten die stundenachse um 1.2503° vor- oder zurückdrehen. nehmen wir an, mein stepper habe 1.8° steps und 1/8 mikroschritte, ein planetengetriebe mi 1:27 und eine schnecke mit 1:144:
dann muss ich in der zeit 21607 microsteps machen, wenn ich mich nicht verrechnet hab, sind das 72 microsteps /sekunde ... das schreckt mich noch nicht ...
lg
wolfi

hallo!
aso, ja, natürlich ... die kommunikation muss man dann halt in LX200 prtokoll machen
lg
wolfi

hi!
wär ja cool, wird auch dokumentiert, dass es von dir ist. ich hab in der richtung noch nix gmacht und habe mir die INDI-seite bei der LX200 noch nicht angeschaut, etwas anschauungsmaterial wär auf jeden fall nett

lg
wolfi

servus!
hat der steffen schon angelegt - https://github.com/selste/TwoStepperControl
lg
wolfi

hi! gestern standen wir am abgrund, heute sind wir wesentlich weiter ... hoffen wir auf gutes wetter am wochenende, dann probier ich amal die reine nachführung aus. stundenmotor läuft scheinbar konstant im asynchronen thread mit 92.26 microsteps/s
lg
wolfi

hi! mitm wochenende wirds nix ... da bastel ich halt im wohnzimmer weiter. man sieht in grauslicher qualität:
- 2 schrittmotoren aus der wühlkiste, einer läuft ständig (RA), der andere nur auf wunsch.
- eine qhy 5 am INDI server
- laden von katalogen. auslastung der CPU geht auf 300%, ein bisserl was geht also noch
- der raspberry wird ordentlich warm
- das gui lüft hier am monitor, nicht auf dem kleinen 3.2" touchscreen

lg
wolfi

hi! das ist schon mikroschrittbetrieb - der kleine ist nur mit viel zu viel strom gefahren
die steuerung kann 16 mikroschritte, und mit anderen motoren die nicht einfach am tisch liegen,
macht sie das auch etwas leiser
lg
wolfi

servus michael!

erstens einmal freut es mich sehr dein und igors interesse an dem thread sehr - input von erfahrenen leuten ist mir wichtig und ich bin auch diskussionsbereit

also - das board, das ich verwende, ist folgendes:
http://www.phidgets.com/produc…gory=13&product_id=1067_0
man sieht die 2 dinger auch auf dem video.

das hat einen microcontroller, der seine befehle (anzahl der schritte, beschleunigung, geschwindigkeit) über USB bekommt. der pi steuert also keine schrittmotoren, sondern das board. er ist allerdings doch so schnell (1.2 GHz), dass er recht gute timerauflösung hat (ich habe eine monotone unix-clock laufen, die liefert schon mikrosekunden). die motoren werden in eigenen threads gestartet, d.h. die einzelnen boards "leben" parallel. daher auch die auslastung mit 300 %, wie in dem terminal mit top zu spitzenzeiten ersichtlich. INDIserver und 2 motoren belegen dann 3 der 4 cores von dem ARM.

bzgl. der mikroschritte - das ding ist, was es ist. wenn man mit den mikroschritten raufginge, geht halt auch das haltemoment ordentlich runter (oder?). egoistischerweise will ich einmal mein eigenes fernrohr damit antreiben - das hat ein rad mit 288 zähnen und ein 1:9 planetengetriebe vor dem stepper. damit habe ich eine geschwindigkeit von 96.26 1/16 microsteps/s. das ist schon recht wenig. ich weiss nicht genau, was meine littlefoot vpower macht - es lässt sich auch nicht mehr so genau nachvollziehen und ist eh wurscht - aber die läuft sicher nicht kontinuierlich sondern tickert.

bezüglich des geratteres von dem kleinen stepper - das ding habe ich in der wühlkiste gefunden, das ist ein vexta PX244 und nicht als antriebsmotor gedacht. ich habe nanotecs im fernrohr. ich sollte ihn auch nicht mehr mit mehr als 0.8 A betreiben

bzgl. RA & stundenwinkel: ist mir schon klar, ich habe physik studiert und kann sphärische triginometrie

zu meiner motivation:
- wie eingangs geschrieben sehe ich das ende der vpower kommen, wenn ich nicht mehr parametrisieren kann. ausserdem hat sie einen bug (ein st4 eingang geht nicht). soll so sein, is mir wurscht.
- ich will das irrsinnige gewurschtel mit guiding via laptop, 1000 RS232/usb/st4 adaptern, verschiedenen ASCOM versionen am laptop nicht mehr.
- ich will nicht mehr zum laptop rennen müssen, um zu sehen , ob ich wirklich einen leitstern hab und ob er fokussiert ist.
- ich brauch dicke motoren. die littlefoot muss auch mit kühlkörpern und lüftern versehen werden, sonst dreht sie sich nach 3 sekunden mit dem thermoschutz ab.

die onstep wäre durchaus interessant und scheint ja ganz ok zu sein. ich hätt das guiding halt auch gern dabei

und wenn ich fertig bin, bau ich mir eine bluetooth handbox dazu

lg
wolfi

hi!

muss mich korrigieren - drehmoment -
mangels genauerer lenntnisse habe ich mich darauf verlassen - http://static.micromo.com/medi…/6_Microstepping%20WP.pdf

aber wie gesagt, ich bin eh auf die 16 mikroschritte festgelegt mit dem phidget board ...

lg
wolfi