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

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

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:

#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!):

#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.

[damfino]

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!

[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.