Beiträge von MartinB im Thema „Selbstbausteuerung mit open source fw?“

Michael,
als potentieller Interessent und Nachbauer einer Selbstbausteuerung möchte ich mich hier mal kurz melden.

Leider reichen meine vor vielen Jahren erworbenen Kenntnisse hint' und vorn nicht, um euch aktiv bei der Firmware- oder Softwareentwicklung zu unterstützen. Daher kann ich für das Projekt in der jetzigen Phase nur sehr begrenzt von Nutzen sein.

Die Idee, erst mal mit einer kleinen Variante auf AVR-Basis zu starten, finde ich sehr gut. Die Treiberplatine hat ja schon einen hervorragenden Eindruck gemacht. Es wäre schade, wenn die nun lange nicht zum Einsatz käme.

Darren Hutchinsons Steuerung scheint ja vom Aufwand her durchaus geeignet, eine quick-and-dirty-Zwischenlösung zu bauen.

Ohne nennenswerten Anpassungsaufwand wird das aber nicht gehen:
Die Lowlevel-Ansteuerung der Portbits fällt natürlich weg, dafür müssen die Stepperkommandos für die Treiberplatine geeignet übersetzt werden.
Eine Neuprogrammierung der Lowlevel-Treiberroutinen wird dadurch nötig sein, ebenso die Implementierung einer geeigneten Schnittstellenroutine. Es werden jede Menge Portbits frei.

Hardwareseitig wäre eine Prozessorplatine fällig, die nach außen zumindest ST4, RS232 und Handbox-Interface bieten sollte. Leider kann man wohl die EQ6-Steuerbox nicht einzeln nachkaufen. Daher müssten wir uns einigen, ob wir eine "dumme" Handbox unterstützen oder eine mit integrierter CPU und serieller Übertragung, und welche bzw. woher wir die nehmen. Das Handbox Elektronik- und Mechanikdesign könnte ja auch jemand ohne spezielle µC-Kenntnisse bewältigen.

Nachdem kleine CPUs nur noch ein paar Cent kosten, wäre eine einfache Prozessor-Handbox sicher das Beste, weil sie nur 3-4 Kabeladern bräuchte. Das wär dann genau das Richtige für ein kleines AVR-Einsteigerprojekt, denke ich.
Zunächst nur unidirektionale Datenübertragung und mit 6-8 Tasten, als Erweiterung evtl. bidirektional und ein paar Status-LEDs. Später aufbohren mit Display zur Positionsanzeige ginge dann immer noch.

Vielleicht kann mal jemand die zu erledigenden Aufgaben ("Gewerke"?) auflisten. Dann melden sich vielleicht eher Freiwillige, die Teilaufgaben in Angriff nehmen.

Habe ich das eigentlich richtig verstanden, dass bei Darren Hutchinsons Steuerung ebenso wie bei der original EQ6-Steuerung komplett auf Beschleunigungsrampen verzichtet wird? So wird natürlich nur ein Bruchteil des Leistungspotentials der Treiberplatine ausgenutzt.

Gruß,
Martin

Hallo Leute,
Wenn das Projekt tatsächlich ein Erfolg wird, finden sich zwangsläufig Interessenten, die sich zur Erzielung von Einkommen daran beteiligen wollen. Das finde ich völlig in Ordnung, solange der geforderte Preis in vernünftiger Relation zur erbrachten Leistung steht.

Die Frage ist auch, ob man einen Nachbau komplett verhindern kann. Kommerzielle Produkte nutzen den Kopierschutz des Programmspeichers, d.h. es ist nicht mehr ohne Weiteres möglich, das Gerät einfach zu kopieren. Das ist bei einem Open-Source-Projekt natürlich ausgeschlossen.

Was spricht prinzipiell dagegen, hier in Gemeinschaftsarbeit entwickelte Komponenten kommerziell herzustellen, <i>solange die gesamte Dokumentation beigfügt wird</i>, d.h. alle Schaltpläne und Layouts und alle Sourcen für die Firmware und Software?
Ich finde, es wäre langfristig sogar der Idealfall, wenn sich eine Firma darum kümmern könnte, sowohl fertig aufgebaute Module als auch Leerplatinen und Bauteilesätze anzubieten. Allerdings darf es dann auch keine Exklusivität geben; der Preis muss schon so kalkuliert sein, dass genügend Kunden sagen "selbst machen lohnt nicht".

