EinEinfach
Well-known member
Richtig ist das nicht, jemand oder etwas sendet auch noch was auf dem Port. In der Sunray Readme gibt es eine Anleitung, wie man das überprüfen kann
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Umbau Worx Landroid WG795e Type 1
- Thread starter EinEinfach
- Start date
Hallo in die Runde,
ich bin neu hier und lese seit ein paar Tagen in diesem Thread mit.
Hintergrund ist mein Wunsch einen Husqvarna Automower 220 auf GPS-RTK etc. umzubauen.
Heute habe ich dann mal das Repo von @EinEinfach geklont und etwas tiefer in den Code und die Schematics geschaut.
Danach glaube ich, dass man die Umsetzung der RaspberryPi Variante ohne RP-Pico vermutlich "relativ einfach" ausprobieren könnte.
Nach meinem bisherigen Verständnis hängen
- alle Motortreiber (inkl.Odometrie)
- die Bumper-, Notaus-, Charge/Battery-Schalter,
- die Strommessung (INA266 über I2C)
am RP-Pico und werden vom RaspberryPi über /dev/ttyUSB0 angesteuert oder abgefragt.
Das GPS hängt über USB-Seriell-Adapter am RaspberryPi.
Wifi hängt über USB am RaspberryPi (oder ist es integriert?).
In der config.h findet sich noch eine MPU6050, aber mir ist nicht klar geworden über welchen I2C-Bus die interagiert?
Meine Idee:
Unter Linux kann man ja nicht nur lokale IP-Verbindungen (127.0.0.1) zwischen Prozesse auf dem gleiche Rechner nutzen, wie zwischen Cassandra und Sunray, sondern in ähnlicher Weise auch Pseudoterminals (pty) für serielle Verbindungen.
Wenn man nun die Aufgaben des RP-Pico (in Sunray/alfred/firmware/rpi_pico/main.py) in einen eigenen Prozess auf dem RaspberryPi laufen ließe, müsste dieser Prozess mit Sunray über ein pty kommunizieren können, ohne, dass irgendeine sonstige Änderung an Sunray notwendig wäre.
Dafür müsste allerdings neben diversen GPIOs auch ein I2C Bus am Raspberry noch ungenutzt sein, womit ich wieder bei der Unklarheit zur MPU6050 von weiter oben bin(?). Ich würde das gerne Testen, habe aber keine Infos zur bisherigen Verwendung der GPIOs des RaspberryPi gefunden.
Soweit meine bisherige Erkenntnis und Fantasie, ich würde mich über eine Rückmeldung mit Korrekturen zu meinem Verständnis und Details zu den (genutzten) GPIOs am RaspberryPi freuen.
Sorry für den langen Text und DANKE!!! für die bisherige Entwicklungsarbeit!!!
Thomas
ich bin neu hier und lese seit ein paar Tagen in diesem Thread mit.
Hintergrund ist mein Wunsch einen Husqvarna Automower 220 auf GPS-RTK etc. umzubauen.
Heute habe ich dann mal das Repo von @EinEinfach geklont und etwas tiefer in den Code und die Schematics geschaut.
Danach glaube ich, dass man die Umsetzung der RaspberryPi Variante ohne RP-Pico vermutlich "relativ einfach" ausprobieren könnte.
Nach meinem bisherigen Verständnis hängen
- alle Motortreiber (inkl.Odometrie)
- die Bumper-, Notaus-, Charge/Battery-Schalter,
- die Strommessung (INA266 über I2C)
am RP-Pico und werden vom RaspberryPi über /dev/ttyUSB0 angesteuert oder abgefragt.
Das GPS hängt über USB-Seriell-Adapter am RaspberryPi.
Wifi hängt über USB am RaspberryPi (oder ist es integriert?).
In der config.h findet sich noch eine MPU6050, aber mir ist nicht klar geworden über welchen I2C-Bus die interagiert?
Meine Idee:
Unter Linux kann man ja nicht nur lokale IP-Verbindungen (127.0.0.1) zwischen Prozesse auf dem gleiche Rechner nutzen, wie zwischen Cassandra und Sunray, sondern in ähnlicher Weise auch Pseudoterminals (pty) für serielle Verbindungen.
Wenn man nun die Aufgaben des RP-Pico (in Sunray/alfred/firmware/rpi_pico/main.py) in einen eigenen Prozess auf dem RaspberryPi laufen ließe, müsste dieser Prozess mit Sunray über ein pty kommunizieren können, ohne, dass irgendeine sonstige Änderung an Sunray notwendig wäre.
Dafür müsste allerdings neben diversen GPIOs auch ein I2C Bus am Raspberry noch ungenutzt sein, womit ich wieder bei der Unklarheit zur MPU6050 von weiter oben bin(?). Ich würde das gerne Testen, habe aber keine Infos zur bisherigen Verwendung der GPIOs des RaspberryPi gefunden.
Soweit meine bisherige Erkenntnis und Fantasie, ich würde mich über eine Rückmeldung mit Korrekturen zu meinem Verständnis und Details zu den (genutzten) GPIOs am RaspberryPi freuen.
Sorry für den langen Text und DANKE!!! für die bisherige Entwicklungsarbeit!!!
Thomas
EinEinfach
Well-known member
Hallo Sunflare,
der MPU6050 hängt am I2C vom Raspberry Pi.
Anfangs wollte ich auch alles auf dem Raspberry Pi umsetzen, allerdings bin ich mit Interrupts gescheitert. Da kannte ich aber die Arbeiten von @ullisun58 noch nicht. Er ist mit seinem Projekt an dem Thema deutlich weiter.
Wir hatten irgendwo mal die Anzahl der benötigten Pins zusammengezählt und die Anzahl der Gpios auf dem Raspberry Pi war hart an der Grenze.
der MPU6050 hängt am I2C vom Raspberry Pi.
Anfangs wollte ich auch alles auf dem Raspberry Pi umsetzen, allerdings bin ich mit Interrupts gescheitert. Da kannte ich aber die Arbeiten von @ullisun58 noch nicht. Er ist mit seinem Projekt an dem Thema deutlich weiter.
Wir hatten irgendwo mal die Anzahl der benötigten Pins zusammengezählt und die Anzahl der Gpios auf dem Raspberry Pi war hart an der Grenze.
Hallo EinEinfach,
das ist dann vermutlich GPIO2/GPIO3 im Schaltplan?
Hängt an den anderen GPIOs, die Du beschriftet hast (0,1,4,5,6,13,19) auch etwas dran und wenn ja, was?
Die Anzahl ist knapp aber könnte reichen, ich mache mir mehr Sorgen um die "Performance", aber es reizt mich das mal zu testen.
das ist dann vermutlich GPIO2/GPIO3 im Schaltplan?
Hängt an den anderen GPIOs, die Du beschriftet hast (0,1,4,5,6,13,19) auch etwas dran und wenn ja, was?
Die Anzahl ist knapp aber könnte reichen, ich mache mir mehr Sorgen um die "Performance", aber es reizt mich das mal zu testen.
EinEinfach
Well-known member
Ja, es gibt noch Software UART (2Pins) über den die RTK Korrektirdaten Richtung UBLOX Platine kommen, das habe ich noch niergens dokumentiert
EinEinfach
Well-known member
Es hat sich über letzten Wochen bei mir etwas getan. Ich setze aktuell den Mäher als meinen Hauptmäher ein. Ziel ist Langzeiterfahrungen zu sammeln und in dessen Züge auch Verbesserungen an der Hardware und Software zu identifizieren und soweit es möglich umzusetzen.
Eine Verbesserung habe ich bereits auf dem Pico Code realisiert. Das Original Display des Landroids ist jetzt lebendig. Das Display wird über I2C des Picos angesteurt. Die Statis der Sunray FW sind in der sowieso vorhandenen AT+S message verpackt und können auf dem Display angezeigt werden. Die Ansteuerung läuft auf dem 2ten Kern des Picos, damit die eigentliche serielle Kommunikation mit der Main Unit nicht gestört wird. Die Versuche alles auf einem Kern laufen zu lassen führten zu sporadischen Kommunikationsproblemen zwischen dem Pico und RPI.
Eine Verbesserung habe ich bereits auf dem Pico Code realisiert. Das Original Display des Landroids ist jetzt lebendig. Das Display wird über I2C des Picos angesteurt. Die Statis der Sunray FW sind in der sowieso vorhandenen AT+S message verpackt und können auf dem Display angezeigt werden. Die Ansteuerung läuft auf dem 2ten Kern des Picos, damit die eigentliche serielle Kommunikation mit der Main Unit nicht gestört wird. Die Versuche alles auf einem Kern laufen zu lassen führten zu sporadischen Kommunikationsproblemen zwischen dem Pico und RPI.
Last edited: