Onderwerp: XTE gaat de verkeerde kant op?

Hoezo uitgerekend onze eigen Holtere...
Das een wakker gassie hoor

Was goed bedoeld hoor; in de geest van “dicht bij huis”!

Ik denk dat het in dit geval een 'niet goed gelezen' dingetje is.
De RMB specificeert 'direction to steer'. Terug naar de lijn waar je moest zijn.
Als je links zit, dan naar rechts en v.v.
Maar dat snap je alleen als je een zeiler bent die weet waar het over gaat.
Niet als je alleen een (slimme) coder bent, de materie-kennis is echt nodig hier.

Zelfde soort dingetje in de Tactics-plugin, ik heb het al gezegd: de CMG in Kts.....

Ooit heb ik de wikipedia aangepast voor de Blokkanalen in Nederland.
Stond (natuurlijk) Kanaal 1 CMIJ in als Blokkanaal.
Ik heb het zeker 10 keer veranderd in Informatiekanaal, er is immers geen meldplicht en het is geen blokkanaal.
Werd 9 keer weer terugveranderd in Blokkanaal... door iemand die dus niet wist hoe het zat.
Even gekeken, mijn tekst staat er nog

Volhouden dus, er zijn genoeg mensen op deze aardkloot die denken dat ze het weten.
Ze hebben wel de melk horen klotsen, maar ze weten niet waar de tepel hangt (zo was het spreekwoord toch )

We hadden toch een Opencpn specialist in huis?
Misschien dat hij er wat mee kan?

Die ontwikkelt niet maar duikelt wat 64 bits betaversies op die bij hem op zolder altijd werken. Als je geen kant-en-klaar kaartje accepteert en vol houdt dat er écht ergens iets niet goed werkt is dat user error of zoals in 3Noreen’s geval ook zijn fout:

Ik bedoel iemand anders....zal eens zoeken.

Ehhh, Rooie Dirk toch?

Ja!

holtere schreef : Maar je moet ook naar links om bij het waypoint uit te komen. Toch?
OK je zit ook links van je koerslijn, maar je cog is dusdanig dat je rechts van je waypoint uit gaat komen en dus zou je de koers wat naar links moeten bijstellen. (Voor de puristen links en rechts te lezen als BB en SB) Dus om kort te gaan O vergelijkt de COG met de BTW(Bearing To Waypoint) en bepaald zo li of re)
Hier hoe OpenCPN hiermee omgaat.
https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:advanced_features:route_to_autopilot

Die R of L heeft dus niets met de XTE of originele route-leg temaken?

Ik snap deze discussie nog niet erg.
Als er afwijking naar links is moet je naar rechts als je voor de afwijking wil corrigeren.
Als de temperatuur te hoog is kan je hier voor corrigeren door een lagere instelling voor de temperatuur te kiezen.
Logischer kan ik het niet zien...


Een gevaarlijk (maar wel werkend) ezelsbruggetje zou kunnen zijn "beweeg de helmstok in de richting van de XTE als je wil corrigeren".

rooiedirk schreef :
De code was duidelijk. Daar staat, zagen baggah en ik, 'stuur naar links als je links van de lijn zit'.
En dat is fout.
In een RMB staat hoever je naast de lijn zit, de XTE, zonder teken, en een direction-to-steer, L of R.
In dit geval van holtere zit hij links van de lijn en moet er in de RMB dus een R staan: terug naar de lijn is naar rechts. Dat moet in die RMB omdat de AP dat dan begrijpt.

Of de COG wel of niet bij het waypoint uit gaat komen is voor de RMB geheel niet van belang.
Dat zou ook gevaarlijk zijn om te gebruiken. Als je niet op de vooraf gekozen lijn zit (die heb je niet voor niets gekozen) kan je van alles tegenkomen onderweg..... dus een navigatie die zelf zegt de COG en de BTW te vergelijken om ergens te komen, die gaat brokken maken. En gelukkig doet O dat dus ook niet zo

Nogmaals: een XTE en een DTS op basis van of je links of rechts van de lijn zit.
De code weet dat ook, die vult de DTS in de RMB afhankelijk van waar je zit tov de lijn (alleen doet de code dat precies verkeerd om).

ALs je wilt weten of je koers bij het waypoint uitkomt moet je COG en BTW vergelijken (dat doet SPD, by the way. Kun je op een meter krijgen als je wilt).
Maar dat zit allemaal niet in een RMB.

De link die je post over hoe OpenCPN omgaat met beschrijft dit alles niet.
En dat OCPN BTW en COG vergelijkt en daarmee de L of R vult.... affijn, de code vertelt heel wat anders.
Daar komen BTW en COG niet voor in het kiezen van L of R.
Zou ook in strijd zijn met de definities van een RMB.
En die RMB moet kloppen, de AP gebruikt hem.....

Dat zeg je nou wel zo stellig, maar in mijn kopie definitie van nmea staat bi RMb "Direction to Steer, Left or Right" In het voorbeeld van Holtere zit je links van de koerslijn, maar je gaat al naar rechts. Teveel naar rechts zelfs voor een koers naar het waypoint.
Voorzover ik weet kijkt je AP alleen naar veld 11 van de RMB de "Bearing to destination in degrees True"
Ik durf nog vol te houden dat het wel goed is wat O doet, (Voorlopig, maar ik laat me graag overtuigen)

Als je parallel gaat varen houd je hetzelfde beeld.
Zelfs als je er vanaf stuurt
Verder: De cross track error houd je bij de eerder gekozen (veilige)route.
Stel je voor dat je zomaar op een waypoint gaat sturen op het wad, stroming en drift negerend.
Als de stroming of drift te sterk is en je waaiert te ver van je uitgezette routelijn af dan stopt je stuurautomaat ook met een alarm erbij. Dat is niet voor niets!

Ook nog:
Als je een actieve route hebt en je zegt je stuurautomaat die route te volgen dan draait die bruusk richting route om dan weer bij te sturen. Is de afstand te groot, dan krijg je een foutmelding! Alles draait om die routelijn.

Zo is dat holtere!
Zou een mooie boel worden als de navigatie pc zelf gaat besluiten wat de route wordt.
Bovendien, de code van O is duidelijk.
Geen sprake van COG en BTW bij het kiezen van de DTS.

Ik heb me altijd verwondert waarom mijn stuurautomaat eerst maar eens de verkeerde kant op gaat sturen in gps mode en een route uit opencpn.
Holtere dank dat je dit gezien en gemeld hebt.
Uit de gebruiksaanwijzing van mijn AP. Het eerste wat de automaat gaat doen als je hem aan zet is de XTE minimaliseren.





Als ik weer vaar zal ik ook eens kijken wat mijn RM C120 er van bakt.

3Noreen schreef :
Grappig he. Gelukkig merkt de AP dat de XTE groter wordt als je naar OpenCPN luistert, en dan gaat hij zelf iets slimmers doen

Het wordt een duivels dilemma voor de Open Sores boys van OpenCPN.
Er is een softwarefout gevonden die de boot de verkeerde kant op stuurt.
Niet zomaar een boot, maar elke boot die met OpenCPN de AP aanstuurt.
Veel mensen zullen het nooit gemerkt hebben, anderen hebben de + en - draadjes van de AP omgewisseld....

En dan komt de verbeterde release.....
De mensen die het niet merkten merken nog steeds niets....
Maar bij de echte kenners, die de + en - omgedraaid hebben, gaat de boot na de OpenCPN update ineens de verkeerde kant uit.....

Dat schreeuwt om een extra pop-up schermpje:
"Stuurt uw boot de verkeerde kant op, klik hier" ​
(mooi! weer een nieuw feature, zegt de echte nerd dan)

@BK: Je bent mij iets te gretig met het bashen van opencpn, dat komt je geloofwaardigheid niet ten goede.

Nog steeds ben ik een superfan van Opencpn met die Oesenc kaarten


Verder, ik heb dit nooit eerder gezien en gebruik het al vele, vele jaren. Misschien/vermoedelijk is de wijziging wel mee gekomen met een update. Wat Baggah ook al noemde na het uitpluizen van de broncodes?

holtere schreef :
Hoe doet jouw stuurautomaat het met OpenCPN aansturing?

Een goed aangestuurde AP blijft, zeker op de motor, maximaal 0,01 Nm van de rechte lijn (XTE=0.01)
Ik gebruik afwisselend een GPS (Garmin 128) en WinGPS voor de besturing van de AP.
Eigenlijk altijd XTE=0.0

Die wijkt inderdaad geen mm van de koers
Ook niet met stroming of drift of het moet wel heel bont worden, dan zie je soms een getalletje i.p.v. de 0

Knoet schreef :
Ik heb het in de laatste 15 jaar zeker 4 keer geprobeerd (op Windows).
Dus ik geef het af en toe een kans....
Ervaring sinds 1988 met Seaclear, Tsunamis99, OziExplorer, WinGPS 3 als shareware, en WinGPS Navigator en Voyager. Je kunt niet zeggen dat ik het niet (al een tijdje) probeer.
Goedkope kaarten hoef ik niet, dus dat argument vervalt voor mij.

En van die hele rij is OpenCPN de enige die ik tot 4 keer toe vrijwel direct weer weggekieperd heb.
Onlogische menu's en werking, gebruikers-onvriendelijk, ondoorzichtig. Ergernis.
Alle andere programma's heb ik langdurig gebruikt.

holtere schreef :
Hoe kwam je dan op het plaatje in je OP zo ver van de lijn?

Wat ze gedaan hebben is bepaalde code die eerst in de src map stond en in een andere map neergezet (uiteindelijk wel overzichtelijker) en blijkbaar hebben ze als basis daar een andere bron voor gebruikt.

En dat is voor de nmea ontvang en verzend code (waaronder de rmb).

Tot nu toe zet ik de autopilot altijd handmatig op een koers voornamelijk omdat ik dan de combinatie koers met bepaalde zeil stand dan goed genoeg vind. Dus heb ik me nog niet zo verdiept in hoe ik zou willen hoe dit van waypoint naar waypoint zou moeten werken.

baggah schreef :
Als je een functie nooit gebruikt zul je ook nooit ontdekken dat er een fout in zit.

baggah schreef :
Een klassieke regressiefout dus? Kan gebeuren. Maar hoort niet

Van waypoint naar waypoint laten sturen: hoe een AP dat doet zal afhangen van de software in die AP.
In ieder geval zal een nette AP proberen zo dicht mogelijk bij de lijn tussen beide waypoints te blijven (XTE=0.0). En een alarm afgeven als dat niet lukt.

In principe kan dat al op basis van de XTE alleen. In een NMEA183 XTE-bericht zit niets anders dan die waarde. Dan zal de AP die waarde proberen te verminderen.
Het is dan handig als hij weet of hij naar L of R moet sturen. Hoeft ie niet zelf te proberen
In een RMB en nog een paar berichten zit die DTS (direction to steer).

In WinGPS kan je instellen welke berichten je allemaal naar de AP wil sturen. Grote keuze.
In OpenCPN is het denk ik alleen een RMB en XTE om uit te kiezen.
Voor een goede AP is de foute DTS in de RMB van OpenCPN niet rampzalig. Die AP ontdekt snel genoeg dat die DTS niet helpt om de XTE te verkleinen. Maar het helpt niet, en als je het op een display ziet (zoals holtere) wordt het wel verwarrend voor een ouderwetse wetware-stuurman.