Onderwerp: XTE gaat de verkeerde kant op?

Ja, dat zou ik ook denken. Dan zou het in deze weergave kunnen betekenen 'De route bevindt zich 0,05 nm links van u' of toch, zoals BK suggereert, een 'stuur naar links' instructie op basis van de heading? Maar dat laatste zou ik wel heel raar vinden, om meerdere redenen.

Hij heeft het gewoon fout hoor.
Als je even de kakkerlak op de rolling road in ogenschouw neemt dan is er echt geen twijfel meer!
Wat je wilt is je echte positie t.o.v. je hartlijn en niet het tegenovergestelde!

Pakken we een willekeurige RMB daaruit...

$ECRMB,A,0.049,L,001,002,5300.009,N,00447.045,E,0.909,359.809,8.694,V,A*70

0,049 mijl XTE: bijna 100 meter naast de rechte lijn
L voor steer Left naar de lijn toe (dus zit rechts van de lijn van haven naar haven, klopt met plaatje)
Waypoints 001 en 002 (1 is Den Helder!)
lat en lon van Waypoint 002 Destination
distance to wp 0.909 mijl
bearing to wp 359,809 (zeg maar 0 graden, noord)
closing velocity 8,694 kts.

Nergens een COG.... Die heb ik in onderstaand plaatje er maar even bij gemaakt.
Als je hem doortrekt naar voren zie je dat hij niet in de haven komt; er zal bijgestuurd moeten worden....

Even de basics:
- COG is per definitie iets dat al gebeurd is. Er bestaat geen COG in de toekomst.
- je zou wel kunnen aannemen dat de huidige COG een aanwijzing vormt voor de toekomstige COG. Maar dat gaat niet altijd goed: stroming, drift kunnen veranderen. (zullen veranderen).
- zelfs de Wagenmaker kan dat niet : zijn doorgetrokken COG komt NAAST de haven uit.
- BTW is altijd van actuele positie naar Waypoint.
- en daarmee de kortste route naar dat waypoint.
- XTE is tov de lijn tussen waypoint en positie bij het starten van de route.

Knoet schreef :
Dat is hoe het in een RMB door NMEA is gedefinieerd:

De RMB die OpenCPN uitstuurt klopt dus? Waarom geeft de multi bij holtere de “direction to steer” dan grafisch fout aan? Dat moet in de muti zelf zitten toch? SPD stuurt geen RMB uit (die wellicht door de gebruiker herdefinieerd zou kunnen zijn)?

holtere schreef :
Dat is wel zeker.
En ik denk dat dat komt omdat hij (OCPN) Heading neemt om te zien hoe je terug komt bij de ideale lijn (XTE=0 maken).

Kijk eens of je in OCPN kan kiezen tussen COG en HDG om de stuur-richting te bepalen?
Als dit echt zo is kan je stuurautomaat er ook zomaar geen sjokola van maken. Die stuurt op (onder meer) XTE en RMB;
Maar misschien is die zo verstandig te kijken hoe XTE kleiner wordt, door L of R te sturen.
En hij kan kijken of de COG in de buurt zit van de BTW.
Als ie dat doet gaat het lukken; kijkt ie niet naar die foute L...
Die is door OpenCPN speciaal erin gezet voor menselijke stuurlieden
Om te kijken of ze wel opletten, want Open Sores is om van te leren, heb ik begrepen

Baasklusje schreef :
De COG (prediction inderdaad, op basis van het recente verleden...) is de rode streepjeslijn en staat ook in de statusbalk die niet op de vorige schermafdruk te zien was:



We voeren hier inmiddels weer naar Den Helder, heen en weer, heen en weer..

@Holtere, zit er toevallig niet ook nog een mux tussen die iets met RMB doet?

Nee, er zijn geen rare instellingen in de mux.
Ik vaar morgen een stukje en zal op het moment supreme even een logje maken van de RMB in Opencpn. Dan weet ik een hoop meer!

Knoet schreef :
Now we are getting somewhere voorspelling obv recente verleden
En niet aanwezig in een RMB.

Ik kan me voorstellen dat dat een handige extra is op een veerboot op stroom.

Maar die luxe heeft holtere niet. Die heeft BTW in het plaatje staan....

Ik heb nog niet gevonden hoe ik in OpenCPN een grafische weergave van BTW kan krijgen, maar als Holtere dat voor elkaar gekregen heeft, en als dat er net zo uit ziet als de COG (prediction!) in de standaard instellingen, dan ben ik benieuwd waar dat zit.

Knoet schreef :
Gaat dat niet vanzelf als je naar een waypoint navigeert?
In WinGPS krijg je een lijn van positie naar target (hier de boei MS1)
Die lijn geeft (als je vaart) de BTW aan.
De HDG en COG zijn hier allebei default 0 (geen GPS-data).

Ik dacht dat een graphische BTW alleen in wingps vertoond wordt.

Wat heeft HDG met GPS van doen?

Gepost met de officiële Zeilersforum-app

666 schreef :
Niets
Ik bedoelde geen enkele NMEA-input, ook geen HDG uit de EV1

Even gezocht bij OpenCPN (site, docs) hoe ze hun navigatie-berichten voor een AP maken.
Daar moet een RMB bij zijn, waarin die L of R gemaakt is op basis van 'iets' (COGof HDG).
Geen woord over te vinden, niets.

Wel de klassieke fout met de verwisseling van From en To-waypoint:



En dat is toch echt andersom.
Misschien komt de fout omdat ze willen dat je terugvaart naar From!

Wel gek hoor, zulke dingen.
Basic slordigheden, net zoals de CMG in kts (jawel, een Course in Kts) in de Tactic-plugin.
Het lijkt erop dat het in elkaar gezet is totdat het werkte, en dat daarna niemand meer oplet of er misschien nog foutjes in zitten..... vooruit met de geit, op naar een nieuw release, de shit ligt lekker achter ons.

Alles op gebied van waypoint varen gaat op basis van over de grond.

Geen drift, geen heading, geen STW

henkvd schreef :
Logisch. Een ouderwetse GPS heeft niets anders (alleen COG en SOG).
Maar als (áls) OpenCPN de L of R in de RMB zet na een vergelijking met de HDG..... (en daar lijkt het op)

En daar gaan ze de mist i.
Of het slim is en de snelste route is ander verhaal.

henkvd schreef :
Terug naar de lijn is altjd een omweg
Je hoeft pas bij het waypoint weer XTE = 0 te hebben (tenzij obstakels onderweg).

Onze testboot Grand Wazoo vaart vandaag met een ander navigatieprogramma.
Dat snapt het wel.
Toen hij rechts van de lijn zat zei de RMB dat hij naar links moest sturen: (x in de positie voor privacy)

$ECRMB,A,0.386,L,004,005,xxxx.709,N,00xxx0.411,E,11.514,252.466,7.688,V,A*41

Hm, ik begrijp het nog niet helemaal denk ik. Wat is hier fundamenteel anders dan wat je schreef over de ECRMB uit openCPN in zeilersforum.nl/index.php/foru...-op?start=25#1295921 ?

Die post ging over de Wagenmaker?
Die moest ook naar L sturen om op zijn bestemming (waypoint) te komen.
Dat was goed (in de RMB), en zo ook hier:
De Grand Wazoo zit rechts van de lijn en zal links aan moeten houden om bij het waypoint te komen.
En dat staat ook in de RMB....

Wat er nu op de ST60 staat weet ik niet...heb hier wel de manual van die Graphic.

Hij zit teveel links, moet dus naar rechts sturen. Duidelijk wel....

grappig zit in de code van OpenCPN te snuffelen
In versie 5 was de RMB goed, in 5.2.x is het fout, in de master code is het nu weer goed gezet.

Alleen de code om XTEDir te berekenen (en die zorgt voor de Links of Rechts) daar is niks aan aangepast.

baggah schreef :
Dat is wel heel grappig ja... voor het eerst van mijn leven heb ik er ook in gekeken....Dus links van de track (NIET: left side of the track) dan XTE negatief.

Vervolgens de RMB maken:

100% fout....
(en te ingewikkeld gecodeerd.
Ik doe in zo'n geval
XTEdir=Right
If <0 = Left
(weer een regel code minder )



En of de XTEdir goed berekend wordt is ook nog de vraag.

En Passant kunnen we ook even vaststellen dat de BTW in de RMB wordt gestopt:
en dus niet de (voorspelde) COG.
Die BTW zou toch ook op de kaart moeten komen.....

Jullie zijn goed bezig jongens
Altijd fijn om te horen dat je niet helemaal het spoor bijster bent en dat er gewoon een reden is voor die gekkigheid

Ik vind het raar dat deze behoorlijke fout door geen van de duidenden gebruikers is opgemerkt en als bug is gerapporteerd. Ik geloof het hoor, maar hoe kan dat? Doet verder niemand iets met met die “direction to steer” behalve uitgerekend onze eigen holtere die nu per ongeluk toegetreden is als Bètatester?

Het creëren van die RMB om uit te sturen lijkt inderdaad snel in elkaar geflanst en niet volledig getest. Mijn (vast onjuiste) gedachte was dat bij een open-source development verschillende mensen iets oppakken/uitwerken waar zij goed in zijn/leuk vinden (gaat meestal samen). Dan doe je toch eerst, als developper, de basale testen? Dit beeld klopt niet dus? Hoe scoor je in die community, als dat de drijfveer zou zijn? Door zo snel mogelijk iets over de muur te gooien (“testen maar jongens, was heel eenvoudig, avondje werk!”) of door slimme goede code op te leveren? Krijgen developpers duimpjes, minnetjes; worden ze verbannen bij consistent matige kwaliteit??

Kan iemand daar een kijkje geven, want ik heb geen idee...