poor mans precision farming

Fragen und Hinweise zu Software, die mit dem Thema GPS zu tun hat. Egal ob PC oder Handheld.

Moderator: Roland

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 28.01.2013 - 23:11

Hagen.Felix hat geschrieben: Hallo Wolfgang,
ist der "Denga10" bei Anthony in England denn tatsächlich bedeutend günstiger als bei Michele in Pisa selbst? :?:
Denn der Entwickler & Produzent ist ja in beiden Fällen identisch ... :roll:
Auch der NVS-Code in RTKLIB ist ja "Made in Italy" ... :lol:
Hallo, Felix,

ich hab' so was befürchtet....deswegen ja die ### :?

Macht das bitte unter Euch Profis aus!
Scheint, die Welt ist echt klein...
Und ich bin nur Zaungast in diesem offensichtlich erlauchten Zirkel.

Der Spagat zwischen den beiden Welten - hehre "open soruce"-Ideologie einerseits und schuldgeldbasierte Peanuts-Ökonomie (da wo unsere Frauen immer Einkaufen gehen) ist mir durchaus bewußt.

Ha, da darf ich doch glatt noch einen zum Besten geben, aus einer Mail, die heute bei mir eingegangen ist:
Er ist GPL, aber nicht frei verfügbar (bisher hält sich auch jeder Nutzer
an die Bitte es nicht frei zur Verfügung zu stellen :-). Ist bei #### für
etwa 1000 Euro zu bekommen.
Du meinst, ich krieg' da jetzt einen echten Denga10 von Anthony? Whow!
Schau' mer mal.... vielleicht hat er ja was abgespecktes gebaut bzw. lassen.

Ich hatte gestern schon bei Farnell ein nacktes Modul bestellen wollen.
Die fünf Drähte an ein 1.25 mm pitch werden meine alten Augen schon noch gelötet kriegen.
Aber die wollen meinen Gewerbenachweis stehen. Und da steht "Handel mit Fleisch- und Wurstwaren" drauf :wink:

Was hat es eigentlich damit auf sich:
"special" NV08C-CSM factory-calibrated for Glonass code group delay!
http://www.onetalent-gnss.com/ideas/usb ... rs/denga10

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 28.01.2013 - 23:39

thomash hat geschrieben:Generell macht es alleinige Entwicklung einfacher, weil man sich nicht in Diskussionen über die Struktur und wo es hingehen soll streiten muss, dass kann ich durchaus verstehen.
Keine Frage. Das kenn ich aus eigener Erfahrung.
Deswegen fiel mir auch der Geräteträger-Ein-Mann-Vergleich ein. Das war ja sicher ein sehr erfolgreiches Produkt und ein wichtiges Stück Weg hin zu dem was Fendt heute ist. Auch wenn es jeder Organisationsentwicklungs-Weisheit widerspricht.
thomash hat geschrieben:Auf github kann man ganz leicht ein Repo forken daran arbeiten und dem Entwickler vorschlagen die eigenen Änderungen wieder in den Main Branch einfließen zu lassen (Pullrequest).
Das wäre sicher lobenswert. Was spricht der Meister dazu?
Ich habe auch schon mal versucht, eine Teamarbeit zu forcieren, indem ich die Sourcen auf SVN gelegt habe (war wohl so was wie ein Vorläufer von github, mußte man damals noch selber hosten).
Das hat dann damit geendet, daß ich allein mit dem System gespielt habe. Aber allein die Dokumentation der Änderungen, das Browsen in den Versionen und das direkte Extrahieren von diffs / patches (geht das bei github auch?) war selbst für diese one-man-show Gold wert.
thomash hat geschrieben:Allerdings ist das von Prozessor zu Prozessor unterschiedlich
Das ist es ja, was mir den Respekt vor den Linux-Maintainern abringt. Da geht nix raus (bzw in den main branch), was nicht sauber quer über alle Plattformen baut.
Klar ist mir aber auch, daß das ein Genie wie Takasu ausbremst.
thomash hat geschrieben:Soweit ich das sehe, war die Lib zu Beginn nicht gedacht so portabel und generell anwendbar zu sein und bedarf daher etwas Zuwendung, wenn man die Architektur wechselt.
Jetzt verstehe ich auch, warum man bei vielen Linux-Paketen oft in der README liest:
... auf der Basis von ... abgesplittet aus dem XYZ-projekt ... etc.
thomash hat geschrieben: Da würde ich dir aber den Import des Codes in eine IDE wie Eclipse nahelegen, das macht Vieles einfacher.
Ehrlich?
Ich hatte einmal Eclipse selber in der Hand, vor ca 4 Jahren.
Mit Python ... übel... speib [ ja, ich bin PERLianer... ]
Da wollte ich eine GPS-Überwachung für meinen Beregnungswagen bauen, mit einem GPS-Modul, das "nebenbei" noch Python konnte. Absolut unausgereift (Eclipse, meine ich). Mehr Abstürze als Erfolgserlebnisse.
Mein Junior hat vor ein paar Jahren in der Schule einen Java-Kurs mit Eclipse gemacht - identische Rückmeldung.

