Arduino + Raspberry Pi Roboter

International Deutsch
1

Hey Leute,

da es zu viel Zeit kostet, mein ganzes Projekt vorzustellen, möchte ich euch in diesem Thread ein paar gezielte Fragen zu meinem aktuellen Projekt stellen.

Ich baue momentan einen Roboter, der mit Arduino und Raspberry Pi ausgestattet ist, damit ich die Vorteile beider verbinden kann. Nun zu meinen Fragen:

Connection Arduino Uno -> Rasp Pi

Wie verbinde ich Rasp Pi und Arduino Uno am besten? I2C, USB-Serial oder Serial. Bei I2C und Serial bräuchte ich als güstigen "Pegelwandler" nur zwei Dioden von Rasp Pi zu Arduino und von Arduino zu Rasp Pi zwei Widerstände oder komme ich mit einem 2-Kanal bidirektionalen Pegelwandler besser? Wie groß müssten diese Wiederstände sein, um 5v auf 3v zu kriegen?
Bei allen drei Formen würde ich folgende "Übertragungstechnik" benutzen:

Byte 1: Befehl;
  falls (Befehl mit Daten verbunden)  [
    falls (Befehl mit undefinierter Datenlänge verbunden)  [
      Byte 2-3: Datenmenge;
      Byte >3: Daten;
    ]
    sonst [
      Byte >1: Daten;
    ]
  ]
(vielleicht Sicherheitshalber [
  letztes Byte: Endbyte;
] )

Geht das so?
Wie sieht es mit der Programmierung aus, wo ist es am einfachsten, diese Datenübertragung anzuwenden?

Drehung berechnen

ich habe durch Drehzahlmesser an den beiden hinteren Rädern, die auch zum lenken benutzt werden, die Geschwindigkeit, die jedes Rad zurücklegt. Wenn ich ein Rad stehen lasse und das andere um x cm fahren lasse, dreht sich der Roboter. Wie berechne ich aus der Strecke x die Drehung des Roboters in Grad (°)?
Umformuliert für alle Mathematiker:
Wie berechne ich den Winkel Alpha?

Karte erstellen

Da ein Roboter für eigenständiges Fahren eine Karte benötigt, möchte ich mit Hilfe eines jeweils vorne und hinten an einem 180° Servomotor befestigten Ultraschallsensors eine Karte erstellen, die man auch auf einen PC übertragen und eine Fahrroute festlegen kann. Kann der Arduino diese Karte erstellen oder soll ich lieber den Pi damit beschäftigen? Ich würde diese Aufgabe eher dem Pi überlassen, da der Arduino mit der ganzen Steuerung schon gut ausgelastet ist und schnell reagieren können soll. Dann werde ich diese Frage wohl mal im Pi Forum stellen.

eventuell Folgen weitere Fragen nach Edit

2

In welchem Abstand befinden Sich Arduino un Raspberry?
Grüße Uwe

3

Im Prototypen liegen max. 10 cm zwischen beiden

4

Wenn du Drehzahlmesser hast (was ich allerdings nicht glaube...) brauchst du zusätzlich die Zeit, da man aus ner Drehzahl alleine keinen Weg berechnen kann.
Vermutlich aber hast du eher Umdrehungszähler-damit gehts relativ einfach:

Du nimmst zuerst den Radius, auf dem das angetriebe Rad läuft (Drehpunkt ist das stehende Rad, hoffentlich), nun berechnest du den Umfang eines Vollkreises mit diesem Radius. Den teilst du dann durch die tatsächlich gefahrene Strecke und löst das dann in Winkelgrade auf.
Die gefahrene Strecke kannst du ja aus den ermittelten Radumdrehungen so wie dessen Umfang leicht berechnen.

Das Ganze funktioniert aber nur unter Idealbedingungen (möglichst schmale Räder oder zumindest welche die wirklich nur an nem Punkt den Boden berühren), möglichst hohe Auflösung der Radencoder, schluppfreiem Antrieb.
Und: nach fünf, sechs Umdrehungen des Roboters hast du genug Ungenauigkeiten angesammelt, dass da nichts mehr so recht stimmen wird.

5

Die einfachste Verbindung zwischen dem Raspberry Pi und dem Arduino kannst du per USB Herstellen und dann im Arduino einfach die serielle Schnittstelle nutzen. In welcher Software programierst du auf dem Raspberry Pi C / C++ / Python ?
Vorteil hier wäre, dass du den Arduino über das Raspberry Pi auch programmieren und flaschen kannst. Es ist auch möglich das Raspberry Pi per Wlan ins Netzwerk zu hängen und über den PC, -> Router -> Wlan -> Raspberry Pi den Arduino mit neuer Firmware versorgen. :wink:

6

@ Rabenauge:
Ja kein Drehzahlmesser sondern sowas: http://www.miniinthebox.com/de/hc-020k-double-speed-messmodul-w-optische-drehgeber-schwarz-gruen-2-pcs_p647629.html#
ich wusste eben net wie das heißt

@Jomelo:
Stimmt! So habe ich das auch noch net betrachtet. Echt praktisch wenn ich mit dem Pi über WLAN die Programmierung des Arduinos korrigieren kann, sonst musste ich den immer wieder einfangen und ans Kabel hängen.
Dann hab ich dazu mal ne Frage: Wenn ich Bytes, die ich ausgelesen habe, überprüfen wollte, sagen wir ob "dtgkinfrrhhnj" angekommen ist, hätte ich bis jetzt 13 ifs gemacht und die in ein Array eingelesenen Bytes überprüft. Geht das auch anders?

7

Wenn es ums auswerten auf dem Arduino geht nicht. Aber falls du überprüfen willst, ob die Übertragung geklappt hat. Kannst du mit CRC8 eine Checksumme berechnen, die du z.B. hinten an den String anhängst. Die Checksumme wird dann von beiden Seiten berechnet, also von Raspberri Pi und vom Arduino. Stimmt diese Summe überein, ist die Übertragung technisch Fehlerfrei oder bewusst manipuliert worden :wink:

Du könntest deine Informationen anstatt in Bytes auch in Bits übertragen. Z.b. passt in das Zeichen "a" = 01100001 (binär) auch viel viel mehr Informationen rein:

geschicktere Aufteilung:
Bits 0-2: Geschwindigkeit linkes Rad (0 - 7) => 8 Stufen
Bit 3: Richtung des Rades: 0=> vor, 1=zurück
Bits 4-6: Geschwindigkeit des rechten Rades (0 - 7) => 8 Stufen
Bit 7: Richtung des rechten Rades

Nun wäre es möglich mit der Übertragung eines Bytes den Roboter zu lenken, zu navigieren, in alle Richtungen, links, rechts, vor und zurück. Denk mal drüber nach :wink:

8

Sry Leute, ich war jez eeeeewig net online. Hatte zu viel zu tun und außerdem net genung Bauteile um das Projekt sinvoll weiterzuführen.
Jetzt sollte aber in der nächsten Woche alles da sein.

@ Rabenauge (und alle die sich damit auskennen): Ja. Stimmt. Verdammte Ungenauigkeit. Ich habe die breitesten Räder, die du dir vorstellen kannst und je nach Untergrund liegen die eh immer anders auf. D.h. Ungenauigkeit = extrem. Hat jemand ne Idee wie zur Hölle ich die Drehung OHNE Kompassmodul genau messen könnte?

zu Jomelos Post: Genial!! Ich werde deine Übertragungsmethode auf 4 Bits pro Rad für die Geschwindigkeit ausweiten. Zurück zum Pi werd ich das Ganze dann ähnlich für die Sensoren machen.

Mein Notfall-Entfernungssensor-Ersatz: Da ich jez schon eine gaaanze Weile an dem Roboter baue und der Entfernungssensor immer noch net da ist (hab ihn erst vor kurzem bestellt), hab ich mir aus lauter Langeweile (ja da hatte ich noch Zeit) einen Ersatz gebastelt. Ich habe statt des Sensors eine weiße, helle LED und daneben einen Lichtsensor genommen. Zwischen beide kam ein kleines Stückchen Plastik, damit die LED net direkt auf den Lichtsensor schein. Dann habe ich den Sensorwert ausgelesen, die LED angeschaltet, erneut gemessen und die Differenz mithilfe einiger Ifs und Whiles in einen auf ca. 5 cm genauen Wert umgewandelt. Messbereich: 5 - 20 cm. ^^ Ich lache immer noch wenn ich das sehe ^^

MfG paulrt5

9