Aus Sicht der Anwender ist das Hauptproblem ja wohl, dass bisherige kommerzielle Lösungen oft zu unflexibel sind. Für die Anbieter lohnt sich mehr Entwicklungsaufwand nicht, weil spezielle Lösungen in zu geringen Stückzahlen nachgefragt werden. Genau hier hat Open Source Vorteile, denn die Eigenleistung der Entwickler macht spezielle Projekte überhaupt erst möglich. Die modulare Struktur verhindert dabei, dass das Rad jedesmal neu erfunden werden muss.

"Geschlossene" Module als Alternative zu den Open Source Versionen anzubieten könnte natürlich auch eine Alternative sein, warum nicht?
Ein Problem für kommerzielle Anbieter von Modulen sehe ich aber in der Gewährleistung. Wenn jemand ein Treiberstufen-Modul liefert und das Teil beim Kunden abraucht, kann die Ursache auch in der Firmware liegen oder in einem anderen Fehler außerhalb des Treibermoduls.
Ist die Schaltung des Treibermoduls offengelegt, kann ich als Kunde die Fehlersuche selbst betreiben. Ist das Modul "geschlossen", bin ich auf den Support und im Zweifelsfall auf die Kulanz des Herstellers angewiesen.
Und dann ist da noch die Sache mit der CE-Konformität, über die wir als Selbstlöter meist einfach hinwegsehen...

Gruß,
Martin

Hallo Leute,
eine Modularisierung der Antriebstreiber halte ich auch für extrem wichtig. Gerade hier bietet sich die Möglichkeit, die Steuerung auf individuelle Bedürfnisse anzupassen.
Als Basismodul wäre sicher eine Platine mit zwei Schrittmotortreibern kleinerer Leistung sinnvoll. Zumindest zwei solcher Module sollte man ansteuern können, damit kann eine Luxusversion dann Derotator und Motorfokus ansteuern. Nächster Schritt wäre eine Platine für höhere Leistung, die optional Encoder unterstützt. Spezialversionen mit Servotreiber oder Direct Drive könnten später folgen.

Die Ansteuerung sollte per Übertragung einfacher Parameter erfolgen, z.B. schreibend Drehrichtung, Geschwindigkeit, Motorstrom und lesend Status und aktuelle Istposition. Fürs Goto evtl. noch schreibend die Zielposition.

Beschleunigungsrampen sollten die Module bereits selbständig beherrschen. Ob man das Backlash auch schon intern berücksichtigt, müsste diskutiert werden.

Ich fürchte, man wird bei so einem Konzept keine Spezial-ICs direkt an die interne Schnittstelle hängen können, sondern es dürfte minimal ein kleiner Zusatzprozessor nötig werden, der zumindest das Übertragungsprotokoll bereitstellt. Dann wären aber spätere Erweiterungen oder neue Motortreiber sehr leicht einzupflegen, und die Mehrkosten dürften minimal sein.

Der Steuerprozessor der nächsten Ebene hätte nun die Aufgabe, die Koordinatentransformationen, Autoguiding und PEC durchzuführen und die Hardware korrekt anzusteuern. Hier könnte man andere Komponenten wie Handbox mit Richtungstasten und ST4-Schnittstelle anschließen, und auch die Schnittstellen zum PC gehören hier hin.

Weitere Level wie die Verarbeitung von RA+DEC "Echtkoordinaten, automatische Ausrichtung, interner Objektkatalog könnten je nach Prozessorleistung ergänzt werden, wie auch eine Handbox mit Grafikdisplay. Möglicherweise könnte die Prozessorplatine auch in verschiedenen Leistungsstufen entwickelt werden, falls das eine nennenswerte Kostenersparnis bei der "kleinen" Variante bringt.

Mein persönlicher Wunsch wäre übrigens eine Steuerung, die auch Intervalltimer-Signale für eine DSLR-Kamera generieren kann.
Mobil möchte ich nämlich mit möglichst klienem Gepäck unterwegs sein.

Wer sich dann richtig austoben mag, könnte auf dieser Basis gar eine private Himmelsdurchmusterung oder zumindest einen Mosaikscan eines großen Objekts programmieren - welche kommerzielle Steuerung kann das schon?

Gruß,
Martin

Hallo Leute,
nachdem ich die Diskussion hier schon länger verfolge, möchte ich mich mal aktiv einmischen. Wer sich jetzt wundert "was will der Typ mit seinen Dobsons mit einer Selbstbausteuerung anfangen?": Ich denke seit einiger Zeit darüber nach, in Zukunft auch mal in die Fotografie einzusteigen, zunächst mit kleiner Öffnung. Auf halbe Sachen habe ich aber keine Lust, dafür umso mehr auf Selbstbau.
Meine eigenen Fähigkeiten beschränken sich auf vor 20 Jahren marktgängige Lösungen, programmiert wurde noch weitgehend in Assembler. Ich kann euch also bei der Entwicklung nicht wirklich eine Hilfe sein.

Trotzdem hier mal meine Gedanken als potentieller Nachbauer:

Ein Schalenmodell zu definieren, ist natürlich unabdingbar. Ebenso eine umzusetzende Minimal-Ausbaulösung als ersten Schritt festzulegen.

Das Projekt sollte unbedingt auf verschiedene Hardware adaptierbar sein, auch wenn zu Beginn vermutlich eine parallaktische Monti mit Schrittmotoren, ohne Encoder, mit einfacher Handbox, Autoguider-Eingang und Motorfokussierer-Anschluß als Standard-Hardware definiert wird. Natürlich sollte auch eine Altaz-Monti mit Bildfeld-Derotator ansteuerbar sein, damit haben wir insgesamt 4 Motoren.

Ein gut umgesetztes Schalenmodell würde es erlauben, später auch DC-Motoren mit Encodern oder sogar ein Direct Drive System anzusteuern.

PC-Interface in USB ist vor allem hardwaremäßig suboptimal. Hauptprobleme: Zu kurze max. Leitungslängen, mechanisch viel zu anfällige Steckverbinder. Dann lieber erst mal RS232 und später evtl. gleich LAN (WLAN?). USB sehe ich nur als Alternative für kleine mobile Systeme, weil man ein Netbook ohne Adapter anstöpseln kann.

Auch der Hardware-Aufbau darf ruhig modular sein.
Ganz wichtig finde ich, beim Standard-Basissystem ohne exotische Hardware auszukommen.
Falls es absolut nicht ohne SMD &lt; 1/20" Pinabstand und 4lagige Platinen geht, ok.
Zweilagige 1/2 Europlatinen wären aber wünschenswert, zumindest für eine einfache Basishardware.

Wenn genügend Leute mitarbeiten und die Schnittstellen-Definitionen zwischen den Schalen vernünftig gepflegt werden, spricht gar nix dagegen, dass von Beginn an verschiedene Entwickler mehrere Alternativen erarbeiten. Nachbauer könnten dann, vielleicht zunächst mit Hilfe der Entwickler, aus den vorhandenen Komponenten das für sie passende Menü zusammenstellen.
Die oberen 2-3 Schalen nach Jens' Beschreibung könnten sicher auch problemlos auf einem PC laufen.

Beteiligte Entwickler sollten sich möglichst auf eine Schale beschränken. Ein großer Vorteil dieser Strukturierung: Jeder Entwickler beackert eine überschaubare Teilmenge des Gesamtprojekts und kann sich innerhalb seines Aufgabengebiets ziemlich frei entfalten.

Wie wollt Ihr denn nun weiter vorgehen?
Dieser Thread ist jetzt schon eigentlich viel zu lang und unübersichtlich. Ihr braucht dringend eine andere Basis, um die Grundlagen zu erarbeiten Es wäre gut, wenn sich jemand fände, der die nächsten Schritte und die Kommunikation strukturiert. Minimal wäre wohl ein extra Forum und eine Plattform zum Onlinestellen von Dateien erforderlich.

Ich bin gespannt, wie sich die Sache weiter entwickelt.

Gruß,
Martin