Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI

  • ich nehme keine raddecoder, es macht die sache etwas schwerer gebe ich zu. aber in der natur gibt es auch nur schätzungen :-)
    ich meine ja nur.

    das leben ist hart, aber wir müssen da durch.

  • Moin morob,


    ...
    ... aber in der natur gibt es auch nur schätzungen :-)
    ...


    naja ... nachdem aber Fahrzeuge nicht an Sträuchern oder auf Bäumen wachsen, darf man da schon mal eine Ausnahme machen ;) ...
    Wobei Rad-Decoder imho irgendwie Mist sind ... da hast Du wohl recht


    cu,
    -ds-

  • Die Argumentation kann ich irgendwie nicht nachvollziehen... In der Natur gibt es garkeite Räder von daher ist der Vergleich garnicht möglich, außerdem geht es ja nicht darum einen "vegetarischen" Roboter zu bauen (vegetarisch = "Ich verwende nur Prinzipien die die Natur vorgibt", könnte man diesen Begriff bitte in der Fachlitheratur verwenden :-) )

  • morob wo steht, dass maigrafd einen vegetarischen Roboter bauen will???
    Und Schritte zählst du sehr wohl wenn du wissen möchtest wie weit du gehst und das nicht zufällig ein GPS dabei hast oder sowieso weißt wie weit der Weg ist.

  • Es geht ja auch darum zu wissen wie schnell der Roboter fährt und eben wie viel Strecke er zurück gelegt hat - das vereinfacht es enorm ihn Autonom agieren zu lassen da er somit weiß wo er sich befinden 'müsste', insbesondere da Positionsbestimmung innerhalb von Gebäuden nicht gerade billig oder einfach umzusetzen ist aber GPS auch nicht sooo super genau ist.


    Mein Plan ist ja zunächst ihm eine PathMap vorzugeben, ich bestimme also ganz genau wie groß ein Raum ist und wo Hindernisse sind. Somit kann ich ihm einfacher sagen/anweisen "fahr in die linke Ecke" und der RoPi berechnet dann den effektivsten Weg um Hindernisse herum. Bei der Fahrt erkennt er aber auch Hindernisse und reagiert darauf (Neuberechnung).
    Oder er erkundet ein Raum im Lernmodus und fährt an der Wand entlang, speichert die zurückgelegte Strecke und ich kann ihm dann im nachhinein sagen "Das ist das Wohnzimmer, da steht ein Stuhl" usw..


    Und genau dafür sind solche Rad Encoder Gold wert ;)


    Dazu dann noch ein Kompass damit er die Richtung weiß.


    Die von dreamshader zB sind eher nicht so leicht zu gebrauchen - kennt der ein oder andere vielleicht noch von alten Kugelmäusen vom PC, auf der einen Seite ist ein Sender auf der anderen ein Empfänger und in der Mitte dreht sich eine Scheibe mit Öffnungen... Nur das an ein Rad anzubringen ist nicht so einfach bzw zumindest nicht wenn man ein fertiges Chassis nimmt.
    Die Selbstbauweise mit Hallsensor ist ebenfalls nicht so einfach sofern man nicht die Reifen/Felgen beschädigen will.
    Also bleibt dann nur ein Getriebemotor mit integriertem Encoder oder man setzt sowas auf die Achse.
    Man brauch aber auch mindestens 2, also einen pro Antriebswelle/Seite, weil das Gefährt ja nicht nur gerade aus fährt sondern auch mal eine Seite schneller dreht bzw in eine andere Richtung als die andere Seite, um zu wenden ;)

  • Achja, lest euch mal > diesen Artikel < durch und dreamshader guckt dann mal bitte speziell unter Ganz professionell und dort in der Mitte des ersten Absatzes :fies:



    Leider stocher ich aber noch immer im Dunkeln wie ich am einfachsten eine PathMap erstellen und wie die dann auch vom RoPi verwendet werden kann :s



    //EDIT: Habe gerade eine Projekt Seite vom Rover5 gefunden, was mir einiges erleichtern wird

  • So so ...


    ich denke halt: Stepper oder aufgebohrte Servos (Anschlag entfernt) sind da sinnvoller.
    Rein theoretisch könnte man auch ein Motor-Potentiometer nehmen ;) ...
    btw: dieser Mensch, der o.g. Potis vertickt, hat echt gute Teile im Angebot - alles neue Markenware (Alps) aber recht günstig.
    Hab' ich mal durch Zufall entdeckt ...


    cheers,
    -ds-

  • Mathias: Vielen Dank für den Tip - der RP6v2 sieht wirklich sehr sehr interessant aus - einen AVR braucht man ja so oder so, der PI soll die gesammelten Daten nur kontrollieren bzw dem Owner bereitstellen und dessen Befehle umsetzen ;)



    Ich wollte für das Projekt auch ein B+ verwenden da ich dann auf einen aktiven USB-Hub verzichten kann, um ein AVR (bzw ggf sogar 2 AVR's) und WiFi anzuschließen


    Das einzige was mir zZt noch Sorge bereitet ist das ich nicht möchte das die Motoren nur An oder Vollepulle kennen. Da weiß ich noch nicht wie das über den jeweiligen MotorDriver realisiert werden kann bzw ob jetzt in dem neuen Fall der RP6 das beherrscht :huh:


    Zur Umsetzung stell ich mir das so vor das der RoPi schneller fährt wenn er kein Hindernis in 2 Meter Reichweite sieht und dann eben langsamer fährt um so näher das Hindernis kommt, bis er dann kurz vorher stehen bleibt.. Dann eben solange er Autonom fährt. Wenn die Steuerbefehle aber vom Owner kommen soll er nur kurz vor dem Crash automatisch stoppen (es sei denn der Owner stellt diesen Schutz aus um zB einen Ball schieben zu können)


    Ich hab jetzt schon ein bisschen Quellcodes und Beispiele gesammelt und glaube das ich zumindest das Fahren und Kommunikation zwischen AVR und PI schon realisieren kann.
    Das größte Problem stellt aber hierbei weiterhin das erstellen (bzw wie man das macht) einer PathMap dar, und wie der RoPi diese dann verwenden kann. Oder auch wie der PI diese selber erstellen kann... Habe ein paar Videos gesehen wo das zB Rettungs Roboter auch machen also eine PathMap selber erstellen, aber da wird leider nirgends beschrieben wie das umgesetzt wird :(

  • Meine bisherige Überlegung war einfach den jeweiligen Wert an den AVR zu schicken.
    Also im Sketch vom Motor-Controller-AVR bau ich ein das er auf Befehle über Serial reagieren kann/soll. Da übergebe ich dann einfach einen Zahlenwert von zB 255 für VollePulle und die Hälfte wäre dann halt 127,5 bzw abgerundet 127.
    Somit kann ich auf den einen PWM-Pin des RPI's oder langsameres SoftwarePWM verzichten - so hoff ich zumindest ;)

  • Allso ich hatt früher einen RP6. Hab ihn aber aus Frust wider verkauft. Bin an C++ gescheitert.
    Die Geschwindigkeit müsstest man per PMW steuern. Es gab sogar ein Script das ein Tönekonzert macht :D

  • Hey meigrafd, alter Haudegen ...


    wie schon mehrfach erwähnt ist PWM da das Zauberwort.


    Ich häng Dir mal einen sketch von mir an ... ist alles weder ausgegoren noch komplett, aber vielleicht ganz informativ.
    Ich habe zwei dieser "Billig-Getriebe-Motoren" mit Rad-Encodern und greife da jeweils rechts und links die Umdrehungen ab. Das soll mal dazu dienen, dass ein Pro Mini sowohl die Synchronisation übernimmt als auch die gesamte Steuerung auf Kommando.
    So ähnlich, wie Du es da scheinbar auch schon angedacht hast.


    Vielleicht hilft Dir der sketch ja ein bisschen,
    cheers, und bis denne,
    -ds-

  • Die Fahrgeschwindigkeit mach ich dann ja auch via PWM, aber das übernimmt dann der AVR, nicht der PI. Der PI sagt nur wie hoch der Wert sein soll, der AVR stellt dann seinen PWM entsprechend ein :)


    Aber die Frage is halt ob der Motor-Driver vom RP6 auch wirklich PWM versteht oder doch nur son abgewandelter Schrittmotor scheiß is, der dann nur in passender Frequenz an/aus geht :no_sad:


    [hr]


    Im Punkt Wegfindung und Lernmodus will ich halt sowas wie folgendes erreichen: http://www.societyofrobots.com/images/sensors_IRSLAM.gif


    Dabei wird das sog. SLAM (Simultaneous Localization And Mapping) verwendet, was Bestandteil der aktuellen Robotik Forschung und sehr komplex ist...


    Um also nicht gleich von 0 auf 100 durchzustarten werde ich zunächst mit dem sog. wavefront algorithm anfangen (der Link beschreibt das recht gut mit Codebeispielen)


    Soweit ich das verstanden habe wird das in etwas so aussehen:


    Ein Raum wird in viele kleine Quadrate eingeteilt (sog. Nodes), die von der Größe her die Abmessungen des RoPi's entsprechen (so lässt es sich präziser navigieren) und als X und Y Koordinaten festgelegt werden.
    Dann werden die Quadrate in denen Objekte bzw Hindernisse stehen rot markiert bzw mit einer 1 versehen. Quadrate mit einer 0 darf er befahren, mit einer 1 nicht.


    Im Algorithmus sind diese Werte allerdings etwas anders:
    Nicht befahrbare Quadrate haben den Wert 255
    Befahrbare Quadrate haben den Wert 0
    Der Roboter selbst hat den Wert 254
    Das Ziel wohin der Roboter fahren soll hat den Wert 1


    Der Algorithmus fängt nun oben rechts an zu zählen und geht jede einzelne Node durch, ignoriert alle 255'er Werte und natürlich auch sich selbst, zählt die dann zusammen und legt den kürzesten Weg zum Ziel fest (geringste Zahl an Nodes die durchfahren werden müssen).


    Auch wird der RoPi ausgebremst wenn man nach jeder Fahrbewegung stehen bleiben muss um den Bereich in Fahrtrichtung nach unbekannten Objekten zu scannen.. Aus diesem Grund möchte ich den vorderen Bereich mit 3 Ultraschall Sensoren verstehen (einer Mittig und die anderen im 45° Winkel jeweils zur Seite) und diese ständig auslesen bzw in Realtime auf Veränderungen reagieren können.


    Die Schwierigkeit besteht aber auch darin dass der Microcontroller nicht genügend Flash hat um alle Maps zu speichern. Ich muss also eine Möglichkeit finden bzw entwickeln wie ich neu erkundete Map-Daten vom RoPi empfange, sinnvoll speichere und dann auch die Gegenrichtung, dem RoPi wieder zur Verfügung stelle. Das wird insbesondere dann heikel wenn er mehrere Räume oder größere Räume abfahren soll.



    //EDIT: Ich hab jetzt schon mehrmals gelesen das Kettenantrieb nicht so gut ist wenn es um Positionsbestimmung geht, wegen des Schlupfs und den starken Abweichungen der Encoder in Kurven... Werde also mal nach einem alternativen Chassis mit Rädern ausschau halten müssen :(