Odometrie auf so eine Art läuft immer aus dem Ruder-da brauchst du dich keinen Illusionen hingeben.
Selbst winzigste Messfehler addieren sich unglaublich schnell auf. Eventuell könnte man mit nem 9DoF-Sensor die Werte aber schon noch verbessern.
Mein NiboBee schafft eine Genauigkeit von 0.5cm pro Meter- allerdings kommt pro volle Umdrehung (relativ egal ob am Stück oder ob er z.B. nen Viereck fährt) noch mindestens nen cm drauf.
Manches kann man durchaus noch herausrechnen, aber irgendwann kommt man in Bereiche, wo schon unterschiedlicher Bodenbelag sich spürbar auswirkt und: es fallen bei genaueen Messungen irgendwann auch exorbitante Datenmengen an. Ok-du hast nen Pi drauf, der so einiges handlen kann, auch auf ne SD-Karte kriegt man wirklich viel, aber all das hat die Biene nicht.
Ich hab dann immer versucht, mir ne Wand oder Ecke als Referenz zu schnappen, da mein NoboBee nen Sharp-IR-Sensor drauf hat, kann er beispielsweise die Entfernung zu nem Hindernis mal genau vermessen, und das mit der Odometrie abgleichen. So hat man wenigstens ab und zu eine Art Korrektur, kann z.B. Radschlupf (nen ziemliches Problem bei der Biene) durchaus leidlich rausrechnen.
Das tolle: auch ein GPS nutzt da gar nix- die Ungenauigkeiten, von denen wir hier reden kriegen selbst HighEnd-Geräte nur unter optimalen Bedingungen raus...

Wenn ich den Kettenroboter anfange (wird ähnlich dem bekannten T`Rex-Chassis, aber Eigenbau und etwas anders) mach ich das vielleicht, der soll auch im Freien grössere Entfernungen zurücklegen, das wird rein mit Encodern eh nix.
Da kann man die Odometrie ab und zu wenigstens mit dem GPS abgleichen. Wird bei dem Burschen auch nicht auf nen halben Meter ankommen.

10

Hi,
Möglichkeiten, um die Drehung zu erkennen

  • Radsensoren (Vorsichtig mit Schlupf)
  • Gyroskop (vor jeder Drehung neu auf 0 setzen)
  • optischer Maussensor (anbringung nicht am Mittelpunkt des Fahrzeuges. Die zurückgelegte Strecke sollte bei einer Drehung auf der Stelle gleich sein, somit könnte damit auch der Winkel der Drehung bestimmt werden (Über den Rand des Kreises/Elipse))
11

Oder einen Magnetkompass mit ausreichender Auflösung. Der Lauf des Rades reicht schon um eine Drehung genau zu bestimmen. Aber nach 2-3 Drehungen hat man so viele Fehler drin, dass es nicht mehr passt. Wenn man danach mit einen anderen Sensor die tatsächliche Ausrichtung bestimmt sollte es gehen.

12

Ich gehe mal von aus das es sich um ein Dreirad handelt...
Wenn du den Weg des 3. Rades auch messen könntest, dann könntest du einfach berechnen/vergleichen ob ein Antriebsrad Schlupf hat oder nicht.

Gruß

13

-optische Mausensoren funktionieren wirklich gut- unter "Labor"bedingungen.
Sie haben Probleme wenn die Entfernung zwischen Boden und Sensor grösser als ein, zwei Millimeter ist (das kann man ggf. noch mit ner Vorsatzlinse umschiffen), sie haben Probleme mit refflektierenden Böden- wie gesagt: unter definierten Bedingungen ists ne tolle Sache. Nur dann...

-Kompass hat leider ähnliche Probleme-ich habs versucht: auf Robotern der Grösse Asuro, NiboBee gar nicht zu gebrauchen.
Die Dinger funktionieren nur bei einem ziemlichen Abstand zu Motoren überhaupt einwandfrei-den kriegt man bei kleineren Robotern nie hin. Und: alles mögliche lenkt die Dinger ab, Lautsprecher, stromführende Leitungen, Handys...sogar Eisen in den Wänden.
Da hilft nur eine Kombination mehreren Sensoren, dann kann man über gute Filter vielleicht was machen.

Das mit dem dritten Rad-hm...da könnte man alte Maussensoren benutzen(Lichtschranken mit Encoderscheiben). Damit dürfts ausreichend genau werden.
Bräuchte man zweie: einen, der registriert, wohin der Nachläufer geschwenkt wurde und einen für die Drehzahl und -richtung.
Damit dürfts möglich sein, auch Kurven sauber zu vermessen.

Was Radencoder allgemein angeht: wenn man nur einen Impuls pro Radumdrehung messen kann, braucht man gar nicht erst anzufangen. Damit wirds definitiv nicht mal "sowas ähnliches wie grob geschätzt"- nach nen paar Metern hat man da solche Ungenauigkeiten, dass man auch gleich die Zeit auf die Motordrehzahlen aufrechnen kann.
Rechnet mal: schon ein Rad mit 3cm Durchmesser hat bereits rund 9.5cm Umfang- wenn ich da nur einen Impuls pro Umdrehung bekomme, hab ich bereits dann eine Mindestabweichung von 9cm!
Damit ist rein gar nix anzufangen.
Radencoder sollten schon Rückschlüsse im einstelligen Millimeterbereich liefern, sonst sind sie relativ nutzlos.

14

Jaja mit dem Radencoder geht alles klar der misst schon in kleinen Abständen.
@ Rabenauge: Wovon ich jez noch gar keine Ahnung habe ist, wie du einen Referenzpunkt verfolgen kannst. Ich habe jetzt zwei Ultraschall-Abstandssensoren hierzuliegen. Einer kommt wahrscheinlich um 360° drehbar auf den Robo. Wie ich die Daten kriege kein Problem, aber wie vergleiche ich das dann?
Auf die schnelle würde ich es so machen:
Sensor um 360° drehen, dabei stetig Differenz zwischen letztem und vorletztem Messen ausrechnen. Wenn die Drehung abgeschlossen ist, würde ich den Sensor nochmal genauer über den Punkt mit der größten Differenz laufen lassen und die einzelnen Differenzen speichern. Dann würde ich die Drehung mit den Werten des Radencoders ausführen, den Sensor über den (durch die Werte des Radencoders berechneten) gleichen Punkt laufen lassen und wieder die Differenzen speichern. Dann würde ich die größte Differenz bei beiden Messungen als Anhaltspunkt benutzen und von dort aus eben diese Differenzen und die Messungen links und rechts davon mithilfe von vielen ifs vergleichen. Stimmt alles ungefähr überein, vergleiche ich die Stellung des auf den Punkt mit der größten Differenz gerichteten Sensors vor und nach der Drehung mit den Daten des Radencoders und gleiche alles ab.
Das Ganze sollte dann ca. 3-4 Sekunden vor und nach der Drehung in Anspruch nehmen, also noch geradeso akzeptabel.
Ma Guggen wat wird wenn dann endlich diese sch*** Sensoren da sind.

Ein bisschen rassistisch, aber am besten wäre es, wenn ich mir einfach einen kleinen Chinesen in den Robo baue. ^^

MfG
paulrt5,
der hofft, dass irgendjemand ihn versteht ^^

15

Du hast doch nur nen Dreirad-wozu dann nur den Sensor drehen?
Das ist unnötiger Aufwand, denn es nutzt dir auch nur dann was, wenn du die jeweilige Stellung des Sensors genau kennst (ohne Encoder oder Kompass wird das auch wieder nix, wenn man ihn nur nen Stück schwenkt, reicht ein Servo).

Fahr soweit, bis der Sensor ein Hinderniss erfasst. Dann messen. Nun den Roboter nach Odometrie so lange drehen (auf dem Punkt natürlich, ggf. ist das bisschen Rechenaufwand, weil manche Stützräder verhindern, dass er wirklich mittig zwischen den Rädern dreht), bis der Sensor das selbe Ergebnis wieder hat.
So kannst du schonmal die Drehungen mit der Odometrie abgleichen. Sollte es nicht möglich sein, im Erfassungsbereich nur ein Hindernis ringsum zu haben, musst du dir halt ne Stelle suchen, an der eins in genauem Abstand (alle anderen müssen andere Abstände haben) ist, was du als Referenz nutzen kannst.
Dabei gibts allerdings nen Haken: diese Sensoren messen keineswegs in nem schmalen Bereich, die billigen haben sowas zwischen 15 und 20 Grad Erfassungswinkel, du musst also seeeehr genau messen, oder eben den Rand des Erfassungsbereiches ermitteln.

Fahr-Odometrie kannst du genauso kalibrieren: such dir ne Wand, und fahr ran bis sie der Sensor gut erfasst (beispielsweise auf nen Meter ran, wenn der Sensor 4m schafft), nun fährst du zurück und kannst die Ergebnisse der Odometrie mit denen des Sensors abgleichen.
Kannst du dann auch mal probieren, ob es noch genauer wird, wenn du das Ganze mehrmals machst (einfach immer schnurgerade hin-und her fahren, dabei schön die Odometrie mitzählen lassen und am Schluss mit dem US-Sensor abgleichen).
Bedingung hierfür ist allerdings, dass der Roboter auch wirklich grade vor und zurück fahren kann (mit nem Nachlauf-Rad wird das wohl eher nix, weil der Roboter dann immer kurz schwenkt, da brauchst nen ziemlich cleveren Algorithmus um das definiert hinzubekommen), bei ner Kugel als Stütze oder sowas sollt das möglich sein, wenn du eine Geradeausfahr-Regelung benutzt.

Und: wenn du sowieso mehrere der Ultraschall-Sensoren hast, benutz sie auch. Lass sie beide schräg nach vorne sehen, so dass die Erfassungsbereiche sich grade noch überlappen, dann hast du ne ziemlich gute Möglichkeit, Hindernisse richtig zu erkennen und brauchst da nix schwenken (das ist gerne ne Quelle für Fehlmessungen): wenn beide Sensoren was erfassen, ist es genau vor dem roboter. Den drehst du nun etwas, und dann wirds nur noch einer der beiden erfassen, und du weisst, wo es wirklich ist.
Wichtig aber: niemals beide Sensoren wirklich zugleich einsetzen, die beeinflussen sich gegenseitig!

16

Wie "wozu dann nur den Sensor drehen"?? Ja ich hab ein "Dreirad", aber ich weis auf 1° genau, wo der Sensor hinzeigt, habe vorne so eine dumme Kugel dran und kann aber nicht beide Räder gleichzeitig drehen. Ich möchte nur den Sensor drehen, da ich so auch hinter und neben mir Hindernisse erfassen kann, auch ohne den Robo zu drehen. Den zweiten Sensor möchte ich so flach wie möglich vorne am Robo befestigen, um auch flache Hindernisse zu erkennen.
Die Kugel macht das Ganze nur Laborfähig, da die Kugel bereits in einer größeren Fliesenfuge hängen bleibt und sich nur mit ein bisschen Arbeit wieder rausziehen lässt. Durchfahren geht net, wenn dann nur Rückwärts.
Das mit der Wand wird in kleinen Räumen aber problematisch, da sich die Position des Sensors bei drehen auf einem Rad verändert und in kleinen Räumen zu viele Wände in der Nähe sind. Aber es bevor ich das gleich ausschließe, werde ich es mal testen wenn eeeeendlich die ganzen Sensoren da sind...

17

Rabenauge:
Du hast doch nur nen Dreirad-wozu dann nur den Sensor drehen?
Das ist unnötiger Aufwand, denn es nutzt dir auch nur dann was, wenn du die jeweilige Stellung des Sensors genau kennst (ohne Encoder oder Kompass wird das auch wieder nix, wenn man ihn nur nen Stück schwenkt, reicht ein Servo).

Es kommt darauf an was man genau machen will.

Ich hatte während des Studiums ein Projekt mit Lego NXT Robotern gemacht. Da ging es darum die genaue Position von Hindernissen zu erfassen und eine Karte der Umgebung zu erstellen. Einfach die Hindernisse zu umfahren reichte also nicht. Und wenn man ständig den Roboter dreht, hat man gleich die Position verloren. Also haben wird den US um 180° drehbar gemacht. So konnte man während dem vorwärts Fahren links und rechts Hindernisse messen.

Das funktionierte ziemlich gut. Die Position der Objekte konnte man durch den Drehwinkel des Sensors und die Position des Roboters auf ein paar cm genau berechnen. Wenn die Objekte weit genug auseinanderstanden ging es sogar zwei Objekte pro Sensor-Schwenk zu erfassen.

18

Kommt auf die Sensoren an.
Mit nem guten Sharp-IR-Sensor kann ich aufrecht stehende Bleistifte aufm Tisch zählen-kein Problem.
Die billigen US-Sensoren schaffen das nur mit viel Tricksen....

19

Ja. IR-Sensoren. Das hatten wir dann auch vorgeschlagen, aber wir mussten mit dem US Sensor arbeiten.

Und nachdem wir dann festgestellt haben, dass die eher dazu da sind um grob Hindernisse zu entdecken als deren Position zu bestimmen mussten wir und was einfallen lassen :slight_smile:

20

Lego NXT hatte ich nie- daher weiss ich nicht, wie gut die sind, bessere US-Sensoren arbeiten schon auch präziser. Aber wir reden ja hier von denen, wo ne Tüte voll nen Zehner kostet-da darf man nunmal auch kleine Wunder nich erwarten...