AutoMower von Elektrolux und Husqvarna

[harald_nds]

Hallo Klaus,

das mit der Datensicherung im Point-to-Multipoint kann das Device auch ja nicht mehr so einfach regeln - das muss ja schon detailliert aus der Anwendung hervorgehen wie das laufen soll.
Auf jeden Fall solltest Du mal unter dem Kapitel "API" (Stichwort Framing) nachsehen. Jedes Package, das man in diesem Modus versendet, kann verfolgt werden ob es denn tatsächlich angekommen ist. Nur nicht bei Broadcast-Nachrichten, das funktioniert naturgemäß natürlich nicht. Die Nachrichten bekommen eine Frame-ID, damit man nachher die Zuordnung noch hat. Das Modul antwortet nach erfolgreicher/-loser Zustellung mit dieser Frame-ID. Das Modul macht dabei selbständig Retries anhand der im Parameterspeicher hinterlegten Anzahl.
Eigentlich bietet der API-Modus wirklich alle Eigenschaften, die man für ein Netzwerk braucht. Die Sache mit dem ZigBee-Koordinator würde ich nicht machen, das ist dann schon sehr in Richtung voller ZigBee Norm und somit arg kompliziert. Oder meinst Du "Koordinator" nur im allgemeinen Sinne?


Kapitel 4.3 API
==========
ZigBee Transmit Request : API Identifier Value: 0x10
A TX Request message will cause the module to send RF Data as an RF Packet.

und

ZigBee Transmit Status : API Identifier Value: 0x8B
When a TX Request is completed, the module sends a TX Status message. This message will indicate if the packet was transmitted successfully or if there was a failure.

[harald_nds]

Hallo Leute,

ab heute ist unser Wohngebiet mit Automower-Daten versorgt, ich habe gerade mal einen Reichweitentest mit dem Auto durchgeführt  
Das XBee-Pro Modul habe ich in eine Tic-Tac-Dose verbaut. Zunächst einmal provisorisch - versteht sich. Auf Dauer möchte ich den Stecker unten aus der Diagnosedose herausholen und unter das Display führen. Da kommt man durch die extra Verschraubung des Displays schnell heran.....
Zum Test habe ich das Programm von Vogon genommen, das ist ja wirklich genial!!! (@Vogon: könntest Du auf Dauer verschiedene COM-Ports unterstützen, mein XBee-USB Interface kann ich nicht auf COM1 verschieben?)

Externes Bild anzeigen   

[marvin42x]

Ich streue hier nur mal ein "ist ja toll was iher hier auf die Beine stellt" rein.
Da euer Vorhaben Kommunikationsfragen aufwirft und löst finde ich das für mich natürlich besonders spannend.


Netter Gruß
http://www.marvins-lab.roboterbastler.de/

Ps. Und nicht nachlassen  

[seibot]

(@Vogon: könntest Du auf Dauer verschiedene COM-Ports unterstützen, mein XBee-USB Interface kann ich nicht auf COM1 verschieben?)

Das Programm von Vogon besitzt eine Setup-Funktion. Vor dem Start des Programmes können die COM-Einstellungen gewechselt werden. Diese sind dann in einer optionen.ini gespeichert.

[DigitalKlaus]

Upate und Erfolgsmeldungen:

XBeePro

Die Funkverbindung ist von den bisherigen 868 MHz-Modulen auf die XBeePro Module umgestellt. Im AM sitzt ein XBee Pro vorne unter der Haube in einer kleinen Kunststoff-Box. Die Antenne ist oben auf der Haube montiert (und kann wegklappen, sollte es ein Hindernis geben).

An dieser Stelle Danke an alle Entwickler im Roboternetz-Forum, die mir bei grundlegenden Verständnisfragen zum AVR geholfen haben, und die mit dem Einbringen eigener Forschungsergebnisse den aktuellen Stand überhaupt möglich gemacht haben. =D>

Die Verbindung zum AM regelt im Moment eine Station am PC. Diese Station ist ein MaxStream XBee Development Board mit USB-Anschluß. Ich habe das Board in ein Gehäuse eingebaut (da mußte allerdings kräftig "nachgearbeitet" werden   ):

Externes Bild anzeigen   

Vorne rechts ist der USB-Anschluß, links LEDs für Betriebsbereitschaft, zur Rückmeldung der Funksignal-Qualität (1-3 LEDs), und optische Meldung der Sende/Empfangsvorgänge. An der Rückwand ist die Antenne für das 2.4 GHz Band angebracht.

Die PC-seitige Station dient mir als Konfigurationsmöglichkeit für die XBee Module sowie für erste Tests mit vorhandenen AM Diagnose- und Steuerprogrammen. Wichtig ist eine XBee Erstkonfiguration um die Sendeleistung auf das in Europe zugelassene Maximum zu begrenzen. Gleichzeitig hatte ich etwas zu optimistisch die Baudrate auf 38.400 eingestellt - was sich als nicht machbar erwiesen hat: Bereits bei der Konfigurationseinstellung gab es mehrmals Übertragungsprobleme. Eine Kommunikation mit dem AM war überhaupt nicht machbar.  

Zurück zu 9.600 Baud war erfolgreich. Der Grund für die Limitierung dürften die (alten) PC Device Driver für den virtuellen COM Port sein - diese sind in der Software für die XBee's enthalten, es gibt aber vom eigentlichen Treiberhersteller inzwischen Updates.

Die Ergebnisse sind für mich durchaus beeindruckend: Mit 9.600 Baud ist der Datendurchsatz erheblich (!) besser als mit den 868-MHz-Funkmodulen - und das bei gesicherter Übertragung! Zu einem späteren Zeitpunkt werde ich noch weiter testen, wo die maximale Datenrate liegt (was aber aufwendig ist, das beide XBee-Pro Module dann umkonfiguriert werden müssen - d.h. auch Ausbau aus dem AM -- daher die Befestigung unter der Haube, leicht errecihbar.)

Die Funklöcher sind weg, die vorherigen Datenfehler sind weg - letzteres aufgrund der gesicherten Übertragung. \  /

Jetzt habe ich weniger Bedenken, auch Daten im AM zu verändern (was bei ungesicherter Übertragung ein Abenteuer ist.)

Basis-Station (AVR)

Zur autarken Station auf AVR-Basis bin ich auch ein Stück weiter. Hier der Hardware-Testaufbau:

Externes Bild anzeigen   

Links im Bild der Regensensor, hier mit etwas Wasser "Regen" simuliert (grüne LED meldet "Feuchtigkeit"). Rechts das RN-Control mit ATmega32. oben das LCD (RS232 wird für die XBee Steuerung benötigt, also mußte eine Alternative zur Infoanzeige her), unten ein Verteilerboard (Wannenstecker auf Klemmleiste für einen Port) mit LED-Portstatuskontrolle. Das XBee und die RTC fehlen im Aufbau noch - ich überlege wie ich das auf Platinen aufbaue oder per Stecker zusammenhänge ... zu viele Einzelplatinen sind nicht gut (wie befestigen!?), evtl. wird's eine Huckpack-Konstruktion.

Ein erstes Programm (BASCOM) erkennt "Regen" oder "kein-Regen": Wenn der Sensor Regen erkennt, schließt ein eingebautes Relais einen Stromkreislauf. Die Spannungsänderung an einem AVR-Port löst den Interrupt 0 aus, worauf im Programm ein Flag für die "Wetterlage" gesetzt wird. Es werden beide Zustände gemeldet und gespeichert (Regen / kein Regen). Man müßte das nicht per Interrupt machen, hier könnte auch ein Polling erfolgen - die Int0 Implementierung hilft mir als AVR-Einsteiger die Zusammenhänge besser zu verstehen, außerdem ist es m.E. logischer wenn ein "Ereignis" einen Interrupt auslöst und dieser im Programm einen Status setzt.

Die autarke Station weiß also jetzt zu jeder Zeit ob es momentan regnet oder nicht. Zur Kontrolle werden diese Zustände am LCD angezeigt. In einer späteren Programmlogik wird hier eine Latenzzeit für die AM-Steuerung einzuplanen sein - der AM soll ja nicht ständig rein und rausfahren wenn ein paar Regentropfen fallen. Das fällt aber schon in den Bereich "Optimierung".

Das Board hat fünf Taster, mit denen momentan Port-Zustände am LCD angezeigt werden, die LCD-Beleuchtung an/aus zu schalten ist (das Teil zieht mächtig Strom, da kommt der Spannungsregler am RN-Control ins Schwitzen ...).

Der nächste Schritt wird die Kommuniklation mit dem AM, und danach folgt die Timer-Programmierung. Das muß dann auch irgendwie einstellbar sein - mit einem 4-zeiligen LCD und ein paar Tastern (oder eine kleine Tastatur?).

Wie dann alle 3 Systeme (PC, Basisstation, AM) miteinander reden weiß ich noch nicht. "Framing" erfordert mehr Einarbeitung in das XBee API und einen AVR im AM. Eine Alternative wären 2 Funkstrecken: AM - Basis und Basis - PC. Das setzt 2 serielle Schnittstellen am RN-Control voraus und die Basisstation müßte eine Art Vermittler spielen. Die beiden seriellen Schnittstellen könnte man mit 1 x HW und 1 x SW realisieren. Wie weit das mit 32 KB Programmspeicher überhaupt zu realisieren wäre ist fraglich.

Nächster Schritt: Die Basisstation (AVR) soll mit dem AM reden.

Kommentar, Anregungen, Fragen sind willkommen. Und wenn ich zu lange Beiträge schreibe, dann sagt es mir bitte  

Gruß, Klaus

[harald_nds]

Hallo Klaus,

klasse, das schaut ja schon richtig gut aus! Freut mich, das XBee nun doch das richtige zu sein scheint! Ein paar Fragen/Bemerkungen habe ich:

