Low-Cost Experimentträger

[PICture]

Als einfachste (mechanisch) und ausprobierte Lösung, könnte das vielleicht interessant sein: https://www.roboternetz.de/community...einem-DC-Motor .

[Arkon]

@oberallgeier: Süß XD. Wie du schon geschrieben hast sind solche Anpassungsarbeiten meist aufwändiger als man zuerst denkt

@PICture: Danke für den Link. Die Motoren werden über PWM angesteuert. Dafür habe ich in dem Thread leider keine "fertige" Lösung gefunden. Und um die von jeffrey vorgeschlagene Lösung umzusetzen fehlt mir das nötige Fachwissen.

Ich werde daher erst einmal auf selbst gefertigte Dekoderscheiben+Gabellichtschranke setzten und mir einfach mehrere Versionen durch den Laser schieben lassen. Die Arbeiten sind dank modernem CAD-System sehr schnell erledigt.

[Arkon]

*staubwisch*

Ein paar Wochen war es ruhig hier aber das Projekt läuft weiter. Mittlerweile habe ich eine V0.1 der Hardware:


Auf dem ersten Bild sieht man ein an der Front angebrachtes Servo. Die seltsam aussehende Halterung habe ich gewählt, da, wie schon erwähnt, der Roboter bei der Bestückung mit Sensoren möglichst modular sein soll. Darunter hängt, momentan noch in der Luft, ein Sharp-IR-Sensor (hab die genaue Bezeichnung grad nicht zur Hand). Im hinteren Teil sind zwei identische Platinen aufgeschraubt. Diese Platinen sind bereits an der FH vorhanden und im Eingangsposting kurz beschrieben (wenn ihr genauere Infos haben wollt einfach fragen)

Auf dem zweiten Bild sieht man die Unterseite. An der Front der angesprochene Tischtennisball und im hinteren Teil die Antriebe. Jeweil ein Bühler Getriebemotor mit 9Ncm und 64upm treiben über eine Untersetzung die Antriebsräder an. Diese sind die 70mm-Räder von Robotikhardware.de und wurden mit einem selbst gefertigten Adapter auf der 6mm Welle befestigt. Auf dieser Welle sitzt ebenfalls eine Dekoderscheibe (welche genau muss noch ermittelt werden. Habe 4 oder 5 verschiedene Rastermaße fertigen lassen) welche mit einer kleinen Schraube am Zahnrad befestigt wird. Somit ist eine direkte Verbindung zwischen Antriebsrad und Odometrie hergestellt wodurch ich keine Einflüsse wie Getriebespiel ect. beachten muss.

Was noch nicht zu sehen ist, ist die "Bedieneinheit". Über den µC-Platinen wird eine Platte befestigt, in welcher ein paar Taster und ein LCD mit 16x2 oder 20x4 Zeilen angebracht wird. Über das Menü soll sich später eine bestimmte Anwendung auswählen lassen welche dann vom Roboter ausgeführt wird. Die beiden µC sollen miteinander kommunizieren. Und hierzu betreibe ich im Moment Grundlagenforschung:

Ich habe bisher ein wenig Erfahrung mit I2C und UART gesammelt. Ich dachte daran, einen µC die Kommunikation mit der Hardware und die "Regelungen" übernehmen zu lassen. Der zweite Controller dient zur Ansteuerung des LCDs, auswerten der Tasten und übermitteln der "Befehle" (im Sinne von: Führe Aufgabe xyz aus) an den ersten µC. Mir ist dabei bewusst, dass für diese Aufgaben auch ein einzelner µC ausreichen würde aber so ist nunmal die Aufgabenstellung -_-
Welches der Protokolle ist sinnvoller für den Einsatz zwischen den beiden µC?

[mausi_mick]

Hallo Arkon,

hab den Thread erst heute gesehen.

Interessantes Projekt!

Hab vor einiger Zeit auch mal mit Encodern gearbeitet und bin dann - gerade bei Einsatz im Freien - von den Refelexsensoren weggegangen und hab Gabellichtschranken verwandt.
Um den Aufwand/Kosten mit den Encoderscheiben zu minimieren, hab ich einfach ein Modul 1 Kunststoff-Zahnrad (z.B. mit 40 Zähnen) verwandt und die Zahnlücken abgetastet. Hab dann gleich für einen Quadroencoder jeweils 2 Gabellichtschranken verwandt, Justage in Zahnmitte (und für Quadro 90° Versatz) über 2-Kanal Oskar. Als Gabellichtschranke hab ich eine TC ... von Pollin verwandt, die zum einen preisgünstig ist (25 Cent), zum anderen einen Schmitttrigger beinhaltet, der ein sauberes TTL Rechtecksignal liefert, sodass man auf die AD-Umsetzung (ASURO) verzichten kann.

Siehe:
https://www.roboternetz.de/community...adraturencoder


Gruss mausi_mick

[021aet04]

Hast du beim Getriebe mit Encoderscheibe eine Abdeckung? Ich hätte bedenken wegen Staub/Schmutz. Ich würde eine Abdeckung machen.

Welchen Bus du nimmst bleibt eigentlich dir überlassen.Ich würde eine UART Schnittstelle nehmen. Damit hättest du den Vorteil das du über PC debuggen könntest. Ansonsten könnte, wenn etwas nicht funktioniert, vom µC1 oder vom µC2 kommen. Die beiden µCs würde ich über Steckverbinder verbinden (damit man mit dem PC debuggen kann).

