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

[H.A.R.R.Y.]

Mit dem TWI stehe ich noch immer leicht auf Kriegsfuss, da sich die mittlerweile 3 Kontroller beim einschalten manchmal gegenseitig stören.

Ist dieses Problem mit der neuen Lib auch schon gelöst?
Wie äußert sich der Fehler, wenn er auftritt?

Hab gerade mal den Code der Init-Routine aus der von Dir benutzten Lib (http://www.mikrocontroller.net/topic/38917) gegen meine Variante verglichen. Ergebnis:
Bei mikrocontroller.net werden zuallererst SCL und SDA gleichzeitig als Ausgänge deklariert:

  DDR_USI |= ( 1 << PORT_USI_SCL ) | ( 1 << PORT_USI_SDA );	  // Set SCL and SDA as output

Typischerweise sind die Portbits im Ausgaberegister (PORTx) insbesondere nach einem RESET aber auf '0' => Beide Bus-Leitungen werden niederohmig und fast gleichzeitig (das liegt im Bereich weniger ns oder noch kürzer!) auf '0' gelegt und stören damit was auch immer gerade auf dem Bus stattfindet.

Jetzt wird es noch schlimmer; nun werden die Leitungen (SCL zuerst) nacheinander niederohmig nach '1' geschaltet. Am I²C-Bus ist aber niederohmig '1' verboten, weil ein anderer Treiber ja gerade '0' senden könnte. Das gibt in so einem Fall einen Kurzschluß. Der Signalablauf sollte zwar eine Stop-Bedingung darstellen, aber der restliche Bus wird durch diesen Init massiv gestört:

  PORT_USI |= ( 1 << PORT_USI_SCL );  // set SCL high
  PORT_USI |= ( 1 << PORT_USI_SDA );  // set SDA high

SDA wird jetzt endlich hochohmig geschaltet:

  DDR_USI &= ~( 1 << PORT_USI_SDA );  // Set SDA as input

Das SCL wird dann durch den USI-Init auf den richtigen Stand gebracht

  USICR = ...

Fazit: diese lib vom mikrocontroller.net ist definitiv nicht für Multimaster ausgelegt. Eventuell stören sich aber auch im Single-Master-Betrieb einzelne Slaves an den unerwünschten Pulsen auf SCL und SDA, die durch diesen Init eines Slaves entstehen. Das kann bis zur totalen Busblockade führen - zumindest aber zu massivem Datensalat.

Versuch mal die von mir vorgestellte Init-Reihenfolge. Sie ist getestet und erzeugt keinerlei Störungen auf dem I²C-Bus wenn das USI "angekoppelt" wird. Das ist insbesondere bei Multimaster-Betrieb sehr wichtig. Immerhin kann es sein, daß auf dem Bus schon erste Aktivität läuft, während irgendein Controller erst seine Init-Routine startet. Dann ist Chaos vorporgrammiert. Deine Beschreibung, daß das nur "manchmal" passiert, stützt derzeit meinen Verdacht, daß so ein Effekt bei Dir auftritt.

Welche Controller hast Du im Einsatz und in welchem Modus arbeiten sie am I²C?

Eine andere Baustelle ist dann wohl noch:
Welchen Beschleunigungssensor verwendest Du? Und wie ist der an den I²C angebunden?

H.A.R.R.Y.

[damfino]

Hi, ja ich werde mal deine Init testen, Verbesserungen schaden nie. Man findet eben immer wieder Libs im Internet die bei manchen problemlos funktionieren, aber bei anderen nicht.

Die Einschaltprobleme kamen vom 5V Spannungswandler, damit kam vor allem der Master nicht zurecht. Seitdem gab es keine Probleme beim einschalten mehr.

Am I2C sind:
Atmega644 Master
Atmega32 Slave
Attiny26 Slave
BMA020 Beschleunigungssensor, Probleme dazu hier:https://www.roboternetz.de/phpBB2/vi...=531507#531507
CPMS03 Kompass

Den Atmega644 werde ich vielleicht gegen einen 1284p austauschen, denn wegen der A* Wegfindung ist der Ram jetzt ziemlich am Limit, etwas Reserve schadet bei meinem Programmierstil nicht

LG!

[H.A.R.R.Y.]

Könntest auch einen mega mit externem RAM verwenden (z.B. mega162).

Was hältst Du von einem Test in folgendem Aufbau:
ATmega (mit UART) per RS232 an ein Terminal (PC mit Hyperterminal) ankoppeln. Per Schleife einfach mal einen Teststring senden. Hast Du so etwas schon mal gemacht?

Wenn das sauber funktioniert, nur den Beschleunigungssensor an den TWI anschließen (die beiden Pull-Ups nicht vergessen). Der mega könnte dann per Schleife den Sensor auslesen und die Daten ans Terminal senden. So kannst Du prüfen, ohne das andere Komponenten den Bus stören. Wer weiß, ob nicht doch noch ein Bug in einer der Libs ist.

Wenn das funktioniert, die Zahl der Teilnehmer erweitern und notfalls das Tempo auf dem I²C drosseln.

Alternativ solltest Du Dir die Signale auf dem Bus mit einem Oszilloskop ansehen - geht natürlich nur, wenn Du eines hast.

H.A.R.R.Y.

[damfino]

Für so einen Testaufbau fehlt so ziemlich alles Kein RS232 am PC mehr, kein Pegelwandler am Atmega, wenigstens ein brauchbares Multimeter ist vorhanden
Die Kommunikation zwischen Master und Slave mit LCD läuft jetzt zuverlässig, ich kann alles nötige am LCD darstellen. Es gibt auch noch 2 LEDs am Master die ich jetzt dazu verwende sie vor und nach vermuteten problematischen Code ein- und ausschalte um den Ablauf zu überprüfen.

Erfolg der letzten Tage:
Kommunikation Master-Slave LCD funktioniert,
GPS am Slave funktioniert
Kompass funktioniert
Kommunikation Master - Balancer funktioniert
Automatischer Ladevorgang funktioniert

zB der Slave kümmert sich ums GPS und bereitet diese Daten auf, der Master holt diese und verarbeitet sie (zB für Betriebszeiten) und schickt die Ergebnisse an den Slave zurück um sie am LCD darzustellen.

Der automatische Ladevorgang hat gestern das erste Mal funktioniert:
Wenn der Master erkennt das eine (korrekte) Ladespannung anliegt und der Akku leer ist, wird das Laderelais aktiviert. Dieses schaltet den Lader ein und aktiviert auch hardwaremäßig die Ansteuerung der Lastwiderstände im Balancer. Das Relais kann hardwaremäßig nur angesteuert werden wenn eine Ladespannung anliegt.
Der Balancer ist andauernd am messen der Zellenspannungen, und gibt diese und den aktuellen Status (ok, Fertig geladen, Fehler) an den Master zurück.
Bei Fehler (Unter oder Überspannung) bzw Fertig geladen schaltet der Balancer das Relais ab.
Der Master schaltet bei Fertigmeldung auch das Relais ab, und setzt den Status im Balancer zurück sodass dieser für den nächsten Ladevorgang bereit ist. Bei Fehler schaltet auch der Master ab, es sind später noch weitere Optionen geplant.
Der Master überprüft auch laufend die übermittelte Gesamtspannung des Akkus vom Balancer mit einer eigenen Messung, bei Abweichungen wird ebenfalls abgeschalten. Kann etwa bei einem schlechten Steckkontakt vorkommen.
Die einzelnen Zellen und Gesamtspannungen werden laufend am LCD dargestellt.

Jetzt fehlt noch der Anschluss der Motortreiber, Hallsensoren, Bumper, Bedientaster, und der neue Robi + Ladestation, also fast nichts

LG!

[H.A.R.R.Y.]

ja ja, die neuen PCs und altgediente einfache Schnittstellen. Sch... USB!

Aber da ja sonst schon recht viel funktioniert, sollte das mit dem Beschleunigungssensor auch hinzukriegen sein. Ich poste jetzt zu diesem Thema dort weiter. Paßt besser als hier.

H.A.R.R.Y.

[wuwei]

Zur Positionsbestimmung häb ich eine Idee. Könnte man nicht so eine Art Mini-GPS nachbilden und zwar mit Ultraschall, weil Schall eine wesentlich niedrigere Geschwindigkeit hat als Funkwellen. So müssten auch schon im Zentimeterbereich deutliche Laufzeitunterschiede festzustellen sein.

Also mindestens 3 Ultraschall-Relaisstationen ("Satelliten") in den Ecken des Gartens aufstellen. Diese sollten schnellstmöglich auf Anfrageimpulse des Robos antworten, und zwar jeweil mit einer anderen Frequenz. Damit müsste die Position aus den unterschiedlichen Laufzeiten recht schnell und zentimetergenau festgestellt werden können.

[Richard]

Es wird zu viele Stör Geräusche geben und Luftströmungen könnten auch verfälschen.
Das macht man besser mittels Baken wie IR Sender mit mindestens 3 auf dem Gelände Vereitelte kann der Bot mittels Trigonometrie
seine Position ermitteln. Dabei entstehen aber auch immer "Rundgnus Fehler" und diese summieren sich auf.

Wenn ich mir überlege das (ICH) auch nie weiß wo ich mich X/Y genau befinde, aber trotzdem den Rasen mähen kann ohne die Blumen "umzunieten"...... Warum ist das so, weil ich sehen kann! Mit verbundenen Augen würde das nicht klappen. Also bleibt eine Bild / Videoauswertung von markanten Punkten übrig.

Wenn eine Überwachungs- Kamera einem Markierten Objekt folgen kann, kann ein Bot mit Kamera auch auf das Objekt zu fahren b.z.w. aus mehreren Objekten seine Position zu diesen ermitteln.

Es gibt ja auch schon solche Kameras mit denen ein Bot z.B. bestimmte Spielkarten folgt.
Das Problem dabei liegt eher vor der Tastatur, das (bei mir fehlende) KnoffHoff dazu......

Gruß Richard

[wuwei]

Störsignale und Störgrößen gibt es überall, für solche einfache Aufgaben lassen sie sich aber leicht rausfiltern. Dass Ultraschall prinzipiell gut zur Nahnavigation geeignet ist, zeigen uns die Fledermäuse, die keine Probleme haben, damit sowohl ihre Wege als auch ihre winzige Beute zu finden. Was soll an Infrarot besser sein? IR hat Lichtgeschwindigkeit und ist deshalb für Entfernungsmessung im Nahbereich ebenso ungeeignet wie GPS. Und Positionsbestimmung über Winkel ist bedeutend aufwendiger.

Einen Rasenmäher mit Kamera und Bilderkennung auszurüsten, ist mit Kanonen auf Spatzen geschossen. Die Unterscheidung per Kamera, wo der Rasen schon gemäht ist und wo nicht, ist alles andere als trivial. Da scheint mir das Kartenkonzept mit Positionsbestimmung und abhaken der gemähten Stellen wesentlich einfacher und sinnvoller.

[oberallgeier]

... IR hat Lichtgeschwindigkeit ... für Entfernungsmessung im Nahbereich ... ungeeignet ...

Ich habe seit vielen Jahren zwei optische Sensoren in Benutzung, die ganz hervorragend für Navigation im Nah- und im Fernbereich geeignet sind, AGC, Farbsensorik und sonstige Features. Vom energetischen Minimalaufwand will ich jetzt garnicht schwärmen. Basis ist Bilderkennung, Stereometrie, eine Menge komplexe Datenverarbeitung - und natürlich mein neuronales Netzwerk im Kopf.

... müssten auch schon im Zentimeterbereich deutliche Laufzeitunterschiede festzustellen sein ...

Stimmt. Vor allem, wenn eine Sensor-Peillinie durch eine thermisch andere Luftblase läuft als die andere. Genaue Entfernungsmessung in der üblichen Umgebung, sprich im thermischen Chaos der Atmosphäre ist eine neckische Theorie.

[Richard]

Störsignale und Störgrößen gibt es überall, für solche einfache Aufgaben lassen sie sich aber leicht rausfiltern. Dass Ultraschall prinzipiell gut zur Nahnavigation geeignet ist, zeigen uns die Fledermäuse, die keine Probleme haben, damit sowohl ihre Wege als auch ihre winzige Beute zu finden. Was soll an Infrarot besser sein? IR hat Lichtgeschwindigkeit und ist deshalb für Entfernungsmessung im Nahbereich ebenso ungeeignet wie GPS. Und Positionsbestimmung über Winkel ist bedeutend aufwendiger.

Einen Rasenmäher mit Kamera und Bilderkennung auszurüsten, ist mit Kanonen auf Spatzen geschossen. Die Unterscheidung per Kamera, wo der Rasen schon gemäht ist und wo nicht, ist alles andere als trivial. Da scheint mir das Kartenkonzept mit Positionsbestimmung und abhaken der gemähten Stellen wesentlich einfacher und sinnvoller.

Mit Störsignale waren (auch) Autos, Motorsägen u.s.w. gemeint. Mit IR waren eher Baken zur Positions erkennung / berechnung NICHT Abstandsmessung gemeint. Wie weit der Rasen entfernt ist weiß man gewöhnlich.

Ob man mittels Kamera erkennen kann wo schon gemäht ist? Auf alle Fälle schwierig, ich dachte da eher an bestimmte Bild-Baken wie Bäume, Hausecken, Gartenbank oder ähnliches. Also vom Prinzip sehen wo hin gefahren wird inklusive Hindernis Erkennung.

Bei US bleibt auch noch der Schall Kegel, bei
20 x 30 m Rasenfläche sicher nicht zu vernachlässigen. Dazu noch mögliche Ruflektionen.....das wird auch nicht wirklich einfach beim Auswerten....

Gruß Richard