mit dem C#-Test empfange ich laufend den Telemetrie-Datenblock; die Zuordnung des Inhalts zu Parametern ist aber noch nicht klar.
Was gut funktionieren sollte:
Zusatzhardware für Robomow-Mäher (RC, RS) für Automatisierungs-Einbindung:
Die zuverlässigste RM-Schnittstelle ist die RS232, die auch für das Serviceprogramm verwendet wird. Damit ist jede Art von Steuerung machbar, es muß aber nach einem Geräte-Reset ununterbrochen mit dem Mäher kommuniziert werden.
Dafür ist eine zusätzliche CPU nötig; optional könnte diese Baugruppe - angesteckt an der RS232, und von dort versorgt - auch das Reset selbst herbeiführen (FET-Switch oder Relaiskontakt zum Drücken der Ok-Taste auf dem Bedienpanel.
Die Baugruppe sorgt für dauerndes Handshaking mit dem Mäher; nun ist noch eine Verbindung zum Haus-Automatisierungssystem nötig.
Dafür sind WLAN und Bluetooth ungeeignet, weil in der Praxis keine zuverlässige, unterbrechungsfreie Verbindung mit einem BEWEGTEN GERÄT im Bereich eines Grundstücks möglich ist: Selbst Bluetooth2/Klasse1 hat keine genügende Reichweite; auch WLAN-Repeater zur besseren Bereichsabdeckung vermeiden nicht gelegentliche Verbindungsabbrüche (Reconnect oft problematisch).
Besser geeignet sind RF-Modems, die im Bereich 434/868 MHz arbeiten. Die Übertragungsrate ist völlig egal, da ja nur gelegentliche Statusabfragen bzw. Commands übertragen werden müssen. Die Handshake-Baugruppe bildet die Verbindung.
Aus der Sicht des stationären Automatisierungssystems liegt eine einfache serielle Schnittstelle vor, die Befehle und Telemetriedaten mit dem Mäher austauscht (vorverarbeitet von der Add-On-CPU).
Der Eingriff in den Mäher beschränkt sich auf das Anstecken der Baugruppe; ein von außen zugänglicher Schalter würde die Deaktivierung des Zusatzes ermöglichen, um das Bedienpanel oder die BTLE-App nutzen zu können.
Technischer Aufwand:
Beispielsweise ein Microchip PIC (16 Bit, 24Fxxx; …C-Compiler), eine Spannungsregelung von +12 auf 3.3V, ein RS232-Treiberchip, und ein RFComm-Modul (z.B. RFSolutions ZULU-M868, Radio Modem Module DIP Package 868MHz).
Alles passt locker auf eine durchkontaktierte 2-Lagen-Platine, z.B. mit 30x50mm. Die Baugruppe wird 2x verwendet: Einmal im Mäher, und mit anderer Programmierung als Interface zwischen Automatisierung und Funkverbindung.
Insgesamt eine kleine Fingerübung für einen Entwickler…
Super zusammengefasst!
Ich würde für eine fertige Plug and Play Platine was spenden (Material + Aufwand).
Vielleicht findet sich mal wer für eine Sammelbestellung!
also bei Hardware Themen bin ich dann leider raus, das ist nicht mehr meine Welt… Wäre aber auch an einer Platine interessiert und würde auch was dafür zahlen.
Zu der Software kann ich sobald ich mal etwas Luft habe ggf. noch was beitragen, muß mich noch ein bischen mit C# beschäftigen, da bisher eher C und Perl meine Welt sind.
Kein Relais sondern einen Optokoppler bei dem zwar auf die Polung geachtet werden muss, aber nicht prellt. Auch ist er unempfindlicher gegen Vibrationen die evt. bei dem Gerät herschen.
Wenn ich richtig verstanden habe ist die RS232 am Mäher mit 3.3V. Da wäre dann der MAX3232 der Richtige.
Danke!
Die RS232 des Mähers entspricht dem Standard - verdaut also locker +/1 12V-Pegel. Mit jedem RS232-Treiber (egal ob von 3.3/5/12 versorgt) kann man da senden und empfangen, weil alle Treiberchips zur Standard-Schnittstelle kompatibel sein müssen.
Die Bauteilwahl ist für mich kein Problem; für die optionale „ok“-Tastenbetätigung hätte ich ohnehin lieber einen FET-Switch (genauer: ein Photo-MOS-Relais, z.B. AQVxxx) vorgesehen. Da aber die Mäher-Tasten sicher intern entprellt sind, hat ein Mini-Relais auch keinen Nachteil.
Dann wäre noch zu klären, wo man möglichst einfach Zugangspunkte zum dieser Taste findet. Es soll ja alles möglichst ohne Eingriffe in die Mäher-Hardware gemacht werden…
Vielleicht erübrigt sich ja die Tastenbetätigung: Falls die RS232-Verbindung - wenn einmal hergestellt - unter allen Umständen bestehen bleibt, kann man darauf verzichten. Zur Sicherheit würde ich es aber lieber vorsehen.
Ich denke, bevor man eine Hardware baut, sollte mit Testprogrammen (wie mein C#-Versuch) sichergestellt werden, daß wir über die Schnittstelle sicher die notwendige Funktion erreichen können. Bis jetzt sieht es wirklich gut aus, ich habe aber noch nicht alles abgeklopft.
Bitte um Mithilfe!
Es muß ja nicht C# sein, das war halt für mich der einfachste Weg… vorher habe ich sehr viel Zeit mit der Analyse der BTLE-Verbindung verbracht. Die Kommunikation ist grundsätzlich gleich wie auf der RS232.
ich habe mit meinem RS612 das Programm getestet.
Das Programm zeigt drei Buttons (Scan, Stop, Base)
Bei Scan fährt der Robomow los, bei Stop stoppt er auch nur bei Base macht er nichts.
Hier hat der RS andere Befehle zum RM.
Die Verbindung bleibt auch über längere Zeit aufrecht, egal ob in der Station oder unterwegs.
Beim ersten mal verbinden, muss die Reset Taste gedrückt werden.
Wenn man danach die Verbindung unterbricht, muss nur das Programm neu gestartet werden.
Es ist dann kein Reset mehr notwendig für eine Neuverbindung, was sehr gut ist!
Um die Befehle für den RS zu finden, wird jemand benötig, der die App auf einem Android hat.
Noizy kann demjenigen eine Anleitung geben, wie man damit die Befehle auslesen kann.
Persönlich habe ich nur ein Iphone zur Verfügung.
habe nachgesehen; ausgerechnet die „AutomaticOperation“-Codes dürften bei RC und RS doch gleich sein.
Die relevanten Cmds sind so aufgebaut:
0xaa (Startcode), 0x09 (Message len), 0x1f, 0x15 („AutomaticOperation“), 0x00, 0x?? (vermutlich ein Sekunden-Byte zur Unterscheidung bei aufeinanderfolgenden, gleichen Cmds), 0x0? (2=Scan, 1=Edge, 0=Stop, 3=Home, 6=EdgeTest, 7=FollowWireTest), 0xff, 0x?? (Checksum).
Die Antwort ist in allen Fällen gleich, nämlich:
0xaa (Startcode), 0x07 (Message len), 0x1e, 0x04 („Ack“), 0x00, 0x?? (gleich wie das „Sekundenbyte“), 0x?? (Checksum)
Ich werde nun ein paar Kleinigkeiten im C# ändern:
Versuchsweise das Sekundenbyte verändern (dzt. fixiert auf einen beobachteten Wert)
Das Absetzen der Cmds nicht asynchron mit dem Handshake durch den Button auslösen, sondern mit dem Handshake-Zyklus synchonisieren.
Vielleicht behebt das die Probleme…
Gut, daß auch nach Ab/Anstecken die Verbindung ohne Reset wieder da ist - das gilt aber nur für kurze Zeit, dann fehlt ihm das Handshaking.
Aber insgesamt sieht die Sache doch recht gut aus, oder?
nun ist der Aufbau der „AutomaticOperation“-Cmds (z.B. „Scan“, „Stop“,…) komplett bekannt:
Wie schon früher beschrieben, gibt es 2 variable Bytes zwischen dem Code 0x15 und dem Funktionscode (0…Stop, 1…Edge,…); die sind mit einer Art „Timestamp“ gefüllt. Das erste Byte ist das höherwertige.
Hier wird eine 16-Bit-Zahl eingesetzt, die jede Sekund um 1 hochzählt. Das dient zur Unterscheidung aufeinanderfolgender Cmds.
Dieser Code wird in der Bestätigung (0x04, Ack) zurückgesendet, um den Zusammenhang zur Anforderung herzustellen.
Bis jetzt scheinen aber wichtige Funktionen, z.B. „Scan“ (= Mähen ohne Rand) nicht ansprechbar zu sein. Falls das wirklich nicht geht, könnte es daran liegen, daß die RS232 ja nur für Testzwecke gedacht ist. Aber noch ist nichts verloren…
Dann wäre der einzige verbleibende Weg, anstelle der RS232 das BTLE-Interface zu nutzen. Die dafür nötigen Befehlssequenzen sind bekannt (gleiche Syntax wie auf der RS232).
Es müsste dann das zu schaffende Interface das nötige Handshaking und die Vermittlung mit der RFComm-Schnittstelle machen - so ähnlich wie die App, nur mit der zuverlässigen Long-Range-Verbindung zur Automatisierung.
Da kommt wieder die Frage: BTLE-Modul auf den früher skizzierten Hardwarezusatz draufsetzen (im Fall des Mähers anstelle der RS232), oder eine fertige Hardware verwursten?
Nun wäre ein Android-Phone zwar billig, und hätte BTLE usw. schon drinnen, aber die RFComm müsste dazugebaut werden; und das Android-OS dazu zu bringen, ohne Zicken Handshaking mit dem Mäher und die andere Kommunikation zu machen, ist durchaus mühsam…
Da wäre der Weg mit einer eigenen Hardware deutlich überschaubarer!
mir fällt nichts Besseres ein:
Ist es noch möglich, eine Verbindung zum Serviceprogramm herzustellen? Als Baudrate würde ich 19200 einstellen (9600 funzt nicht).
Falls das nicht geht, wird der Canossagang zur Servicestelle fällig (" ich hab’ nichts gemacht, gestern hat es noch funktioniert! Serviceprogramm? Hä? Was soll das sein?").
Der Programmiervorgang sollte ja eigentlich bombensicher sein - aber wer weiß… wenn es z.B. gelingt, eine falsche Firmware (von einem anderen Modell) reinzuladen, oder ein unerkannter Übertragungsfehler passiert, dann ist die Firmware „zerschossen“. Mit einem Programmer und den richtigen Files kann ein Techniker natürlich wieder alles richtig flashen.
Hallo, bin heute über diesen Thread gestolpert. Ist ja ein schönes Serviceprogramm für den Robomow. Betreibe einen TS1800. Die Softwareupdates kommen mit dem Programm automatisch? Oder woher bekommt man die Softwareupdates?
Schon mal Danke vorab.
LG
Update,
das Aufspielen der neuen Software, welche automatisch vom Robomow Toolkit erkannt wird hat problemlos funktioniert. Danke für die Infos hier.
Hallo,
das Serviceprogramm bekommt der Enduser normalerweise nicht, es ist für Servicefirmen gedacht.
[
Jaja, die Steuerelektronik eines Rasenmähers ist viel komplizierter als so ein primitiver PC, der Updates locker nebenbei macht? Das ist ebenso ein Mysterium wie das nutzlose GSM-Modul, das „aus Sicherheitsgründen“ keine Fernsteuerung kann.
]
Wenn das RS232-Kabel am PC steckt, auf dem das Serviceprog. läuft, macht man ein Mäher-Reset (OK lang drücken); das Programm sollte sich sofort mit dem RM verbinden (z.B. 19.200 Bd einstellen). Das richtige Modell wird automatisch erkannt, dann kann man das Update-Download starten.
Falls während des Updates was schiefgeht, könnte der RM theoretisch in einen undefinierten Zustand geraten (? Dann bleibt nur mehr der demütige Gang zur Servicestelle, um dort die Firmware mit einem Adapter am Mainboard direkt zu flashen). Also für den Download zur Sicherheit die externe Versorgung anstecken.
Hallo,
hat jemand die als Zubehör angebotenen breiten Räder für den Robomow probiert?
(Beim Geländefahren mit dem Auto sind breite Reifen nicht nützlich, höchstens im Matsch. Aber dort ist ein Mäher selten unterwegs).
Ich will versuchen, ob 3D-gedruckte Räder funktionieren. Die dem Original entsprechende Nabe habe ich schon im FreeCAD konstruiert; nach 3 Iterationen perfekt. Next: Radbreite und Profil…
Auf Gras wird der Grip ok sein, aber mangels Gummierung der Oberfläche wird’s beim Überfahren von harten Flächen rumpeln und rutschen. Vielleicht nutzen sich die gedruckten Räder schneller ab, als man sie nachdrucken kann…
hört sich gut an mit den Rädern … ich denke das bringt schon was … mit den kleinen habe ich bei mir ein bisschen Probleme. Hatte auch schon überlegt mir die großen zu holen … aber bei dem Preis :0D
habe mir am Wochenende einen Robomow RC312 bestellt, der diese Woche kommen müsste.
Beim verfolgen des Thread scheint die RS232-Schnittstelle ja am Erfolg versprechendsten für eine Implementierung zu sein.
Hat dabei schon mal jemand versucht einen RS232 zu WLAN-Konverter (siehe Titel - gesehen bei Amaz…) einzusetzen vielleicht in Verbindung mit den Tools von Robomow ?
ich kam mit der WLAN-Anbindung per Modul nicht weiter und bin jetzt auf die Methode mit dem ausgedienten Handy übergegangen. Ein eigenes Handy für den Robomow ist zwar schon dekadent, aber was soll´s.
Derzeit habe ich über VNC (VMLite VNC Server auf dem Handy und noVNC in einem iFrame in einer HTML-Box) die Robomow-App im Webfront sichtbar (Bedienung). Aufgesetzt ist noch ein kleiner HTTP-Server, sowie natürlich Tasker und AutoRemote/Eventghost. So bringt er mir auch die GPS Daten, die ich dann prima als (Goo…)Map einbauen konnte. Die GPS-Genauigkeit ist nicht der Hit - GLONASS wäre toll.
Das funktioniert unter Laborbedingungen (der Mäher steht unter meinem Fenster direkt in BT-Reichweite - also Trockenübungen) auch ganz gut…
Ich will noch von VNC wegkommen, da es doch ein wenig langsam und Stromhungrig dadurch wird.Tasker ist für einen Newbie recht tricky - es funktioniert bisher noch nicht so richtig mit der Bedienung der Robomow-App darüber (an „Input Touchscreen tap X Y“ hakt es noch).
Über meine CCU2 und einen Leistungsmesser habe ich initial die Grundanzeige (Mäht, lädt, schläft, verloren gegangen) sozusagen als Minimalvariante aufgesetzt, aber das reicht nicht. Ich will ihn eben über IPS richtig steuern können.
Jetzt will ich es in den Robomow einbauen.
Hat jemand zufällig auch einen Robomow RCXXX und ein Handy mitfahren der mir beschreiben kann, wie ich eine vernünftige Stromzufuhr herstelle ??? An der RS232 soll ja 12V anliegen, aber welche Pin´s benötige ich ? Ich habe auch einen USB-Zigarettenanzünder-Adapter und ein nicht mehr benötigtes RS232-Kabel rumliegen.
Ein paar Tipps / Gedankenaustausch zu o.g. Konfiguration wären auch nicht schlecht.
Anbei mal noch ein Screenshot, wobei ich den Lageplan jedoch herausgeschnitten habe (sonst wissen gleich alle, wo ich wohne )
der mir beschreiben kann, wie ich eine vernünftige Stromzufuhr herstelle ???