Von a nach b

[Dahris]

Vielen Dank für die vielen Antworten. Entschuldigung für das Gestammel, ich versuche alles zu beantworten...

Ich geh in eine Schule mit IT Schwerpunkt und jeder in der Klasse muss sein eigenes Projekt alleine machen. (also kein Gruppenprojekt)
Es ist eine Aufgabe von meinem Lehrer, da er meine vorherige Idee zu kompliziert fand.
Da ich auch bei meiner eigenen Idee mit einem Pi arbeiten wollte, kenne ich mich gut damit aus. (ich hab im Sommer einen Stimmenautomatisierten Pi als Mediacenter "gebaut" -> war ein großer Teil meines ersten Projektes) Jedoch hatte ich 2 Monate Zeit dafür zu recherchieren und es war kein mobiler Roboter geplant.

Mein Lehrer hat gemeint, dass ich einen fertigen Roboter (der eine Traglast von 5kg aushält) kaufe, der mit einer Fernbedienung kontrollierbar ist und mir dann etwas einfallen lassen soll wie ich diesen Roboter automatisieren kann.
Mir ist auch bewusst wie teuer dieses Projekt werden wird.

Das Projekt fliesst nicht in die Note ein, ist aber für das Schuljahr ein Muss-Kriterium.
Der Boden besteht bei meiner Testfläche sowohl wie in der Schule aus Fliesen.


Es muss nicht ein Pi sein, war nur ein Vorschlag meines Lehrers da ich mehr Erfahrung damit hatte als zB mit Arduino.
Lego NXT hört sich aufjedenfall schon vielversprechend an und das mit dem Staubsaugerroboter habe ich schon einmal vor einer Weile in Betracht gezogen.

Ich versuche es nochmal und hoffentlich etwas verständlicher aufzulisten, wie mein Lehrer mir diese Aufgabe zugeteilt hat:

+ Ich brauche einen Roboter der 5kg tragen kann (ich habe nochmal nachgefragt und 5kg genügen)
+ Mit einem Programm soll dieser Roboter von einem Startpunkt zu einem Ziel fahren. Der Weg wird aber nicht gerade sein, da er durch mehrere Räume fahren soll
+ Damit der Bot nicht in Schüler reinfährt, soll er ausweichen können

Bei meiner Aufgabe ist der Roboter selber nicht das wichtige, sondern, dass der Roboter automatisch beim Starten einen bestimmten Weg befahren kann ohne von der Traglast zusammenzufallen.

Entschuldigung für dieses Mischmasch, aber ich weiß nicht wie ich es genauer beschreiben kann...

LG
D

[i_make_it]

Traglast 5 kg oder Zuladung 5kg?

Wenn die Traglast 5kg ist und z.B. das Eigengewicht inklusive Antriebe, Sensoren, Steuerung und Stromversorgung 3kg ist, bleibt für die Zuladung nur noch 2kg.

Damit der Bot nicht in Schüler reinfährt, soll er ausweichen können

Das kann knackig werden.
Im ersten Versuch kann man das ganz normale Ausweichverhalten nehmen das man auch für Möbel und Wände nimmt, aber Menschen sind in der Regel nicht ortsfest sondern laufen rum.
weshalb oft einfach stehen geblieben wird bis der Mensch den Weg frei macht.

von einem Startpunkt zu einem Ziel fahren. Der Weg wird aber nicht gerade sein, da er durch mehrere Räume fahren soll

Zwischen Start und Ende sind 1-2 Haltestellen.

Eine Möglichkeit wäre eine Leitmarkierung (Stichwort Linienfolger) für die Strecke und Barken an den "Haltestellen"
Da muß man halt klären ob man eine Klebebandlinie auf den Boden machen darf.

Ohne ein solches Leitsystem, muß der Roboter über eine Karte verfügen und die Möglichkeit sich selbst in der Karte zu verorten.
Damit bist Du dann auf Nivau eines Unistudiums.

Hier mal ein paar Links zum Thema Roboternavigation/Kartierung:
https://users.informatik.haw-hamburg...nck/folien.pdf
http://www.statistik.lmu.de/institut...428-slides.pdf
http://ocw.mit.edu/courses/aeronauti..._blas_repo.pdf
http://www.diva-portal.org/smash/get...FULLTEXT01.pdf
http://www.cs.cmu.edu/~16899/notes/slam_ieee.pdf

Frag mal deine Lehrer ob Sie sich des Umfangs der Aufgabenstellung bewusst sind.
Sowohl von den Kosten, dem notwendigen Wissen und dem Zeitaufwand für eine Person.

[HaWe]

das mit dem "Niveau eines Unistudiums" halte ich für hanebüchen, ich habe es als reiner Hobbybastler mit Lego gemacht. Odometrie braucht nur etwas Trigonometrie. Nacheichen mit Gyro oder externen Baken ist aber schon besser, klar, aber man kann ja erstmal klein anfangen.

Fürs Ausweichen gibt es von Lego Ultraschallsensoren (im Startset enthalten), die sind absolut simpel zu programmieren.
Wichtig dabei: den alten NXT verwenden (gebraucht, Ebay etc.), nicht den neuen EV3, denn da ist die Programmierung viel komplizierter.

Dann war von einer Zuladung von 5kg die Rede, nicht von einer Tragfähigkeit des Fahrgestells von bis zu 5kg. Gesamttragfähigkeit des Gestells ist also Eigengewicht plus 5kg Zuladung.

Auch mit Linuxkenntnissen halte ich den Pi aber wegen seiner miserablen Echtzeitfähigkeit (u.a. für Encoder-Pins) für absolut ungeeignet (außer mit Extension-Board, wie z.B. Propeller-HAT, kostet aber wieder extra).

Für die Plastikachsen von Lego ist das Gewicht aber dennoch eine Heraussforderung (auch wenn Lego-Plastik insgesamt leicht ist).
Metallachsen (Metabo, Märklin, Trix, Metallus) mit Adapter auf die 5mm Kreuzachsen funktioniert aber sehr gut (wie in meinen oben verlinkten Modellen). Dann kann man sogar ein Sperrholzbrett als Basis-Chassis verwenden.

Die Programmierung ist nicht schwierig, wenn man preemptives Multitasking (NXT) oder wenigstens cpu-Timer-IRQs (Arduino Due) und mindestens 30kB RAM für die Karte und die Wege hat.

Das ganze nicht rein odometrisch - sondern z.B. als Linienfolger - würde die Sache natürlich noch weiter vereinfachen, auch Hindernis-Ausweichen per Ultraschall-Sensor-Führung ist damit möglich (Linie verlassen, Hindernis im (Halbkreis-) Bogen umfahren, bis man wieder auf die Linie trifft). Auch ein Lichtsensor ist für Linienfolger im NXT Basis-Set enthalten.

[i_make_it]

das mit dem "Niveau eines Unistudiums" halte ich für hahnbüchen, ich habe es als reiner Hobbybastler mit Lego gemacht. Odometrie braucht nur etwas Trigonometrie.

@ HaWe: Wenn Du meinen Text aufmerksam liest und Dir die Links ansiehst, stellst Du fest das ich nicht von Odometrie schreibe sondern von Kartierung und wie sich ein Roboter selbst darin verortet.
Also Occupancy Grid/Vektorkarten und SLAM.
Sowie Korrektur der Karten beim mehrfachen durchfahren des selben Raums um Messungenauigkeiten zu elliminieren.
Also Koppelnavigation, Kalmanfilter, Monte-Carlo-Lokalisierung etc.
Bei Kartierung mit Eigenbewegung, ortsfesten Hindernissen UND beweglichen Hindernissen (Menschen) erstellt man Zeitdiskrete Karten und integriert diese dann wieder um die ortsfesten Hindernisse zu filtern. Diese sind ja entscheident für die Routenplanung bei Ausweichmanövern.
Es bringt ja nichts dem Menschen auszuweichen und dann vor der Wand zu stehen. Also beim Ausweichmanöver die Ortsfesten Hindernisse mit berücksichtigen wenn z.B. der Mensch vorne links ist aber rechts dann nicht mehr genug Platz ist um hinter dem Menschen weiter zu kommen.
Dan greift nicht das einfache Ausweichen sondern die Routenplanung muß die Ausweichroute möglichst in Echtzeit berechnen. (Oder man bleibt stehen und wartet bis der Mensch weg ist)

Die Aufgabenstellung ist eigentlich genauso anspruchsvoll wie ein fahrerloses Auto das am Straßenverkehr teilnehmen soll.
Wenn das mit etwas Trigonometrie machbar ist, dann geh damit mal zum Patentamt bevor Mercedes, BMW und Co. das selbst anmelden. (Sorry der musste sein)

[HaWe]

na, aber jetzt...

die Odometrie ist doch die Basis der eigenen Positionsbestimmung per Koppelnavigation, um sie dann anschließend in die eingespeicherte Karte einzuprojizieren.

D.h., man braucht eine Karte der Räume und den Startpunkt des Roboters, den Rest der Wegefindung macht der Roboter per Odometrie-Messungen (das ist ja die besagte Koppel-Navigation).
Nach dem Motto:
2m geradeaus,
dann 30° nach rechts,
dann 4 meter geradeaus,
dann 90° links,
dann 1m geradeaus
- dann...: Sie haben das Ziel erreicht!

So funktioniert das, wo ist das Problem?

Selbst dafür wären jetzt Karten noch nicht mal zwingend notwendig,
a-Bär: Odometrie ist ungenau, und so kann man die (bekannten) Wände in der eingepeicherten Karte bereits als Navigationshilfe mitverwenden, um die Odometrieposition zu berichtigen (wenn man sich in der Mitte des Gangs wähnt, aber plötzlich doch an der Wand anstösst). IMUs (Gyros) machen es NOCH etwas einfacher, aber es muss ja für das Projekt nicht gleich 100% perfekt sein.

Fürs Umfahren von Hindernissen gibt es übrigens auch den Bug- oder Bug2-Algorithmus, und ganz ohne feste Steuer-regeln noch den Astern (A*), aber das ist dann schon ein ganz klein wenig schwieriger (aber auch mit Lego bereits gelöst).

[i_make_it]

@HaWe: Dein Ansatz funktioniert bei vollständig bekannten Karten.
Nicht ortsfeste Hindernisse (Menschen) bedeuten automatisch die Karten sind nicht vollständig bekannt.
Nimm deinen Ansatz mal beim Autofahren und stelle dann Fest das eine Tagesbaustelle deine 4 Meter gradeaus blockieren.
Schon fällt dein System in sich zusammen. (ein Tag warten bis das Hinderniss wieder weg ist)
Sobald bewegliche Hindernisse ins Spiel kommen wird das alles viel spannender (komplizierter)
Und das ausweichen vor Menschen ist halt Teil der Aufgabenstellung.
Eine einfache Pfadplanung in einer Umgebung nur mit ortsfesten Hindernissen ist ein Anfang, so habe ich in den 90ern auch mal angefangen und werde es mit meinem Großneffen auch wieder so machen. Aber es geht hier ja um eine konkrete Aufgabenstellung bei der die Randbedingungen festgelegt sind.

Wobei ich mir die Frage stelle ob die Lehrer die diese Aufgabe formuliert haben sich der Komplexität derselben bewust sind.

[HaWe]

mein Ansatz funktioniert auch bei nicht störungsfrei befahrbaren Routen.
Denn wenn ein Hindernis auftaucht, gibt es 2 Möglichkeiten:
1. kurz stoppen und warten, ob es sich von alleine wieder wegbewegt
2. wenn es nach einer bestimmten Wartezeit nicht weg ist, dann im Bogen mit Abstand umfahren, bis man wieder ein Stück weiter vorn auf der geplanten Kurslinie gelandet ist.

Kein Lehrer wird erwarten, dass ein solches Schüler-Modell in allen erdenklichen Situationen 100% funktioniert, aber in ausgesuchten Standardsituationen gibt es einfache Lösungsstrategien.

Wären da nicht die 5 kg Zuladung, wäre es ein ideales Modell für Lego:
wegen Speicher, Encoder für Odometrie, ein oder mehrere Ultraschallsensoren, nötigenfalls Sensormultiplexer, parallel-läufigen Firmware-Sensor-Tasks (die automatisch Sensorzustände im Hintergrund auswerten, z.B. automatisch Encoderwerte weiterzählen, ähnlich wie Linux-Demons) sowie Multitaskingfähigkeit und damit der Möglichkeit für eine Subsumption-Programmarchitektur (Behaviour-events), um strukturiert auf Situationen reagieren zu können. Als Lego-NXT-Projekt für 500g Zuladung könnte ich da aus dem Stegreif jede Menge praktische Tipps geben, die extrem schnell umzusetzen sind (wenn die erlaubt sind).

Alles schon gemacht.

Mit einfacher AVR-Programmierung ist das aber eher nicht - oder nur mit ungeheurem Aufwand - zu machen.

[Rabenauge]

Im Grunde kann das jedes Spielzeugauto, was ausreichend gross ist (bissel was muss rein und ne Ladeplattform brauchen wir auch), und wo man den passenden Motor (wie sie der Wild Thumper z.B. hat) einbauen kann. Ungefedert ist besser, die kann man auch "mal" gnadenlos überladen, dauerhaft muss es das ja nicht aushalten.

Kartierung würd ich lassen (das verlangt mit Sicherheit _kein_ Lehrer an irgendeiner Schule), und dann reicht nen Arduino völlig aus- oder eben der Pi, der aus undurchsichtigen Gründen scheinbar verwendet werden soll.
Beim Pi gehts natürlich mit Karte- mit nem Arduino ansatzweise noch (soo präzise muss die auch wieder nich sein, man kann alles übertreiben). Im Grunde genügt ne einfache, zweidimensionale Matrix, dynamisch muss die hier nicht sein.
Wenn ich da die Umgebung in halbmetergrosse Quadrate aufteile (genau genug um auch noch ne Tür zu finden), und die als "befahrbar oder nicht" markiere, geht das, denke ich.

Wir haben hier nen riesigen Vorteil: das Einsatzgebiet ist bekannt.
Somit kann man die Karte bereits im Vorfeld erzeugen, und einfach ablegen.
Gegebenenfalls auch mehrere mögliche, auf SD-Karte z.B. (auch das geht mitm Arduino locker ab).
Die Feinheiten erledigen wir dann mit Odometrie (die sich, z.B. an bekannten Punkten, wie Türen, wieder mal kalibrieren lässt) und entsprechenden Sensoren- nen paar US-Sensoren vorne und seitlich erledigen das.
Hier gibts echt keinen Grund für schwere Waffen...

Möglicher Aufbau: drei US-Sensoren in der Front (zweie genügen wohl auch, aber einer mehr schadet nicht), an jeder Seite noch einer. Hinten- nur wenn aktives Ausweichen wirklich gefordert wird, und somit Rangiermanöver anfallen können. Ansonsten brauchen wir den nicht, wenn Hindernisse erkannt werden, halten wir einfach an, oder versuchen, sie vorwärts zu umfahren.
Odometrie mittels Encoder am Motor (einfache Sache, da fertig zu kaufen), auch ne Mauskamera wäre denkbar- und präziser.
Kriegt man auch noch mit nem Arduino hin. Einzig der Bodenabstand muss mittels anderer Linse angepasst werden, aber dann funktioniert das hervorragend.
Die zu fahrende Strecke messen wir grob aus und übertragen sie als "Karte" in ne zweidimensionale Matrix. Soll das unbedingt im Vorfeld bereits passiert sein, dann eben auf ne SD-Karte, nen zusätzlichen EEPROM oder sonst irgend was.
Dort ist sogar ein ganzer Plan des Gebäudes möglich- wir brauchen es nur rudimentär!
Auflösung: Quadrate von 50x50cm, wenn genug Speicher da ist, kann man sie kleiner wählen, dann wirds präziser.

Bei unbekannten Hindernissen wird gestoppt, den (vorher bekannten) Weg können wir direkt in der Karte ablegen.
Falls man mehr will: einfach eine komplette Karte des Einsatzgebietes ablegen, die bekannte Hindernisse bereits enthält. Dann müssen, wenn ne unbekannte Strecke gefahren werden soll, nur Start-und Zielpunkt noch in die Karte eingefügt werden.
Das würde immer noch mit nem Arduino gehen: die "Karte" auf nen kleines Touchdisplay zeichnen, und dann wird nur Start-und Zielpunkt live eingegeben. Würde mit nem normalen Arduino wohl etwas eng, aber nen Mega2560 packt auch das noch.
Und: diese Variante wär für Zuschauer natürlich beeindruckend, das macht einfach was her....
Geht mitm Pi auch, für den gibts ja auch so handliche Touchscreens.
Die Wegberechnung kann man durchaus so machen, wie HAWE das bereits beschrieben hatte, da gibts einige, nicht allzu schwierige, Vorgehensweisen.
Auch erweiterbar ist es: "Fahre von A nach B, OHNE über C zu fahren" oder anderes...

Somit nen durchaus überschaubarer Aufwand, wobei ein Pi die Sache komplizierter macht, als es nötig wär...es ist ganz sicher mit nem Arduino Mega 2560 lösbar, und das dann schon recht komfortabel.
Passende Motortreiber gibts zu Hauf, ebenso US-Sensoren, Displays usw.

Ich persönlich würd versuchen, die Nutzlast runter zu handeln, einfach, weil die vieles an der Geschichte unnötig aufwendig macht: nur deshalb braucht man nen stärkeren Antrieb, nur deshalb dann auch ein grösseres Chassis (ohne den Quatsch könnt nen RP6 das nämlich locker erledigen!)...
Aber da fällt mir ne Alternative ein: an das Fahrzeug (kann dann nen recht einfaches Roboterchassis sein) einfach nen Anhänger dran.
Dann _geht_ das mit nem RP5 (ggf. bissel Ballast rein, damit er das zieht, weiss nicht, wieviel Grip die haben), und für die Nutzlast reicht irgendein Bruder-Spielzeuganhänger.
Zum rangieren besser was einachsiges.....