[Luis_pm]

Confirmado, el piloto funciona sin ningún problema 

[gypsylyon]

En hora buena.  Me alegro.

[Tehani]

¿Qué os parece si hablamos de XTE, BRG (O BTW) y el procesado que hacen los pilotos con estos datos?.
Como estoy liado con el modo TRACK/NAV del mi piloto, he leído y analizado un hilo en Cruisers Forum donde se debatió sobre este tema:
https://www.cruisersforum.com/forums/f13...96347.html

Documentación de OpenCPN:
https://opencpn.org/wiki/dokuwiki/doku.p..._autopilot

Estoy intentando combinar XTE y BTW para que el usuario no sufra sobresaltos...

[Tehani]

Como ya se comentó, el XTE es el error transversal de ruta, es decir, la distancia a izquierda o derecha que nos separa de la línea establecida desde el punto inicial hasta el siguiente punto o waypoint de una ruta, o entre dos puntos de esa ruta.
Luego, esa ruta puede estar compuesta por varios waypoints, que el navegador debe seguir hasta el punto de llegada final.
Cada tramo establecido entre dos waypoints será dibujado en el plotter (OpenCPN) como un segmento o línea a seguir. En inglés se llama "leg".
Los puristas del tema, que normalmente son los que vavegan en fiordos, ríos o caños, son muy estrictos con el XTE, y exigen que su piloto no se desvíe de esas líneas lo más mínimo.

[Tehani]

Y aquí vienen los problemas.
Si hay que reducir ese XTE siempre al mínimo posible (escasos metros), el piloto puede hacer barbaridades si no andamos con cuidado.
Por lo general, debemos activar la ruta en el plotter una vez salidos de puerto o resguardo. E inmediatamente, activar el modo TRACK en el piloto. Esa es la manera de no tener sustos porque el XTE al activar el TRACK será pequeño y el AP no virará bruscamente para buscar la línea. (AP = AutoPiloto, de ahora en adelante).

[Martin Iut]

Yo por costumbre, antes de activar el modo track, hago un reset del xte. Pero claro, lo tiene que permitir la ruta a seguir.
Nunca lo he usado en entradas o sitios estrechos... Por esto que dices de las burradas...

[Tehani]

Pero hay mucho más.
La mayoría de AP solicitan una confirmación por parte del usuario cuando detectan que el navegador o plotter ha cambiado de segmento (cambio en coordenadas de destino, o cambio brusco del ángulo hacia el destino (BRG o BTW, que es lo mismo).
BRG: Bearing a secas.
BTW: Bearing To Waypoint (un poco más claro).
En esas situaciones, el AP no cambia de rumbo hasta que el usuario da su visto bueno, y esto se hace porque un cambio de rumbo es peligroso si hay otros barcos cerca.
Claro, cuanto más tiempo tardemos en aceptar el cambio, más nos habremos salido de la ruta, pero también resulta que el navegador puede haber cambiado de segmento no sobre el waypoint, sino a una distancia antes de llegar a él.
Aquí paro de momento, y me pongo a escuchar...

[Tehani]

Yo por costumbre, antes de activar el modo track, hago un reset del xte. Pero claro, lo tiene que permitir la ruta a seguir.
Nunca lo he usado en entradas o sitios estrechos... Por esto que dices de las burradas...

Lo que llamamos "Zero XTE" se hace siempre de forma automática en el primer tramo. Y es lógico, puesto que el punto inicial es la posición del barco cuando activamos la navegación en el plotter.
Luego es posible resetear el XTE para evitar que el AP haga viradas bruscas si nos hemos salido de la ruta al desactivar temporalmente el piloto o haber esquivado un obstáculo (boya u otro barco).

[Tehani]

Todo esto tiene implicaciones y limitaciones según usemos un protocolo u otro de comunicación (buses N2k, Seatalk o NMEA0183) entre plotter y AP.
También depende de los datos que use nuestro piloto. Algunos sólo manejan XTE y distancia al WPT, otros además BTW, y los más completos, también supervisan coordenadas de los waypoints.
Una de las cosas que me han pasado por la cabeza ha sido que el piloto sólo tomara coordenadas de los waypoints, y que tanto XTE, como BTW y distancia la calculara él, en lugar de tomar lo que le envía el navegador.
Como sabéis, esos datos se pueden calcular según Mercator o usando la ortodrómica (geometría esférica de círculo máximo).
Os informo que OpenCPN dibuja la ortodrómica cuando marcamos o medimos distancias, pero luego tanto las sentencias RMB como APB usan proyección Mercator.

[Tehani]

Si estáis dispuestos y con ganas de analizar este asunto a fondo, os describiré mi propuesta que ya tengo codificada en el STE300.
La cosa no es trivial. ,(Quien avisa no es traidor...).

[Tehani]

Para empezar, os describo una reacción que tenía mi AP cuando pulsaba +10/-10 mientras navegaba en modo TRACK. Incluso pulsando repetidamente esas teclas.
A mí me gustaba lo que hacía, sin tener que salir de ese modo para salvar un obstáculo.
Los AP de Simrad requieren que el usuario salga del modo NAV para realizar un "dodge" (salvar un obstáculo).
El antiguo AP de Ray corregía su rumbo según los grados marcados por el usuario, y luego, progresivamente iba a buscar la línea de "Zero XTE". No lo hacía buscamente sino que lo hacía a lo largo de unos minutos.
A pesar de eso, también daba sustos al activar el modo TRACK cuando el XTE era grande.

[Tehani]

Otros usuarios también cambiamos el punto de destino en el plotter "sobre la marcha,", sin salir del modo TRACK del piloto.
Esto para que no nos pite constantemente al llegar a un waypoint marcado de forma temporal ("navegar hasta aquí" en OpenCPN, por ejemplo).
Ya sé, esto puede ser un vicio que tenía, pero me iba bien para salvar con precisión los bajos, y además me hacía pasar el rato entretenido...
En estos casos, las coordenadas de destino van cambiando, pero el BRG suele variar muy pocos grados, entonces es necesario que también en este caso el AP exija al usuario que confirme el pequeño cambio de rumbo? Mi piloto no lo hacía.
Hala!. Ya tenéis tema para jugar y poner a prueba vuestro AP!.
Y me gustaría un montón que aportárais vuestras experiencias.
PD: A todo esto, los cambios de rumbo suponen que el barco adquiera una velocidad de rotación que puede estar limitada bien por la inercia de la masa de la embarcación, bien por la velocidad máxima introducida en el setup de usuario...
En ningún caso se puede sobrepasar ese valor, pero tampoco quedarnos lejos porque las maniobras serían lentíiiiiiiiisimas.
Este es uno de los puntos que los AP actuales "aprenden": la facilidad con que un barco maniobra en los cambios de rumbo, dando más o menos ángulo de timón antes de leer la respuesta en forma de velocidad de rotación.

[Tehani]

Bueno, una propuesta para que el AP solicite confirmación o no para los cambios de rumbo:
En el setup:
1- Solicitar siempre (coñazo).
2- Solicitar para cambios de rumbo mayores de X grados (5 a 10).
3- Sólo cuando se detectan blancos AIS con los cuales se reduzca el CPA al virar.
4- Sólo cuando no se detecten otros objetos (blancos AIS o MARPA de radar) a menos de X millas.
5- No solicitar nunca (peligrosillo).

[gypsylyon]

Eso se puede dejar al usuario.
De todas maneras pienso que el cambio de rumbo automático donde más peligroso puede ser es yendo a vela. Por lo demás ir con el AP es igual de peligroso que virar yendo a motor, ya que el AP no ve si hay obstáculos.
Tu propuesta con lis AIS me parece excelente. Se puede usar también durante la trayectoria al WP o incluso que el AP haga una maniobra para evitar la colisión.

Así que resumiendo solo yendo a vela veo la necesidad de esperar la respuesta de usuario

[jiauka]

Yo hace muchos años que no uso la función track de los AP, demasiados sustos y cambios bruscos.

Además, casi siempre voy a vela y ahí es prácticamente inútil.

En motoras creo que debería ser todo auto, excepto si por cualquier razón se sale de la "autopista" XTE, y por supuesto debe permitir corregir manualmente sin salir del modo NAV para esquivar obstáculos. Como volver al modo auto/nav después de 1 obstáculo?. Quizás por tiempo sin pulsar nada (3 minutos?) y entonces recalcular "autopista"/XTE el propio piloto. Es 1 opinión, quizás sería bueno mirar como funcionan los pilotos de mercantes/etc..