* Du sagst 38400 Baud haben nicht funktioniert. Hast Du die denn auf beiden Seiten eingestellt, ich meine der AM kann mit 38400 doch eh nichts anfangen, oder?
* Verwendest Du für die Konfiguration das Program X-CTU von Maxstream? Bei mir war bei den XBee Pro erst mal ein Firmware-Upgrade erforderlich, damit X-CTU die ansprechen konnte.
* Das Diagnoseprogramm kann ja 9600 und 115200 Baud. Wie stellt der AM diese Baudrate um, oder kann er anhand des ersten 0x0F Byte das automatisch erkennen? Mein Experimentiertrieb war in diesem Punkt noch etwas zurückhaltend. Das Problem ist nämlich das ich ein FW-Upgrade des AM nicht über USB-Seriell-Adapter am Notebook hinbekomme. Also schleppe ich bei Absturz den AM ins Büro auf den Schreibtisch und nutze den Legacy-COM Port des PCs. Da liegt der WAF natürlich nicht sehr hoch...
* Die Begrenzung auf Europa-taugliche 10mW gilt sicherlich für Serienprodukte - klar. Aber für experimentelle Zwecke hätte ich da keine Skrupel. Aber wenn es bereits mit 10mW auch schon perfekt geht - warum mehr? Als ich mir die Motorströme so angeschaut habe kam mir die Stromaufnahme des XBee in den Sinn. Mit ca. 200mA beim Senden liegt die Aufnahme in der Größenordnung des Hauptmotors wenn dieser nicht viel zu tun hat. Aber großartige negative Einflüsse auf die Mähzeit habe ich selbst bei dauernder Übertragung nicht feststellen können. Wahrscheinlich sind die 200mA nur Peaks und fallen deshalb nicht ins Gewicht.
* Hat jemand schon Erfahrung (vielleicht auch ungeplante) mit der Strombelastbarkeit der AM-Debug-Schnittstelle? Ich meine, ist das intern abgesichert oder schmort da mal gleich eine Leiterbahn durch? Bei 200mA kommt man ja schon in's Grübeln.
* Nach Benutzung der Vogon-SW haben sich bei mir Datum und Uhrzeit komplett auf Null gesetzt. Hat das jemand schon mal gehabt? Vielleicht sind noch weitere Parameter betroffen, muss ich noch prüfen. Was könnte da passiert sein? Ich habe jedenfalls nichts geschrieben, nur das Variablenfenster nur einmal geöffnet und gleich wieder geschlossen.
* Sind die Speicherzellen der neuen Generation noch identisch mit denen der 2006 AM's.
* 32kB Hauptspeicer sollten doch allemal reichen. Ich meine, ich kenne Bascom nicht, aber in C kann man da schon so einiges regieren.
* Ich könnte mir vorstellen nachher alles schön auf eine Platine zu bringen. Da würde ich mich anbieten. Wenn es kein Großserien-Produkt werden muß ist das kein großes Problem. Evt auch gleich die Regensensor-Elektronik.
* Spannungsregler zu warm: Handelt es sich auf dem Board um einen normalen 7805? Falls ja, könnte das hier eine Alternative sein, die du direkt umlöten kannst: Conrad Best.Nr. 154496 Die habe ich mal getestet, funktionieren ganz gut und werden bei >90% Wirkungsgrad auch kaum warm.

@seibot: Vielen Dank für den Tip mit der INI-Datei!
@Vogon: Könnte man vielleicht die Update-Rate einstellbar machen? Momentan funkt das Modul bei Kontakt ja unentwegt und zieht dadurch zusätzlichen Strom. Vielleicht müsste man wirklich einen kleinen Microcontroller dazwischenschalten, der lokal auf dem AM Daten anfragt und die dann erst bei "Notwendigkeit" aktiv über Funk weitergibt. Müssen wir noch einen µC mit zwei richtigen UARTs finden.
Gruß, Harald

[DigitalKlaus]

@Harald

- 38400 waren auf beiden Seiten eingestellt, ebenso für den COM-Port am PC. ABER, es ist richtig, der AM kann damit nichts anfangen - das hatte ich in der Eurphorie völlig übersehen!
- Ja, ich verwendet X-CTU. Läuft problemlos, nur die Umstellung der Baud-Rate hat nicht immer so funktioniert. Jetzt bin ich wieder auf 9600, da macht X-CTU alles problemlos. Meine XBee Pro melden sich mit XPB24, XBEE PRO 802.15.4, Version 1083, Hardware-Version 1808. Es sind neuere Versionen verfügbar ... aber "never change a running system"!
- Wie der AM die Baudrate umstellt weiß ich (noch) nicht. 115200 gehen sicher rein seriell, aber mit einem virtuellen COM-Port habe ich da Bedenken: Da ist "zuviel Software" dazwischen. Eine direkte Kabelverbindung mit USB-nach-Seriell Adapterkabel funktioniert bei mir. Das ist dann allerdings wieder ein virtueller COM-Port und wird mit 9600 Baud betrieben (auch bei mir am Notebook).

- XBee Stromaufnahme: Bei 10 dBm sollen es "nur" 137 mA sein, bei maximaler Sendeleistung (18 dBm) gibt das Handbuch 215 mA an. Idle sind es 55 mA. Das ist immer noch mehr als die 868 MHz Module, scheint aber keine Probleme zu verursachen.
In ein paar Tagen, wenn das XBee Pro an meinem AVR-Testaufbau hängt, wird's interessant: Das LCD am RN-Control zieht bei eingeschalteter Beleuchtung 200 mA - dann kommt der Spannungsregler (ein 7905) ins Schwitzen. Wenn jetzt nochmal 137 mA für das XBee Pro dazukommen ... Als Netzteil für RN-Control habe ich 12 V/2A stabilisierte Ausgangsspannung. Das Board selbst braucht 60 - 100 mA. Macht zusammen ca. 500 mA. (Einen Kühlkörper für den 7805 habe ich jetzt angebaut.)
Dazu noch folgende Überlegungen:
* Mein Ziel ist eine Reduzierung der Datenübertragung. Die Zeitsteuerung, Regensensor-Überwachung etc. läuft in der Basisstation. Diese muß jetzt nuir noch das Timer-Flag im AM auf On oder Off setzen. Alles Weitere ist nice-to-have und sicher wünschenswert, aber selbst dann könnte man Statistikdaten (die der AM sowieso sammelt) in der Nacht bzw. in Pausen abrufen.
* XBee Pro hatt einen Sleep-Modus und einen zyklischen Datencheck zum "Aufwachen". Vielleicht ist das eine weitere Möglichkeit, die Stromaufnahme zumindest auf der AM-Seite zu reduzieren. Dazu wäre mehr Doku zu lesen - soweit es die Zeit erlaubt.
* Strombelastbarkeit der Diag-Schnittstelle: Könnte ggf. jemand beantworten, der den AM schon einmal geöffnet hat.

- Die Vogon-SW hat bei mir funktioniert. Über Speicherzellen 2006 und 2007 ist mir nichts bekantnt, nur beim 220AC hat sich genau genommen nichts geändert. Der 230 dürfte zusätzliche Daten und Logik haben, weil er intern zwischen 2 Akkus umschaltet.
- Hauptspeicher: Bascom macht das schon recht ordentlich, und ist für Prototyping gut geeignet, da sprachlich höher angesiedelt als C. Vielleicht schreibe ich das dann irgendwann auf C um. Das Problem ist ja nicht nur der Programmspeicher, sondern die 2 K RAM und etwas EEPROM (weniger kritisch). In 2 K RAM müssen die Stacks rein, alle Variablen ... das wird eng wenn wir einigen Komfort wollen. Warten wir ab was passiert.

So, jetzt hänge ich das XBee Pro an den Testaufbau und fange diese Woche mit der Kommunikationslogik an.

Grüße aus München, Klaus

[seibot]

Hallo Klaus und Harald,
Glückwunsch zu diesen Ergebnissen. Ich muss noch auf Bestellungen warten.
Die XBee-Module wurden leider mit 43€ Zoll belegt - ist das üblich?

Noch ein Tipp zum Regensensor.
Wenn die Sensoroberfläche waagerecht oder nur leicht geneigt liegt, ist die Latenzzeit bei Regen ausreichend, damit der AM nicht ständig ein- und ausfährt.

[DigitalKlaus]

@Jürgen

Zoll oder Einfuhrumsatzsteuer oder beides? 19% EUSt sind normal, Zoll weiß ich noch nicht - die Abrechnung habe ich noch nicht.

Regensensor: Der sollte eine "Heizung" eingebaut haben, damit nicht jede Feuchtigkeit gleich als Regen erkannt wird. Ich habe den Eindruck, mein Sensor "heizt" nicht. Mir ist schon klar, dass man da keine Spiegeleier braten kann ...

Gruß, Klaus

[seibot]

@DigitalKlaus,
auf den Nettobetrag von 179,23 € von Digi-Key wurden 43,82 € Einfuhrumsatzsteuer berechnet. Das sind 24,4 %.


Regensensor (CONRAD)
Ich habe die Heizung abgeschaltet, da diese zu einem sehr zeitigen Abtrocknen führt. Die Ansprechschwelle des Sensors lässt sich ja einstellen, so dass das Relais erst bei Regen schaltet.