PS: Protokoll und Busssystem ist nicht das Gleiche. Hier am Beispiel vom CAN Bus http://de.wikipedia.org/wiki/Controller_Area_Network
Protokoll ist nur das Verfahren wie die Daten auffgeteilt wird u.Ä.

MfG Hannes

[Arkon]

@mausi_mick: Ich nutze ja auch eine Gabellichtschranke TCST 2103 für die Odometrie. Eine Drehrichtungsbestimmung ist bisher nicht vorgesehen, da diese ja durch die Drehrichtung der Motoren bekannt ist. Höchstens um den Bot punktgenau um eines der Räder zu drehen könnte die Erkennung nötig werden, um ein "Wegdrehen" des eigentlich stillstehenden Rades zu kompensieren. Aber dazu gibt es bisher noch keine Anwendung

Die Lösung mit dem Zahnrad ist natürlich ein sehr elegantes Workaround. Ich habe glücklicherweise freien Zugriff auf die beiden Laser der FH, so dass mich die Dekoderscheiben 30 Minuten Arbeit gekostet haben. In dieser Zeit hätte man es wahrscheinlich nicht geschafft, ein geeignetes Zahnrad zu finden und die Preise verschiedener Shops zu vergleichen. Und die Genauigkeit dürfte auch besser sein.

@021aet04 (hat der Name eigentlich einen tieferen Sinn oder ist er das Ergebnis Kopf->Tastatur )

Eine Abdeckung ist bisher noch nicht vorhanden. Der Bot ist für den Betrieb in geschlossenen Räumen, auf ebenen Untergründen gedacht. Staub, Schmutz und Co. sollten sich daher in Grenzen halten. Gelegentliches Säubern vorausgesetzt

UART ist auch mein Favorit bei den beiden gewesen, eben zum debuggen. Dann werde ich meine weiteren Recherchen wohl in diese Richtung eingrenzen. Kann ich die UART-Verbindung im laufenden Betrieb "anzapfen"? Ich stelle mir das so vor, dass den jeweiligen RX-TX-Verbindungen zwischen den µCs eine Buchse ist, in die ich meinem USB-UART-Adapter einstecke. So könnte ich die Daten auf jeweils einer Leitung (mit einem zweiten Adapter vll sogar beide Leitungen?) unter "Realbedingungen" abhören.

[oberallgeier]

Hi Arcon,

sieht ganz gut aus. Bei einem (von mir geschätzten Gesamtgewicht 1 kg, in der Rechnung 0,5 kg weil es ja zwei Motoren sind) und der geschätzten Untersetzung 2:1 sind die Motoren recht gut gewählt (klick).

[021aet04]

Der Name hat einen Sinn. Das war meine Bezeichnung in der HTL/Fachschule.
02 => Jahr in dem ich in die HTL kam
1aet => Klassenbezeichnung => "1a" ist die Klasse und "et" bedeutet HTL für Elektrotechnik (Fachschule wäre dann "ef")
04 => Klassenbuchnummer

Mittlerweile hat sich die Bezeichnung der Klassen aber geändert.

UART gleichzeitig mit PC und Bedienteil verbinden funktioniert soweit ich weiß nicht, da UART eine Punkt zu Punkt Verbindung ist. Was ich mir vorstellen kann wäre beim Pc und beim BT (Bedienteil) einen Punkt einzufügen das man Debuggen und steuern umschalten kann.
Als Beispiel: Umschalten von BT auf PC (bedienen auf debuggen)
=> man wählt am BT den Punkt zum Umschalten in den Debugmodus
=> man trennt die Verbindung zum BT und verbindet mit dem PC
=> vom PC schickt man einen Befehl damit die Daten zum Debuggen gesendet werden können (PC für Empfang bereit)
Beim Umschalten von Debugmodus auf Bedienmodus genau umgekehrt.

MfG Hannes

[Richard]

UART gleichzeitig mit PC und Bedienteil verbinden funktioniert soweit ich weiß nicht, da UART eine Punkt zu Punkt

Doch, das geht, aber bitte nur zum Lesen / Lauschen. Dazwischen Funken (Senden) könnte Probleme bis hin zu Daten Kurzschlüssen führen. Aber zum "Mitschneiden" was da so "Verhandelt" wird ist das ideal. Es gibt auch gute Sniffer Programme für RS232 oder USB bekannter allerdings für Netzwerke.

Gruß Richard

[Arkon]

Abhören würde mir ja völlig reichen, um die Kommunikation zu überwachen.

Eigentlich wollte ich am Wochenende die gelaserten Teile zusammen schrauben um ein "rolling Chassis" zu erhalten. Aber erstens kommt es anders und zweitens als man denkt. Da ich am kommenden Wochenende zu meinen Eltern fahre (unter anderem um meine Winterreifen abzuholen) nutze ich die Gelegenheit und greife auf die Werkstatt meines Elternhauses zurück. Da hab ich mehr/besseres Werkzeug als in meiner Studentenbude

Gibt es Literatur, die mir ein paar Strategien für eine sinnvolle Kommunikation zwischen zwei µC zeigt? Welche Teile des Programms am besten auf welchem µC abgelegt werden, wie man die einzelnen Funktionen auf dem "ausführenden" µC startet/beendet/überwacht ect. ?