-
Seite 2 von 6 ErsteErste 1234 ... LetzteLetzte
Ergebnis 11 bis 20 von 59

Thema: Low-Cost Experimentträger

  1. #11
    RN-Premium User Robotik Visionär Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    63
    Beiträge
    9.979
    Als einfachste (mechanisch) und ausprobierte Lösung, könnte das vielleicht interessant sein: http://www.roboternetz.de/community/...einem-DC-Motor .
    MfG (Mit feinem Grübeln)
    Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) Fiction braucht Science. Nix ist real und Reales ist unsimulierbar, weil 1/∞=0. Chaos gegen Ordnung ist immer fehlerfrei. Heutige wurde früher gebastelt und geprüft. Nicht alles ist erlernbar.

  2. #12
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.04.2008
    Alter
    29
    Beiträge
    551
    @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.
    Alles ist möglich. Unmögliches dauert nur etwas länger!

  3. #13
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.04.2008
    Alter
    29
    Beiträge
    551
    *staubwisch*

    Ein paar Wochen war es ruhig hier aber das Projekt läuft weiter. Mittlerweile habe ich eine V0.1 der Hardware:
    Klicke auf die Grafik für eine größere Ansicht

Name:	1.jpg
Hits:	42
Größe:	110,7 KB
ID:	20327Klicke auf die Grafik für eine größere Ansicht

Name:	2.jpg
Hits:	39
Größe:	70,6 KB
ID:	20328

    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?
    Alles ist möglich. Unmögliches dauert nur etwas länger!

  4. #14
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.07.2006
    Ort
    Puchheim
    Alter
    66
    Beiträge
    409
    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:
    http://www.roboternetz.de/community/...adraturencoder


    Gruss mausi_mick

  5. #15
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    26
    Beiträge
    3.798
    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

  6. #16
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.04.2008
    Alter
    29
    Beiträge
    551
    @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.
    Alles ist möglich. Unmögliches dauert nur etwas länger!

  7. #17
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    6.179
    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).
    Geändert von oberallgeier (21.10.2011 um 12:32 Uhr) Grund: falscher Link
    Ciao sagt der JoeamBerg

  8. #18
    Erfahrener Benutzer Robotik Einstein Avatar von 021aet04
    Registriert seit
    17.01.2005
    Ort
    Niklasdorf
    Alter
    26
    Beiträge
    3.798
    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

  9. #19
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Zitat Zitat von 021aet04 Beitrag anzeigen
    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

  10. #20
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.04.2008
    Alter
    29
    Beiträge
    551
    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. ?
    Alles ist möglich. Unmögliches dauert nur etwas länger!

Seite 2 von 6 ErsteErste 1234 ... LetzteLetzte

Ähnliche Themen

  1. Low Cost CNC Fräse
    Von Panzer im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 380
    Letzter Beitrag: 05.05.2011, 09:27
  2. Low Cost Temperatursensor
    Von s.o. im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 11
    Letzter Beitrag: 29.03.2010, 17:51
  3. low-cost IR Abstandssensor
    Von avr_mcu im Forum Sensoren / Sensorik
    Antworten: 1
    Letzter Beitrag: 23.02.2010, 16:58
  4. Low Cost Ätzgerät
    Von daniel.weber im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 13
    Letzter Beitrag: 13.04.2008, 10:49
  5. Anleitung : Low-Cost Belichtungsgerät
    Von Andree-HB im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 14
    Letzter Beitrag: 16.05.2007, 06:34

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •