ich habe ein paar Ideen zusammengeschrieben, aus denen ich gerne etwas funktionierendes Machen möchte.
Es wäre schön, wenn Ihr euch das mal anschaut. Ich freu mich auf euren Input und eure Kritik.
Ich will nicht auf alles eingehen, aber das Projekt hört sich schon mal recht interessant an (vor allem, wenn ich mir vorstelle, wie der RP6 versucht, über Rasen zu fahren ).
Als erstes wäre es angebracht, die Sachen die man ins Netz stellt, vor dem Hochladen nochmal zu lesen. Dann fallen nochmal Rechtschreib und Grammatikfehler auf und für die anderen wird es dann leichter lesbar.
So, nun zum eigentlichen Projekt.
Deinen Umsetzungsplan finde ich sinnvoll. Erstmal die Grundlagen schaffen und nicht alles auf einmal machen.
Inwieweit du deine einzelnen "Module" nochmal überarbeiten musst, wird sich zeigen. Je nach Fläche reichen vielleicht schon Odometrie und Fixpunkte zur verlässlichen Navigation.
Zu den Karten:
Vektorkarten zu verarbeiten ist wirklich aufwendig, davon würde ich auch Abstand halten. Eine reine Rasterkarte ist auch nicht das Richtige (wie du schon sagtest, viel Speicherbedarf). Zwar könnte man das Speicherproblem mit einer SD-Karte und ein wenig RAM lösen, aber es geht auch einfacher.
Überlege dir doch mal, ob du wirklich jeden Punkt in deiner Karte verzeichnen musst. Reicht es nicht schon, wenn du eine Liste von Punkten führst, die irgendwelche interessanten Sachen darstellen?
Der Speicherbedarf wäre sehr gering (zB.: ID,Art,posH,posV).
So könntest du Hindernisse, Zielpunkte etc. darstellen (eigentlich genau wie die POI's beim GPS).
Deine Position sollte dir ja bekannt sein. Dann brauchst du "nur" noch einen Algorithmus, der möglichst effizient die Abstände zu den einzelnen Punkten berechnet. Liegt ein Punkt innerhalb eines bestimmten Radius, wird ein Event ausgelöst und entsprechend reagiert.
Man könnte den Rechenbedarf weiter verringern, wenn man z.B. verschiedene Listen für verschiedene Zonen erstellt. Da gibt es sicher viele Möglichkeiten (und in Bibliotheken ganz viele schlaue Bücher).
So, ich hoffe, das war so die Art Input, die du dir erhofft hast. Ich bin gespannt, wie du weitermachst und wünsche dir viel Erfolg.
dein Entwurf gefällt mir gut. Jetzt kann ich besser einschätzen, wo du mit deinen Überlegungen stehst, und welche Prioritäten du setzt. Die Modularisierung des Projekts zeigt ein professionelles Vorgehen. Ausserdem mache ich das selbst auch gerne so.
Bin schon gespannt, welche Teilaufgabe du dir zunächst vornimmst.
@lokirobotics: Ja. Genau die Art von Feedback habe ich mir gewünscht. Vielen Dank. Der RP6 wird so wie er ist bestimmt viel Spaß mit Rasen haben - vor allem mit hochstehendem Grass...
Wenn du eine - preiswerte - bessere Plattform kennst, bin ich für Anregungen dankbar.
@Hannes: Danke für die Blumen
Wie beschrieben werde ich mit den Sensoren anfangen. Und den RP6 nur auf dem Schreibtisch oder Boden fahren lassen.
Die Bestellungen sind schon raus. Ich habe die GP2D120, HMC6343 und SRF10 bestellt...
Ich werde mit den IR Sensoren anfangen, damit mir der RP6 nicht vom Schreibtisch hüpft.
Ich hoffe nur, dass der teure HMC6343 hält was er verspricht. Es gibt keine Erfahrungsberichte mit dem Ding. Ich glaube aber für unebenes Gelände (selbst an Teppichkanten) ist der CMPS03 ungeeignet...
Mein größtes Problem ist die korrekte Elektronik und der Einbau. Ich habe schlicht Sorge das 500 Eur in Rauch aufgehen.
Aber als Erstes ist Erfahrung sammeln angesagt - wenn ich das richtig verstanden habe ist es nicht so ganz einfach verlässliche Werte aus den Sensoren herauszuholen.
Die Softwareschnittstelle für die Sensoren entsteht jedenfalls bereits...
Ich möchte eine Abstraktion der Sensoren gegenüber den nutzenden Einheiten. z.B. das die Sensorenutzer lediglich Fragen "In welche richtung gucken wir" und entweder die Richtung zurückbekommen oder ein "Unbekannt" (sollte der Sensor nicht da sein oder Mist liefern) eine andere wichtige Funktion soll die "Wo bin ich" sein...
Die Nutzer sollen ihre Rechenzeit nicht mit Gewichtung oder Verlässlichkeit der Rohinformation verbrauchen müssen, sondern vielmehr "saubere", bei Bedarf auch unsaubere mit entsprechder Einschätzung oder gar keine Daten erhalten.
"Inwieweit du deine einzelnen "Module" nochmal überarbeiten musst, wird sich zeigen. Je nach Fläche reichen vielleicht schon Odometrie und Fixpunkte zur verlässlichen Navigation. "
zumindest für den "bahnenmodus" gilt doch:
wozu fixpunkte wozu odometrie? der roboter fährt die bahnen ab. dabei reicht es doch die richtung zu halten. die richtung wird mit dem kompassignal immer wieder korregiert. und selbst beim wendemanöver am ende der bahn würde es doch reichenden, den mäher anhand der kompassinformation um ein rad zu drehen um ihn auf die benachbarte bahn zu setzen. oder?
und auch nen kreuz und quer kurs sollte sich aus richtung und zeit generieren lassen.
dann kann zum schluss nochmal die induktionsbegrenzung abgefahren werden, um die unsauberen ecken, die je nach mähergeometrie entstehen, zu entfernen und gemäht ist der rasen...
...oder?!
das konzept ähnelt meinem übrigens sehr... aber es wird mir immer klarer, dass das schon ziemlich hohe schule ist und ich wohl viel zeit brauchen werde!
nur kurz zum Kompass: also ich kann nur sagen, dass er sehr gut ist! Wir haben ihn bereits erfolgreich in einem U-Boot zur Navigation eingesetzt. Bitte komm aber nicht auf die Idee, den selbst auflöten zu wollen, das geht in der Regel daneben. Wir haben ihn damals hier gekauft; ist auch billiger als ihn bei Digikey oder so zu ordern...
@stripmower: Im Moment gehe ich noch davon aus, dass ich ohne Induktionsschleifen auskomme. Die Richtung bekomm ich mit dem Kompass in den Griff, die Distanz ist noch ein Problem (wenn man davon ausgeht, dass es die Traktion bei unterschiedlichen Untergründen die Drehzählermessungen verfälschen können (Sand, Schlamm, Maulwurfhügel, etc).
Ich bin noch am überlegen wie ich das löse - im Moment denke ich über eine zyklisch "Eichung" an einer Bake und damit an einem bekannten Punkt nach - also nach einer gewissen Zeit zur Bake fahren und die Distanzcounter auf Null setzen... Nicht elegant aber erstmal einfacher als trigonometische Peilung...
Und: Ja das braucht Zeit und Geld - ich habe schon ca. 50 Stunden nur in die Motorsteuerung reingesteckt. Und das Sch**ßding fährt noch nicht mal sauber gerade aus. (Natürlich ohne Kompass)
@Ozzy: Bei sparcfun habe ich auch zugeschlagen - interessante Module die ich dort auch gefunden habe ist die I2C Echtzeituhr und ein I2C Levelconverter von 5V auf 3.3V - auch wenn mich der nachträgliche Einfuhrzoll doch stark überrascht und geärgert hat.
Das mit dem Zoll kann ich gut verstehen; ist schon ärgerlich! Und immer schön an Sicherungen und Schutzschaltungen denken, das ist die best investierte Zeit bei solchen Projekten!!!
"im Moment denke ich über eine zyklisch "Eichung" an einer Bake und damit an einem bekannten Punkt nach - also nach einer gewissen Zeit zur Bake fahren und die Distanzcounter auf Null setzen... Nicht elegant aber erstmal einfacher als trigonometische Peilung... "
ich weiß nicht, ob das so viel einfacher ist als eine trigonometrische peilung:
sinus-, kosinus- und pythagorassatz sollten für eine korrekte peilung mit zwei oder mehr baken ausreichen ausreichen.
die trigonometrischen funktionen sind recht simpel und es ist eine permanente ortsbestimmung möglich.
man könnte also sogar völlig auf den kompass verzichten indem man permanent den ort bestimmt und zur kurskorrektur mit dem sollwert abgleicht. der mäher fährt dann also nicht die bake an, sondern die jeweils vor ihm liegenden soll-punkte, die beispielsweise 10cm auseinander liegen.
ich hatte eine lustige und aufschlussreiche Disskussion mit Hannes (vohopri) zum Thema. Die Peilung mittels Baken ist nur in der Theorie einfach.
Da sind so lustige Themen wie Genauigkeit, Übertragungstechnik (IR, US, Laser, ... hat alles Vor- und Nachteile - und vor allem praktische Haken)
Ich bin ursprünglich mal davon ausgegangen, das eine Ultraschallquelle und drei Micros reichen sollten. Die Messung der Differenz zu den Messzeitpunkten sollte aufschluss geben. Theoretisch sollte das mit Ultraschall und einer gemeinsamen Zeitbasis gehen... Leider bewegt sich Ultraschall mit 33,33 cm pro ms.. Da wird es schwierig mit der Messung.
@Ozzy: Jahaaa. Leider bin ich nicht der Elektronik-Schwarzgurt... Daher: Versuch macht kluch... Bis jetzt ging gut ;-)
Zitieren).
Lesezeichen