Rasenmäher mit Navigation => neu mit A* Wegfindung!

Hallo,

ich beobachte die ganzen Rasenmäher Gechichten schon ca. zwei Jahre. Ich habe vor ca. einem Jahr angefangen mir einen zu bauen.

Ich habe ihn sehr robust gebaut, da ich ca 1600m² Rasenfläche hab mit Hängen. Mein Rasenmäher (SHEEPi) wiegt jetzt mit Akku 14kg. das meiste Gewicht macht die 5mm Alu-Grundplatte und der Bleigel Akku.
Die 385er Motoren waren da überfordert.

Hier zwei Bilder vorm letztem Umbau (nur noch ein Akku, Elektronik nur noch eine Box, nicht mehr Leistung und Steuerung getrennt, Denso Motoren mit Direktantrieb statt 540er mit Riemen)

Bild hier  

Bild hier  

Hallo,
Sieht wirklich sehr massiv aus! :) Wie ist es denn mit diesen Rädern, ist nicht zu viel Gewicht am vorderen?
Ja, mit den 385er Motoren braucht man da nicht mehr zu kommen, bei mir gehts da meiner viel leichter ist und die Planetengetriebe die doppelte Belastung aushalten als die normalen Stirnradgetriebe. Und dabei viel leiser sind.
Um Gewicht zu sparen kann ich die LiFePo Zellen empfehlen, die 4 Zellen für 12 mit 10AH wiegen 1.4kg.

Wie weit ist der Robi schon im Einsatz? Schleifensensoren sehe ich keine, oder sind die gut versteckt?

LG!

Bin grad dabei mein Projekt mal bei "(fast) fertige Projekte" vorzustellen. Das dauert blos etwas alles zu schreiben

Die Entwicklung an diesem Mäher ist für mich jetzt abgeschlossen, ohne große Umbauten sind keine Neuerungen mehr möglich:

Er kann:

• Fahren zu bestimmten Zeiten,
  Randmähen an bestimmten Tagen,
  Anzeige an welchem Tag zu welcher Uhrzeit er das nächste Mal losfährt,
  "Ladestation" anfahren,
  Ränder abfahren in beiden Richtungen, normalerweise mit beiden Sensoren, an einer Stelle wo der Boden sehr zum Zaun hängt fährt er nur mit dem linken(äusseren) Sensor um nicht zu leicht hängenzubleiben
  Spiralfahrt links-rechts herum, an bestimmten Positionen oder wenn die Messerdrehzahl stark sinkt
  Fahrgeschwindigkeit abhängig von der Mähleistung (dh dichtes Gras, geringere Messerdrehzahl, langsamer fahren)
  Navigation, die wenn er Schwierigkeiten (viele Kollisionen) hat abgebrochen und von der aktuellen Position aus neu gestartet wird (max 3x),
  Suche von noch nicht gemähten Fläechen,
  Taster für Stop-Ausschalten/Weiterfahren,
  Taster für Heimfahrt, bzw Losfahren bei jedem Akkustand und jeder Uhrzeit. Bei dieser Heimfahrt bleibt er bis zum nächsten Tag in der "Ladestation" oder man ihn vorzeitig mit dem Taster losschickt.

Was noch kommen soll:

• Ladestation,
  Erkennung der Ladestation,
  Neuen Robi aus Alu
  Schwingend aufgehängtes Gehäuse damit es keine Lücken bei dem Bumpern mehr gibt
  Ladelektronik + Balancer in Robi einbauen,
  Die Bumper für vorne/hinten/links/rechts einzeln auswerten,

Bin mit dem Ergebnis sehr zufrieden, es gibt jede Menge Error Routinen die ihn aus fast jeder Situation befreien, das soll bei Version 2 mit dem neuen Gehäuse dann endgültig kein Problem mehr sein. Er ist sehr leise, so dass ich schon mal eine Runde ums Haus machen muss um herauszufinden wo er grade ist, und wird auch mit hohem Gras locker fertig.
Es gibt weiter Überlegungen einmal auf BL-Motoren umzusteigen, dort kommt beim Antrieb aber die große Getriebefrage. Da werde ich erst abwarten wie lange die derzeitigen Motoren halten.

Version 2 ist in Planung, bis zum Frühjahr ist noch genug Zeit, bis dahin bleibt dieser Robi im Einsatz.

LG!

Nachdem es immer wieder vorkam dass der Robi so an ein Hinderniss fuhr dass er genau zwischen 2 Bumpern anstand und daher nichts bemerkte und ewig weiter geradeaus fahren wollte, ist jetzt eine einfache Erkennung ob sich ein Vorderrad bewegt eingebaut.
Wenn es sich nicht bewegt => Annahme Hinderniss, einmal zurückfahren und drehen.
Es ist im Rad ein Magnet eingeklebt, und ober dem Rad auf der Unterseite der Bodenplatte ein Reedkontakt angeordnet. Der funktioniert auch bei 2cm Abstand zum Magnet noch zuverlässig. Die einzige Einschränkung ist dass die Erkennung nur bis zu einer Auslenkung von max +/-45° funktioniert.
Dafür braucht man sich keine Gedanken machen wie man einen Sensor + Kabel an dass sich beliebig drehbare Rad bekommt.
Für Version 2 ist eine andere Variante geplant die bei jeder Auslenkung den Magneten erkennt, aber hier wollte ich nicht mehr viel umbauen.

Vielleicht ist diese einfache Lösung für andere interessant.

LG!

Ich hatte einen Programmier Anfall, hatte mich zuerst in Scilab und dann im AVR Studio mit dem A* Algorithmus http://de.wikipedia.org/wiki/A*-Algorithmus beschäftigt.
Als Ergebnis macht mein Mäher jetzt die Routenplanung nach A* und erhält so immer die perfekte Route zwischen 2 Punkten.
Ist schon erstaunlich was man alles in einen Atmega quetschen kann!

Hier eine Auswertung vom Robi, einmal quer übers Grundstück, die einzelnen Schritte sind von 33-70 numeriert.

Bild hier  

LG!

Hallo damfino,

hatte gestern mal Zeit mir alles durchzulesen. Gefällt mir sehr gut und Du hast Dir sehr viel Mühe gegeben das Projekt auch noch begleitend zu dokumentieren. Besonders hilfreich fand ich auch das, was nicht funktioniert hat. Hoffentlich hilft mir das bei meiner Idee für einen Mäher einige Fallen gleich zu vermeiden.

Ist das Problem mit dem I²C/TWI noch offen oder schon gelöst?

Und noch eine Frage zur Schleife:
Welche Sorte Kabel hast Du auf den Rasen "getackert"? Und wie ist es um die Haltbarkeit des Kabels bestellt?

Gruß
H.A.R.R.Y.

Hallo H.A.R.R.Y.,

Ich finde dass auch Fehler ein (Um)weg zum Ziel sind. Vielleicht ist es auch gar kein Fehler, sondern man hat wieder mal nur ein Brett vorm Kopf, und wenn man es postet hat vielleicht jemand eine gute Idee dazu.

Das mit dem TWI ist gelöst, es gibt auf mikrcontroller.net eine neue Lib für das USI vom Attiny und mit der geht es.

Mittlerweile ist die Version 2 im enstehen, da sind die neuen Platinen schon zusammengebastelt, Lader und Balancer angeschlossen, und die ersten Programme laufen schon. Mit dem TWI stehe ich noch immer leicht auf Kriegsfuss, da sich die mittlerweile 3 Kontroller beim einschalten manchmal gegenseitig stören.

Im Anhang ein Bild der neuen Elektronik, von links: Lader, Balancer, vorne Hauptplatine, hinten zentrale Stromversorgung mit Anschlüssen für Akku, Lader, Ladestation und dem 5V Spannungswandler (kleine Platine) + dazugehörigen Sicherungen.


Als Kabel für die Schleife habe ich normale Einziehdrähte 2.5mm2 verwendet, die sollten schon einige Jahre halten. Wie es aussieht gräbt man die Schleife sowieso mehrmals ein bis sie einmal passt ;-)

LG!

Hi, Danke für die Antwort. Einziehdraht - das ist wahrscheinlich das Zeug, was ich als Einzelader kenne. Und ich dachte eher an das schwarze Kabel NYM-J 3x1,5².

Ja, das Einschalten und am I²C-Bus "anmelden". Die Lib vom microcontroller.net kenne ich nicht, allerdings habe ich vor langer Zeit angefangen mir selbst mal eine zusammenzustellen. Ging mir allerdings mehr um das Thema einheitliche Softwareschnittstelle auf TWI, USI oder 100%-Softwarelösung. Na jedenfalls sucht der Compiler raus, um welchen Controller es sich handelt und nimmt dann die passende Routine. Im Programm schreibe ich beispielsweise nur "setupTwiBusMaster()" und damit ist das dann unabhängig vom Controller erledigt.

Die Init-Routine für das USI aus dieser Lib würde ich gerne mal hier vorstellen, da ich glaube das ist der Knackpunkt. Der Trick ist den µC so an den Bus zu hängen, daß eventuell schon laufende Transfers nicht gestört werden - dann gibt es auch keine falschen "Start-" bzw. "Stop-"Zustände.

Zuerst ein Auszug aus dem Header (damit wird die Rotuine hoffentlich verständlicher). Sollte sich einigermaßen selbst erklären, hoffe ich:

Code:

---

#if defined (__AVR_ATtiny2313__)
        #include <avr/io.h>
        #define __TWIsupportedByUsi__
        #define TWIport                PORTB
        #define TWIread                        PINB
        #define TWIddr                        DDRB
        #define TWIsclBit                7
        #define TWIsdaBit                5
#elif defined (__AVR_ATtiny26__)
        #include <avr/io.h>
        #define __TWIsupportedByUsi__
        #define TWIport                PORTB
        #define TWIread                        PINB
        #define TWIddr                        DDRB
        #define TWIsclBit                2
        #define TWIsdaBit                0

---

Und hier die Init-Routine (nicht am Namen stören, der Init gilt definitiv für USI sowohl Master- als auch Slave-Mode!):

Code:

---

#if defined (__TWIsupportedByUsi__)
        char setupTwiBusMaster (void)
        {
                // setup does not disrupt any I²C transfer!
                USICR = (0b11<<USIWM0) | (0b10<<USICS0) | (0b0<<USICLK); // USI vorbereiten
                TWIddr &= ~(1<<TWIsdaBit); // SDA als Eingang = hochohmig
                TWIport |= (1<<TWIsdaBit) | (1<<TWIsclBit); // SDA und SCL pull-ups aktivieren
                TWIddr |= (1<<TWIsclBit); // SCL als Ausgang freigeben
                USISR = (1<<USIOIF) | (1<<USIDC) | (1<<USISIF) | (1<<USIPF); // USI starten
                return (0);
        }

---

Kernpunkt ist die Reihenfolge in der die diversen Aktionen erledigt werden; besonders die der verwendeten IO-Pins.

Ein Wort noch zur Umgebung (Compiler), der Vollständigkeit halber:
Ich benutze das WinAVR-Projekt. Der benutzte Controller wird da im Makefile definiert und die #if-Abfragen nutzen das dann aus um den richtigen Code auszuwählen (siehe Header für tiny2313 oder tiny26).

Ach ja, pro TWI-Bus je einen Pull-Up an SCL und SDA von etwa 4k7. Nicht alle µCs haben intern die Weak-Pull-Ups aktiviert, die Megas sperren das Feature im TWI-Modus sogar (schau mal ins Datenblatt).

EDIT:
Im Folgeabsatz ist mit "Controller" jeder "Teilnehmer" am Bus gemeint, also nicht nur µCs, sondern auch andere Schaltungen wie IO-Extender (z.B. PCF8574) oder EEPROMs (z.B. 2401).

Und natürlich müssen alle Controller mit Spannung versorgt sein wenn der Bus gestartet werden soll! Sonst zieht der/die unversorgte(n) Controller die Leitungen massiv gegen etwa 0,7V runter. Zuerst ist alles blockiert und dann kommt auf beiden Leitungen der Anstieg gleichzeitig - das führt dann meist zu falschen Start-Stop-Zuständen bei den bereits aktiven Controllern. Schau im Zweifel auch mal darauf.

Falls Du sie noch nicht hast, hier findest Du die Beschreibung des I²C-Bus: http://www.nxp.com/documents/user_manual/UM10204.pdf

Gruß
H.A.R.R.Y.

Hi,
Ich hab diese Lib für Slave am Attiny laufen: http://www.mikrocontroller.net/topic/38917 Die letzte Version unten auf der Seite funktioniert.
Am Atmega 32 läuft für den Slave diese Lib: http://www.jtronics.de/elektronik-av...2ctwi-avr.html

Die von jtronics für den Attiny wollte nicht funktionieren, ebenso die lib aus rn-wissen für den Atmega. Be der gab es große Verzögerungen und Daten gingen verloren.
Da der Slave das LCD verwaltet ist es schon sehr wichtig dass die Übertragung der Daten mit I2C korrekt funktioniert, sonst hat man beim debuggen gar keine Chance

Die Einschaltprobleme wurden durch den Spannungswandler verursacht. Ich hatte auf der 12V Seite eingeschaltet, das hat mit dem L7205 funktioniert, mit dem modernen Spannungswandler nicht. Da muss man auf der 5V Seite einschalten.

Also, Master+Slave+Kompass funktionieren am I2C Bus, und natürlich die Ausgabe der Daten über den Slave am LCD.
Was nicht funktioniert ist der Beschleunigungssensor, dieser weigert sich zu antworten.

LG!