AutoMower von Elektrolux und Husqvarna

[Vogon]

... die 18V nehmen und mit einem LM7805 auf 5V wandeln.

Der verbratet aber das dreifache der Leistung. Da ist so ein Stepdown-Regler doch sehr viel sparsamer: http://www.pollin.de/shop/detail.php...OTk4OTY4&ts=20
Aber wie schon gesagt, dazu ist ein Eingriff in das Gerät notwendig und damit ein eventueller Garantieverlust.

Aber warum nicht gleich ein AVR mit einer WLAN-PocketPC-CF-Card:
http://www.harbaum.org/till/spi2cf/
Bild hier  

@DigitalKlaus
Ob du mit WLAN die Funklöcher los wirst sollte sich mit einem PocketPC/Laptop heraus finden lassen. Die hohe Datenrate und die gesicherte Übertragung könnte mir schon gefallen.

@marvin42x
Das Problem bei der Sache - im AM ist so etwas eigendlich nich vorgesehen. Er hat nur eine Download-Schnittstelle zum Update der Firmware. Den Softwaremachern bei Electrolux bin ich dankbar, das sie darüber auch ihre Diagnose-Software laufen lassen. Freundlicher Weise (oder aus versehen) haben sie aber auch einige Listen mit Speicheradressen in einem Ordner der Diagsoftware hinterlassen.
Wie das Diagprogramm mit dem AM redet, haben wir inzwischen herausfinden können. Eine richtige Steuerung kann man aber mit unserem mageren Wissen nicht bauen.
Vorstellbar ist ein AVR-Bord mit WLAN wie oben, das zusätzlich die Übersetzung zwischen RnCOM und der AM-Kommunikation vornimmt.

[miki76]

ja, einverstanden, Step-Down-Wandler mit Spule hat einen besseren Wirkungsgrad (80%) als LM7805 (30%). Ein AM-Akku kann man ja selbst basteln(normal Ersatz-Akku beim Händler ist ja ziemlich teuer) und da könnte man auch gleich Batterien einsetzten mit grösseren Kapazität, von daher sehe ich die Sache mit dem Stromverbrauch als nicht so kritisch.

Die Lösung mit AVR+WLAN ist sicherlich ganz interessant nur:
- es ist mehr Arbeit, weil mehr Entwicklung dahintersteckt, Hardware, Betriebsystem, Stromverbrauchkontrolle, Software zur Fernsteuerung...alles muss gemacht werden, das gibt es schon beim PocketPC.
- GPS und Kamera auf den AVR zu packen wird auch Aufwand bedeuten, beim Pocket sind das standard Komponenten mit existierender Software.
- es sind keine Standard-Komponenten und somit wird es schwierig sein, gemeinsam etwas zu entwickeln und auszutauschen. Der AM ist doch etwas ziemlich spezifisches, es wird schwierig sein, Leute zu finden die gleichzeitig einen AM haben, Hardware basteln können, Betriebsystem+Embedded Software entwickeln können.

Es gibt ja schon ein Stück Software für PocketPC um den AM zu kontrolieren, fals man noch eine standard Remote Control Software auf den PocketPC packt(gibt es bestimmt schon), dann kann man vom PC aus schon viel machen über WLAN, und das alles ohne zu viel Aufwand.
Von den Kosten her, müsste es ungefähr gleich sein. PocketPC mit WLAN findet man ab 230 euros(neu) oder vielleich sogar billiger, ich kenne mich da nicht so gut aus.

@Vogon
Mit was hast du den PocketPC programmiert? Visual Basic?
Am besten währe zuerst am PC direkt zu programmieren(AM drahtgebunden an der RS232 des PCs) und dann einfach das Programm auf dem PocketPC laufen lassen, geht das direkt mit Visual Basic?

[marvin42x]

Danke für die super Links die ihr hier habt.
Den Stepp down Regler bei Pollin und das Wireles LAN AVR -Board.
Ja, ein Kommunikator in Form eines z.B. Mega32 scheint mir Optionen bereitzustellen die Ihr, da ihr ja nur an die Diagnoseschnittstelle kommt sonst nicht habt.
Die Frage der Protokollwahl und damit verbundener Option in größere Gesamtsysteme einzubinden.
-Gut gesagt was? - Ich meine RN-Com
Aus einem New Yorker Internet-Caffee raus mal nachsehen was der AM macht

Oder Daten zwischenspeichern und zu gewollter Zeit ausgeben.
Würdet Ihr an Vitalfunktionen wie Motoren Vorwärts, Rückwärts und Bumper -Ereignis rankommen, könntet ihr die Intelligenz auf den Mega32 verlagern?
Auch die Auswertung zusätzlicher Sensoren wäre damit offen.

Habe ich den Themenkreis jetzt so richtig beschrieben?

Ich sehe gerade hat miki76 eine sehr attraktive Variante vorgeschlagen.
Da wäre ja RN-Com oder ähnliches auch denkbar.

Netter Gruß

[miki76]

@marvin42x
Wenn ich dich richtig verstehe, schlägst du vor, die Husquarna-Software wegzuwerfen und alles (Roboter-Steuerung) selbst in den AVR zu packen?
Das währe die Variante wo man alles steuert, allerdings muss man alles selbst entwickeln...lohnt es sich dann noch einen AM zu kaufen sozusagen nur für die Mechanik?

Die Lösung mit AVR würde ich erst in einem zweiten Schritt ausprobieren. Fals es mit dem PocketPC klappt, kann man vielleicht sogar den PocketPC Code im AVR wieder verwenden, da muss aber eine geschickte Programmiersprache, Entwicklungsumgebung gewählt werden die auf beide Plattformen passt. Was gibt es denn da für Möglichkeiten?

[marvin42x]

@miki76
Du überschätz meines Erachtens die Intelligenz des AM.
Und Du unterschätzt meines Erachtens die Brillanz der Hardware.

Was ich auch sehe, das der Vorschlag nach Ausbaustufe 2 riecht.
Ich habe genau wegen dieser Aufgabenstellung vor einem Jahr ein Projekt angezettelt.
Darin ist dann das Betriebssystem, die Kommunikation, und die PC -Applikation für Remote enthalten.
Alles Open Source.
Nicht für den AM aber für einen beliebigen Rasenmäher.
Das anpassen an das Individuelle ist dann Kleinkram.

Die Vogonen haben schon lange Wind davon bekommen .

Netter Gruß

[marvin42x]

@miki76
Die AVR’s werden typischerweise in C, Basic oder Assembler programmiert.
Das von mir verfolgte Projekt verwendet Bascom Basic auf dem AVR.
Die Portierung von Code AVR zu PC ist nur sehr bedingt denkbar. Von der Logik eines Programms her schon, aber im Mikro-Controller herrschen andere Notwendigkeiten. Der reine Code unterscheidet sich schon etwas.

Die Benutzeroberfläche auf dem PC wird es erstmal in Visual Basic 2005 geben.
Andere Benutzeroberflächen am Horizont sind z.B. in Visual Basic 6.
Der Server Rs232-IP ist in C

Netter Gruß

[miki76]

ok, wo ist dieses Open Source Projekt(generischer Rasenmäher) zu finden im Web?

[miki76]

ein anderer Bluetooth/RS232 Adapter, Stromversorgung 5-12V:

http://www.bressner.de/commerceporta...ProductId=4705

[marvin42x]

@miki76:

Das ist noch viel mehr Generisch als Du denkst.

Darum findest Du es auch nicht unter Rasenmäher.
https://www.roboternetz.de/phpBB2/vi...=215457#215457

Es ist ein riesiger unübersichtlicher Thread und ich würde sagen wenn Du da drin lesen willst fange von hinten an da ist das aktuellste versammelt.

@all: Meiner Erinnerung nach war Bluetooth für die Kurzstreckenkommunikation innerhalb eines Raumes konzipiert?
Noch was:
Bei Funklöchern kann man bei WLAN mit Repeatern (WDS) arbeite. Selbst meine Fritzbox bietet das an.

Netter Gruß

[DigitalKlaus]

@marvin42x

Richtig, Bluetooth war ursprünglich für Kurzstecken innerhalb eines Raumes gedacht - z.B. Laptop and Drucker, an Desktop PC, oder Verbindung von Laptopts in Konferenzen etc. Genau die Kurzstrecke hat Bluteooth dann heftige Kritik eingebracht. Dann hat man die Spezifikationen erweitert.

Repeater: Habe ich im Einsatz, im Haus, für das Zweitnetz (WLAN). Bei meiner Installation wäre da evtl. ein Repeater in der Garage die Lösung. Ob WLAN die Lösung ist bezweifle ich, zumindest für meine Anforderungen: Es soll primär eine autarke Lösung sein (d.h. ohne PC), ganz einfach den AM bei Regen in der Ladestation stehen lassen bzw. dorthin schicken ...

@all

Wie "sicher" die Übertragung sein muß kommt auf die Zielsetzung an. Wenn nur bestimmte Standardabläufe notwendig sind, die aufgrund festgelegter externer Ereignisse ablaufen sollten, dann könnte ich mir folgende Lösung vorstellen:

Ein externes Board ermittelt die Gegebenheiten (Regensensor, Zeit, etc.) und schickt per Funk eine Kommando an den AM. Dieses Kommando kann so definiert werden, dass es eindeutig verifizierbar ist.
Im AM befindet sich ein Transceiver sowie ein AVR, beispielsweise der von Vogon bereits früher erwähnte ATMEL Bufferfly (geht sicher noch einfacher, aber AVR's sind für mich noch etwas Neuland - der Butterfly hätte m.E. Vorteile, z.B. diverse Standardroutinen direkt am AM auch manuell auszulösen, hat ein LCD-Display etc.). Der AVR spielt nun seine Routine ab, die Werte vom AM abfragen kann bzw. Werte in die Datenschnittstelle schreibt, und so den AM in gewissen möglichen Grenzen steuert. Der AVR könnte dann per Transceiver eine Quittung zurücksenden, die der AVR im externen Board überprüft. Falls die Quittung nicht eintrifft, war's doch ein Funkloch und das Kommando wird wiederholt.

Die Kommandos sind - wenn ich mal von meiner Zielsetzung ausgehen darf - nur

1. Achtung: Es regnet
2. Normalbetrieb
3. STOP (um dann die LS abschalten zu können)

Der AVR im AM kann erkennen ob der AM aktuell fährt und entsprechend reagieren. Ein Software-Stop und Wechsel des aktuellen Programms genügen um ihn in die Station zu schicken. Wenn er bereits dort ist, kein Problem.

Kommando 3 löst einen Software-Stop aus. Danach kann das externe Board über ein Relais die Stromzufuhr zur Ladestation abschalten.

Der ATMEL Butterfly kann mit externer Spannung von 3.1 bis 4,5 Volt betrieben werden - ideal für den AM Diag-Port.

Soweit ein gedachtes Konzept für Basisfunktionen, die Electrolux irgendwie "vergessen" hat (Verhalten bei Regen). Wenn ich das realisieren kann bin ich schon happy. Alles andere ist eine weiter Ausbaustufe - wobei eine notwendige Spannungsversorgung höher als 3.3 Volt immer noch problematisch ist (Eingriff ins Gerät!).

In einer weiteren Ausbaustufe könnte der AM Zusatz-AVR weitere definierte "Zustände" oder "Probleme" erkennen und dem externen Board melden. Dieses wiederum kann per Funk mit einen PC oder WLAN Vebindung aufnehmen ... Ich sehe nur einen nicht unerheblichen Zeitaufwand in der Realisierung. Würde mich nicht wundern, wenn wir länger daran bauen als Electrolux für eine neue AM-Version braucht, in der eine Fernsteuerung (Bluetooth, WLAN oder sonstwie) bereits enthalten ist. (Keine Ahnung ob die an so etwas arbeiten.)

Gruß

Klaus