Menü
Aktuelles
Von:
Filter

Alfred mit NTRIP über mobile RTK nutzen

KadaverJoe

KadaverJoe

Member
Hallo liebe community,

Ich möchte meinen Alfred bald in unserem neuen Heim in Betrieb nehmen, habe aber momentan noch kein WLAN zur Verfügung. Daher ist meine Idee, die RTCM-Korrekturdaten vorläufig über das Mobilfunknetz zu beziehen. Ich hatte dafür betreits mit @AlexanderG Kontakt, welcher mich netterweise auf das 4G NTRIP-Modul von Ardusimple (https://www.ardusimple.com/product/4g-ntrip-master/) hingewiesen hat. Hat damit bereits jemand Erfahrungen sammeln können? Ich kenne mobile RTK von unseren landwirtschaftlichen Arbeitsmaschinen. Diese greifen seit vielen Jahren über das Mobilfunknetz auf die Korrekturdaten meiner Basisstation zu. Dabei reicht eine Prepaid-Karte mit einem geringen Datenvolumen vollkommen aus.
Wie sieht es da beim Ardumower bzw. Alfred aus? Hat das schon jemand in Betrieb und kann mir seine Erfahrungen schildern?

edit: ich denke, die kostengünstigere Variante ist es, einen Raspberry Pi mit einem LTE Stick (Huawei E3372h) auszustatten und dann mit Hilfe von RTKLIB die RTCM-Daten zu einem Xbee zu streamen und dieses sendet die Daten dann an das Ardusimple board im Alfred. Das werde ich nächste Woche mal testen.


Viele Grüße
Konrad
 
Zuletzt bearbeitet:
Ich hatte mal vor einiger Zeit einen ESP32 WiFi Modul für RTK Daten im Einsatz. Auf der Firmware Oberfläche konnte man sehen wieviel Daten hat das Modul gesendet bzw. Empfangen hat… Lass mich Lügen aber ich bin der Meinung da war irgendwas mit 1-3GB über den ganzen Sommer hinweg, eher länger 4-5 Monate
 
Wenn Du es ganz "schlank" machen willst (ohne weitere Hardware), mit Linux fit bist und Dich mit der Konfiguration der Sunray-Firmware am Alfred etwas auseinandersetzen möchtest (und diese nach Anleitung am Alfred neu kompilieren möchtest wie hier beschrieben: https://github.com/Ardumower/Sunray ), kannst Du die Sunray-Firmware so konfigurieren dass ein NTRIP-TCP-Client aktiviert wird. Dieser schickt die Daten über serielle Leitung (mit USB-zu-seriell-Adapter) zum Ardusimple-Modul (an die Pins TX2/RX2), so wie ein XBee/NTRIP-Modul dies auch machen würde. Das Ardusimple-Modul benötigt dann kein XBee-Modul oder NTRIP-Modul. Der LTE-Stick am BananaPI/RaspberryPI baut dann die Internet-Verbindung auf, so dass der NTRIP-TCP-Client sich mit dem NTRIP-Caster (Server) verbinden und die Daten zum Ardusimple-Modul schicken kann.

Ich habe das vor einigen Jahren experimentell (=für ein paar Stunden) bereits (damals am Raspberry) ausprobiert... Aber wie immer: viele Wege führen nach Rom und nicht jeder möchte die Sunray-Firmware am Alfred neu kompilieren oder sich damit näher auseinandersetzen - Alternativ müsste man gar nicht Sunray neu kompilieren und kann diese Kommunikationsweiterleitung (TCP->Serial) auch über ein externes Programm wie RTKLIB machen...

alfred/config.h:
// --------- NTRIP client (linux only, highly experimental) ---------------------------------
//#define ENABLE_NTRIP 1 // must be activated to use Linux NTRIP
#define NTRIP_HOST "195.227.70.119" // sapos nrw
#define NTRIP_PORT 2101
#define NTRIP_MOUNT "VRS_3_4G_NW"
#define NTRIP_USER "user"
#define NTRIP_PASS "pass"

#define SERIAL_NTRIP_PATH "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0"
 
Zuletzt bearbeitet:
Mein Vorschlag:
A:
Im Mäher: simpleRTK-Modul mit esp32 anstelle xbee modul ausrüsten (1. ardusimple esp32-xbee-Modul oder 2. ein Standard esp32 selbst flashen, 20 Käbelchen mit Kontakten anlöten und in den Sockel stecken. Pinbelegung und Programm gibt es bei ardusimple als Download - kein Problem)
Damit kann sich der Mäher in ein wlan-Netz einloggen.
B:
Korrekturdaten hast Du wohl schon im Netz. Wenn nicht, kannst Du sie kostenfrei bei einem Serviceleister hochladen und sie so für dich im Internet verfügbar machen. Dafür muß die Basisstation natürlich die Daten auch ins Netz bringen können ( im Zweifelsfall über den esp32 per wlan)
C:
Wie kommen die Daten aus dem Netz zum Mäher. Hier gibt es wahrscheinlich viele Lösungen. Z.B. altes Handy mit Datenvertrag das einen Hotspot zur Verfügung stellt. Die esp-Module lassen sich über einen lokalen, eigenen AP gut parametrieren, das ist recht konfortable.

Das ist aus meiner Sicht wohl eine der preisgünstigsten Möglichkeiten mit gleichzeitig geringem Aufwand.
Gruß Fürst Ruprecht
 
Fürst Ruprecht schrieb:
Im Mäher: simpleRTK-Modul mit esp32 anstelle xbee modul ausrüsten (1. ardusimple esp32-xbee-Modul oder 2. ein Standard esp32 selbst flashen, 20 Käbelchen mit Kontakten anlöten und in den Sockel stecken.
Zum Vergrößern anklicken....
Unnötige Hardware, er hat schon BananaPi was im Netz hängt, dieser kann Daten empfangen und an Ardusimple weitergeben (wie Alexander oben schon beschrieben hat).

Ich habe das so im Ardumower Umfeld seit einem Jahr im Einsatz. Läuft deutlich stabiler als der ESP32Xbee Modul
 
@Fürst Ruprecht auch eine gute Idee. Ich habe einen eigenen NTRIP Caster für unsere Schlepper programmiert, auf die meine Base die Daten streamt. Ich frage mich nur, ob es nicht am besten und günstigsten ist, einen LTE Modem mit einem Pi zu verbinden, welcher dann per Xbee 868 MHz die Korrekturdaten an den Alfred sendet...ist das von der Netzstabilität nicht besser als WLAN? Gut, für Cassandra benötige wahrscheinlich ich eine gute WLAN Abdeckung im Garten, oder @EinEinfach?
Sonst finde ich die Idee der eh vorhadenen Hardware auch simpler! Die Idee fürs Streamen der Daten über Mobilfunk soll nur übergangsweise sein. Dauerhaft dachte ich an LoRa mit Xbee 868 MHz...oder doch lieber WLAN für Cassandra @EinEinfach ?
 
Ja, WLAN und NTRIP ist immer so eine Sache - wenn für max. 10 Sek. (sporadisch) keine WLAN-Verbindung zustande kommt ist das nicht weiter tragisch, fällt die Verbindung aber für mehr als 30 Sekunden aus kann das RTK seine Position verlieren und der Roboter steht dann und kommt nicht mehr von der Stelle :)
(mit normalem GPS fährt er nicht). Es kommt wohl ganz auf die Umgebung an und wie gut das WLAN ausgebaut ist... Für Cassandra reicht (vermutl.) eine stabile WLAN-Verbindung an der Ladestation und für einfache Kommandos (z.B. "manuell Dock") hin- und wieder eine WLAN-Verbindung (der Roboter arbeitet seinen Auftrag ab (mit oder ohne Timer) und fährt dann zur Ladestation um sich aufzuladen, neue Aufträge/Karten zu laden usw.) .
 
Zuletzt bearbeitet:
Ich bevorzuge 868 Mhz (Geschmackssache: ich bevorzuge niedrigere Frequenzen weil diese um Häuser "herumwandern" können...)

Die Kontakte beim Alfred-Akku müssten wie folgt belegt sein:
P+ Plus
C+ Charge Plus
T Temperature
C- Common Ground
IMG_20211209_134001.jpg
 
Zuletzt bearbeitet:
Ja, deswegen wollte ich auch 868 MHz nutzen ;-)
Heißt das, dass Alfred über C+ geladen und über P+ die Energie wieder entnommen wird?
Das könnte für mich interessant sein, da ich ja überlege, einen 20 Ah Akku in Alfred zu bauen…;-)
Könnte man dann über die Ladeports direkt in den Akku Laden, ohne den Strom durchs Mainboard führen zu müssen?
 
Da ist Vorsicht geboten, Du kannst Ladeports direkt an den Akku anschließen, wenn Du über eine Dioden den Rückfluss verhinderst.
Aber viel wichtiger ist dass das Netzteil die max. Akkuspannung nicht überschreitet und eine Strombegrenzung hat.
Und zuletzt muss das BMS des Akku das Laden auch überwachen und nicht nur als Balancer fungieren.
Akku ist kritisch, bei einem Fehler kann da schnell was abfackeln.
 
Ja, der C+ Anschluss geht über einen "Shunt" (0.05 Ohm) direkt zum Ladekontakt an der Ladestation und dort direkt zum Ladenetzteil. Der Shunt misst den Spannungsabfall und damit den Ladestrom. Da der Ladestrom sowieso nicht richtig im Alfred gemessen wird (Mondwerte) kann man auf diese Messung verzichten. Allerdings muss der Roboter wissen wann die Ladekontakte erreicht sind (dort stoppt er dann beim Andocken) und dafür müsste dann das Ladegerät weiterhin zum Mainboard P10 führen für eine Ladespannungsmessung (aber nicht zwangsläufig von dort in den Akku P11 - ich hoffe das ergibt so Sinn :) ).


Ladestation-Kontakte P10:
1711202852772.png

Akku P11:
Screenshot from 2024-03-23 14-59-07.png
 
Zuletzt bearbeitet:
BerndS schrieb:
Da ist Vorsicht geboten, Du kannst Ladeports direkt an den Akku anschließen, wenn Du über eine Dioden den Rückfluss verhinderst.
Aber viel wichtiger ist dass das Netzteil die max. Akkuspannung nicht überschreitet und eine Strombegrenzung hat.
Und zuletzt muss das BMS des Akku das Laden auch überwachen und nicht nur als Balancer fungieren.
Akku ist kritisch, bei einem Fehler kann da schnell was abfackeln.
Zum Vergrößern anklicken....
Ja, so in etwa hatte ich mir das gedacht. Was denkst du, kann man über die Standard-Ladeports an Strom übertragen? Ich würde ja bei 0,5 C theoretisch knappe 10A übertragen. Das wären dann ja 300W...
Ich habe mir ein 7S BMS gekauft, welches max. 15A laden könnte. Ich habe außerdem ein Netzteil mit dem ich die Leistung von 1-30 A begrenzen könnte. Ist aber nur eine Idee.
Alternativ habe ich überlegt, den Akku mit INR21700 zu bauen und dann mit dem original BMS zu laden und balancen. Spricht da was gegen? Alfred könnte meinetwegen ja die ganze Nacht laden.
 
Zuletzt bearbeitet:
AlexanderG schrieb:
Ja, der C+ Anschluss geht über einen "Shunt" (0.05 Ohm) direkt zum Ladekontakt an der Ladestation und dort direkt zum Ladenetzteil. Der Shunt misst den Spannungsabfall und damit den Ladestrom. Da der Ladestrom sowieso nicht richtig im Alfred gemessen wird (Mondwerte) kann man auf diese Messung verzichten. Allerdings muss der Roboter wissen wann die Ladekontakte erreicht sind (dort stoppt er dann beim Andocken) und dafür müsste dann das Ladegerät weiterhin zum Mainboard P10 führen für eine Ladespannungsmessung (aber nicht zwangsläufig von dort in den Akku P11 - ich hoffe das ergibt so Sinn :) ).


Ladestation-Anschluss P10:
Anhang anzeigen 7197

Akku P11:
Anhang anzeigen 7196
Zum Vergrößern anklicken....
Danke! Das ist ein super Hinweis! Ich hatte schon überlegt, am Ladeport mit einem BEC einfach nur eine Spannung von 30 V abzugreifen. Aber die Leistung müsste dann natürlich ordentlich gedrosselt werden.
 
Ich kann jetzt aus dem Stand nicht sagen was die Ladeelektronik macht, denke aber nicht mehr als 1,5-2A. Das ist zu wenig, denke ich um 20Ah zu laden.
Das NT und das BMS einfach mal testen, wichtig ist die max. Spannung am NT einstellen.
 
Ja, ich werde da auf jeden Fall mal rum probieren. Erstmal werde ich testen, wieviele 21700 Batterien ich überhaupt unter bekommen würde.
Das original NT hat ja eine Ladeleistung von 57 W. Wenn der Akku knapp 600 Wh hätte, müsste er bei einer Restkapazität von 20% ca. 8 h laden. Gegen eine niedrige Ladeleistung spricht aus meiner Sicht garnichts. Es wäre auf jeden Fall ein sehr schonendes Ladeverfahren. ;-)
 
AlexanderG schrieb:
dafür müsste dann das Ladegerät weiterhin zum Mainboard P10 führen für eine Ladespannungsmessung (aber nicht zwangsläufig von dort in den Akku P11
Zum Vergrößern anklicken....
Wenn ich die Spannung bis dort parallel einspeise, sie aber von dort nicht weiter über P11 in den Akku leite, dürfte theoretisch doch auch eine höhere Ladeleistung von - meinetwegen 7-10 A - kein Problem sein, oder?
 
noch eine Frage: über welchen Port kommuniziert Alfred mit der App bzw. dem Web interface? Ich versuche gerade einen LTE-Router so aufzubauen, dass er per VPN Tunnel erreichbar ist (was auch schon funktioniert). Nun muss ich es nur noch hinbekommen, dass ich Alfred via remote router erreichen kann...
edit: ich habe jetzt Port 80 probiert und funktioniert.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben