AutoMower von Elektrolux und Husqvarna

@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?

@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ß

@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ß

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

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

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

@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ß

@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

@DigitalKlaus: ja Zeitaufwand, das ist der entscheidende Punkt für mich auch.

@marvin24: was funktioniert denn heute aus dem ultra generischem Projekt? Wie sieht es aus mit der Hardware...da muss doch extra eine Platine um den AVR entwikelt werden oder gibt es das schon bei Aldi?

@all: können wir heute überhaupt alle Motoren und alle Sensoren vom AM über die RS232 vom AM steuern? Wie ich verstehe können wir den AM ab nach Hause schicken, aber Motor1 AN, Motor2 AUS, geht soetwas auch?

@DigitalKlaus
Du sprichst mir aus der Seele! Alles was du gerade schreibst, habe ich mir auch durch den Kopf gehen lassen.
Meine erste Idee war, ob ich den AM dazu bringen kann, mit meinem eigenen Programm zu reden. Das geht am besten über den RS232-Pegelwandler und Kabel direkt in den PC. Nach dem sich bei den ersten Versuch gezeigt hat, das es möglich ist, wollte ich dem AM bei den folgenden RealTimeTests nicht mit dem Laptop hinterher laufen. Einem Rasenmäher hinterher zu laufen geht ja noch - aber mit einem Laptop in der Hand? Eine RS232-Funkverbindung stand da gleich auf der Wunschliste, schon wegen den Nachbarn.

Der PocketPC habe ich genommen, weil ich dacht, damit geht das erst mal mit einem höheren WAF im Garten. So ein Teil macht sich einfach besser neben Kaffetassen und Kuchen und man kanns auch leichter mit einem Buch oder Zeitung tarnen. Die RS232 hat ja auch noch Handshake-Pins, über die ich einen Sensor abfragen und auch Relais ansteuern kann.

Mit EVB (eMbedded Visual Basic ), EVC (eMbedded Visual C++) von Microsoft habe ich mich wohl zu blöd angestellt, denn das habe ich immer noch nicht ans laufen bekommen.
Deshalb bin ich beim PocketC von www.orbworks.com gelandet. Das hat erst mal zum Programmieren und testen im Liegestuhl gereicht. Weitere Versuche mit PocketC werde ich jetzt aber lassen:

Zitat:

---

Zitat von OrbWorks Development Forum

..the WindowsCE/PocketPC version is no longer supported at all, which may influence your decision to throw money on this dead horse...

---

So bin ich auch auf das WLAN-Interface am AVR gekommen.
Wie ja @marvin42x schreibt, kann das ein Bindeglied zu einer Standardsoftware werden.

Als Einfachlösung sollte aber auch der Butterfly bzw eine eigene Schaltung ohne Funk reichen. Das geht mit den 3.3 Volt vom AM und einen Regensensor kann man auch irgendwie/irgendwo anbringen.

Ein bunter Strauß an Ausgangsbedingungen :-) .
Wenn man sich in ein bestehendes System reinhacken will ohne die Garantie zu verlieren bedarf es schon einiger Raffinesse.
@DigitalKlaus:
Danke für das Update in Sache Bluetooth.
.
@miki76:
Das Projekt von dem ich sprach hat folgende Zielsetzung:
Fertiges Betriebssystem für einen Mega32.
Hier im ersten Durchgang auf dem RNBFRA Board.
Eine Standard Konfiguration für typischen Komponenten, Motoren Sensoren usw.
Verbindung zum PC via RS232
Server auf dem PC der die RS232 Schnittstelle handhabt.
Der Server setzt die Daten in das TCP/IP-Protokoll um und stell es anderen PC-Programmen zur Verfügung.
Grafische Benutzeroberfläche die über TCP/IP von/zum Server Daten Austauscht.
Das ganze dann noch Internetfähig.
Erste Probeläufe haben gezeigt, dass das funktioniert.
Wir haben bereits ein Testprogramm für den M32 und den Co auf dem RNBFRA welches Daten liefert und auch Befehle für Servo’s entgegennimmt.
Dazu einen TCP/IP Testserver und Testclients.
Z.Z. läuft ein Sondertest weil wir Plug ans Play einführen. Also eine Selbstkonfigurierung des Netzwerkes.
Die Grafische Benutzeroberfläche hoffe ich in 2-3 Wochen als ersten Prototypen zur Verfügung zu stellen.
Die Hardware gibt es nicht bei Aldi sondern hier:
http://www.robotikhardware.de/

Netter Gruß