Aber wenn Eclipse für die C-Entwicklung ausgereift ist, wäre eine IDE sicher einfacher, als sich auf der Konsole mit vi und manpages durch die makefile-Synax zu quälen.
Kannst Du mir ein gutes Tutorial für den schnellen Einstieg empfehlen?

Eigentlich wollte ich ja nicht zu tief in die Programmierung, weil mein Vorhaben ohnehin schon recht umfangreich ist.
Aber ich grüble derzeit um die Integration von Kalman-Filterung aus verschiedenen Quellen (meherere Empfänger auf einem Rover, Gyro, Accelerometer, Magetomenter....).
Wenn Dein github steht, schick mir bitte einen Link.

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: poor mans precision farming

Beitrag von Hagen.Felix » 29.01.2013 - 00:11

wrosner hat geschrieben: ...
Du meinst, ich krieg' da jetzt einen echten Denga10 von Anthony? Whow!
Schau' mer mal.... vielleicht hat er ja was abgespecktes gebaut bzw. lassen.
...
Na ja, bin da vielleicht auch nicht ganz aktuell informiert ... :roll:

Kann schon sein, dass da ein älteres und/oder einfacheres Design einfach mal in eine größere Kleinserie gegangen ist.

Ich wollte ja nur auf die ursprüngliche Quelle hinweisen.

Bei Michele selbst ist es demgegenüber ja eher so, dass man bei ihm beinahe gar nicht mehr hinterherkommt, die fortwährenden Revisionen bzw. Re-Designs zu "verinnerlichen". :D

Der Bursche ist quasi permanent am Optimieren! :mrgreen:
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 29.01.2013 - 00:34

Hagen.Felix hat geschrieben:Der Bursche ist quasi permanent am Optimieren! :mrgreen:
Der Name ist Programm: onetalent-gnss :wink:

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 31.01.2013 - 23:03

thomash hat geschrieben: Das geht aber nicht auf jeder Architektur, weil diese Typen da nur auf bestimmten Speicherstellen liegen dürfen (Vielfache von 4 oder so). Das kann immer passieren, wenn man einen kleineren Datentyp über Zeigerzugriff auf einen größeren castet.

Abhilfe schafft dann manuelle kopieren der Bytes auf die Zielvariable, diese legt der Compiler schon auf eine gültige Stelle, weil es den Typ weiß,
Hm...
jetzt bin ich mal dummer User aka C-Programmierer (sorry, ist das vermessen?)
Und ich denke mal, der gcc ist eines der ausgereiftesten Stück Software auf diesem Planeten.

Wenn es denn wirklich so sei, daß das Zeigerrumgebiege nicht unanständig ist, sprich von der Sprachdokumentantion abgedeckt ist, sollte ich da nicht eigentlich berechtigerweise erwarten, daß der Compiler so was selber schnallt und die Zielvariable entsprechend anlegt?

Ich hab' nämlich grad eben meinen ersten test.ubx-log aus einem NL507ETTL auf raspberry mit convbin (ohne patch gebaut) in RINEX convertiert - und keinen BUS FAULT bekommen.

Könnte es vielleicht sein, daß die frühen Raspberry-gcc-Kompiler da nicht ganz ausgereift waren?
Oder daß es an Kompiler-Optienen im Makefile liegt?
Wie schön wäre es nun, ein svn/git zu haben, dann könnte man das sofort diff'en...

Gruß Wolfgang

XPosition
Beiträge: 214
Registriert: 25.08.2008 - 00:09

Re: poor mans precision farming

Beitrag von XPosition » 01.02.2013 - 13:56

@wrosner
Also erstmal ist es eine Frechheit in einem Datenstrom unaligned Elemente zu verschicken.
Denen gehören die Ohrläppchen langgezogen.

Wir reden hier über eine ARM11 CPU. Die kann sogar mit ganzzahligen unaligned Elementen umgehen(ältere konnten das auch nicht),
aber nicht mit Fließkommawerten die unaligned im Speicher liegen.
Man könnte jetzt mit einer Option kompilieren, die den Softwareemulator für Fließkommas aktiviert,
dann würden keine exceptions mehr auftreten. Das hätte aber den bösen Nachteil, dass die Fließkomma Berechnungen langsamer würden.
Für rtklib wäre das tödlich.

Dass du keine Probleme mit Ublox hast liegt daran, dass sie ihre Daten immer schön aligned rüberschicken. Wie es sich gehört.

@thomash
Ob da "memcpy" so eine gute Idee ist ? Ich würde mal testen ob es nicht nicht schneller ist, die Bytes selbst rüberzuschreiben.
Übrigens gibt es auch ARM Plattformen auf denen die Fließkommawerte bigendian sind. Da würde die rtklib auf die Nase fliegen.
Aber das ist wohl vernachlässigbar.

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 01.02.2013 - 14:17

XPosition hat geschrieben: @thomash
Ob da "memcpy" so eine gute Idee ist ? Ich würde mal testen ob es nicht nicht schneller ist, die Bytes selbst rüberzuschreiben.
Übrigens gibt es auch ARM Plattformen auf denen die Fließkommawerte bigendian sind.
Ich bab mir zwar das Assembler Listing nicht angesehen, aber besser optimieren als mit einer dezitierten Kopieranweisung (was ja memcpy für den Compiler ist) sollte der Compiler nicht können. Bei for Schleifen muss der Comiler immer erst draufkommen, dass er mögliche Spezialbefehle fürs Kopieren verwenden kann. memcpy sollte in diese Richtung schon optimiert sein (für die jeweilige Architekur optimierter handgestrickter Assemblercode), um diese Tricks abhängig von der Zahl der zu kopierenden Bytes optimal zu nutzen und auch geinlined werden, bei -O3 ganz sicher. Wobei ich mir bei so kurzen Schleifen jetzt keinen Geschwindigkeitsunterschied in die eine oder andere Richtung erwarten würde, aber man sieht einfach gleich was passiert.

@endianess
das hab ich auch schon kurz angesprochen, müsste man auch noch extra berücksichtigen.

cr2_gps
Beiträge: 121
Registriert: 04.10.2011 - 19:18

Re: poor mans precision farming

Beitrag von cr2_gps » 01.02.2013 - 15:24

wrosner hat geschrieben: in RINEX convertiert - und keinen BUS FAULT bekommen.
Ein SIGBUS wird immer vom Kernel initiiert, und diese Zugriffe sind ohne jeden Zweifel
unaligned:

Code: Alles auswählen

unsigned char *p=raw->buff+6;
...
   tow =U4(p  );
...
   raw->obs.data[n].D[0]  =R4(p+16);
Es hängt alles davon ab, was im "unaligned access trap handler" steckt: wird der Kernel das selber regeln
(sehr inperformant) oder enfach ein SIGBUS schicken.

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 02.02.2013 - 01:08

thomash hat geschrieben: Darum will ich die RTKLIB auf github Stellen und meine Änderungen und auch andere darin einpflegen.
Hallo, thomash,
könnte es sein, daß schon vor Dir jemand diese Idee hatte?
https://github.com/ianmartin/rtklib
wenn ich das richtig sehe, ist die letzte eingepflegte Version 2.4.1
Es ist sicher nicht im Sinne von git, parallele Äste nebeneinander her laufen zu lassen, oder?

cr2_gps
Beiträge: 121
Registriert: 04.10.2011 - 19:18

Re: poor mans precision farming

Beitrag von cr2_gps » 02.02.2013 - 10:31

wrosner hat geschrieben: könnte es sein, daß schon vor Dir jemand diese Idee hatte?
https://github.com/ianmartin/rtklib
Nicht nur einer
https://github.com/ethz-asl/rtklibros

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 02.02.2013 - 11:30

cr2_gps hat geschrieben:
wrosner hat geschrieben: könnte es sein, daß schon vor Dir jemand diese Idee hatte?
https://github.com/ianmartin/rtklib
Nicht nur einer
https://github.com/ethz-asl/rtklibros
Und auch diese wurden nicht geforked, pöhse, pöhse! Ja, es ist nicht im Sinne von Github, das viele gleiche Repos parallel betrieben werden, denn bei einem Fork kann man die Änderungen wieder leichter im Master übernehmen.
Das eine Repo hat schon seit 2 Jahren keine Commits mehr, und bei beiden fehlt mir irgendwie die Beschreibung was genau sie ändern wollen.

Ihr müsst meine Änderungen nicht übernehmen, ich kann diese auch gerne für mich behalten und habe sie nur schnell auf github gestellt, weil hier danach gefragt wurde.
Ich glaube nämlich nicht, dass allzu viele in diesem Board die Alignment Bugs selbst hätten fixen können und wenn sie niemand veröffentlicht (ausser in einem russischen Forum) ist es zwar schön für einen selbst, aber die Mehrheit hat nichts davon.

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 02.02.2013 - 13:15

thomash hat geschrieben: Ihr müsst meine Änderungen nicht übernehmen, ich kann diese auch gerne für mich behalten
und habe sie nur schnell auf github gestellt, weil hier danach gefragt wurde.
Ich glaube nämlich nicht, dass allzu viele in diesem Board die Alignment Bugs selbst hätten fixen können und wenn sie niemand veröffentlicht (ausser in einem russischen Forum) ist es zwar schön für einen selbst, aber die Mehrheit hat nichts davon.
Um Gottes Willen, bitte nicht beleidigt sein :shock:
Natürlich sind wir Dir sehr dankbar, wenn Du den open-source-Geist lebst. :D
Mir ging es eigentlich drum, ein Zusammenführen der branches und anderer zerfledderter Engagements anzuregen.
Aber dafür braucht es wohl einen Maintainer, der einerseits Ahnung hat (von github z.B. und von C), sich andererseits aber freiwillig und unentgeltlich in die Niederungen des Ordnung Schaffens begibt.
thomash hat geschrieben: habe sie nur schnell auf github gestellt
darf ich um einen Link bitten?

Wäre es nicht angesagt, für die rtklib eine kpl. open source Infrastruktur aufzubauen, mit Mailingliste, Bug-Tracker, Doku etc?
So wie bei sourceforge z.B.?
Aber wer macht das?

Ich hab' z. B. heut nacht auch wieder ein dämliches Problem, das sicher auch andere vor mir hatten:

Code: Alles auswählen

pi@raspberrypi ~/test/ublox/rtk $ str2str -in serial:///dev/ttyAMA0#ubx -out test06.rtcm3#rtcm3
stream server start
stream server start error
Wenn ich den Umweg über ein File gehe, geht es, sowohl über den vollen Pfad als auch über den reinen Dateinamen.

Code: Alles auswählen

 ..... cat /dev/ttyAMA0 > test04.ubx  ^C ....

pi@raspberrypi ~/test/ublox/rtk $ str2str -in  test04.ubx#ubx -out test04a.rtcm3#rtcm3
stream server start
2013/02/02 11:02:37 [CC---]          0 B       0 bps 1004,1019
2013/02/02 11:02:53 [CC---]    3768320 B 1570296 bps 1004,1019
Segmentation fault

pi@raspberrypi ~/test/ublox/rtk $ str2str -in  file:///home/pi/test/ublox/rtk/test04.ubx#ubx -out test04.rtcm3#rtcm3
stream server start
2013/02/02 11:01:23 [CC---]          0 B       0 bps 1004,1019
2013/02/02 11:01:44 [CC---]    3768320 B 1472200 bps 1004,1019
2013/02/02 11:01:49 [CC---]    6881280 B 1725716 bps 1004,1019
2013/02/02 11:01:54 [CC---]    7405568 B  677135 bps 1004,1019
Segmentation fault

Wobei die "Segmentation fault" auch noch auf ein Problem hinweist.
War da nicht mal was mit plattformspezifischen EOF-codierungen?

Werde heute abend mal in die Sourcen einsteigen, es mit 2.4.1 nochmal versuchen, oder das ganze per netcat auf eine x86-Plattform ziehen.

Aber Hamsterrad geht vor Spielwiese :-(
Erst mal muß ich in meinen abgesoffenen Elevatorkeller und Rohrleitungen umbauen. Kunde droht mit Auftrag und will nächste Woche 15 Tonnen Saatgut abholen.

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 02.02.2013 - 14:13

wrosner hat geschrieben: darf ich um einen Link bitten?
Ich hab einen Thread hier dazu aufgemacht:
http://www.kowoma.de/gpsforum/viewtopic.php?f=4&t=3376
wrosner hat geschrieben: Wäre es nicht angesagt, für die rtklib eine kpl. open source Infrastruktur aufzubauen, mit Mailingliste, Bug-Tracker, Doku etc?
So wie bei sourceforge z.B.?
Aber wer macht das?
Das gibt es auf github auch. Ich hab bei meinem Projekt eine kurze Anleitung ins Wiki geschrieben und zwei Milestones erstellt. Bugtracking und Feature requests gehen natürlich auch.

cr2_gps
Beiträge: 121
Registriert: 04.10.2011 - 19:18

Re: poor mans precision farming

Beitrag von cr2_gps » 03.02.2013 - 16:59

wrosner hat geschrieben: Wobei die "Segmentation fault" auch noch auf ein Problem hinweist.
Dieses Problem trifft man auch auf x86:

Code: Alles auswählen

cr2_gps@debian:~/Downloads/rtklib_2.4.2b8/app/str2str/gcc$ gdb ./str2str 
*
(gdb) run -in file:///home/cr2_gps/base.ubx -out file:///dev/null
*
Program received signal SIGSEGV, Segmentation fault.
0xb7e88444 in _IO_default_xsputn (f=0xbfffd734, data=0x80f9ad5, n=1) at genops.c:480
480     genops.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
*
#4  0x080ab978 in strsvrstat (svr=svr@entry=0x8101900, stat=stat@entry=0xbfffdd10, byte=byte@entry=0xbfffdd24, bps=bps@entry=0xbfffdd38, 
    msg=msg@entry=0x80abb65 "1004,1019") at ../../../src/streamsvr.c:561
#5  0x0804a80c in main (argc=5, argv=0xbffff384) at ../str2str.c:254
(gdb) list ../../../src/streamsvr.c:561
556             }
557             else {
558                 strsum(svr->stream+i,NULL,NULL,byte+i,bps+i);
559                 stat[i]=strstat(svr->stream+i,s);
560             }
561             if (*s) p+=sprintf(p,"(%d) %s ",i,s);
562         }
563     }
564     /* peek input/output stream ----------------------------------------------------
565     * peek input/output stream of stream server
(gdb)

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 03.02.2013 - 21:52

@cr2_gps

Ich habe zu dem Thema "str2str Segmentation fault" einen "issue" auf Thomas's github angelegt:

https://github.com/tyler123durden/rtklib/issues/3

Wäre doch nett, wenn wir das Engagement von Thomas für eine strukturierte Weiterentwicklung der rtklib hier gemeinsam unterstützen würden 8)

So wie es aussieht, werden derer Kleinigkeiten noch Dutzende folgen....
Ich glaube, das franst hier den roten Faden nur unnötig aus.

Gruß Wolfgang Rosner

Antworten