Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5

Nuevo piloto automático Nautinect
#31

(11-09-2025, 11:51 AM)gypsylyon escribió:  OK. Gracias pero 250MB la mega todavia se quedan lejos .
Quieres que te ayude  a migrar el código al ESP32?
Te miro que bibliotecas sirven y cuales hay que cambiar con el correspondiente código que las usa.

Muchas placas del esp32 llevan WiFi y Bluetooth incluidos. Las bibliotecas para uso de  la wifi son fáciles de utilizar. No tato para Bluetooth. 
No he mirado a fondo tu proyecto pero veo que trabajan con i2c fundamentalmente. Asi que no necesitas muchos GPIOS.

(11-09-2025, 06:04 PM)gypsylyon escribió:  Sergio,conoces esta página?
https://open-boat-projects.org/en/

Aquí te puedes orientar para saltar a nmea2000

Gypsylyon, te agradezco tu ofrecimiento. Apenas tengo tiempo para dedicarle al proyecto en su arquitectura actual y de momento mi objetivo es terminarlo, con las decisiones ya tomadas para bien o para mal. Por supuesto siéntete libre de adaptarlo o hacerle mejoras en otra arquitectura pero yo no puedo embarcarme en esa singladura.

Saludos
Sergio
Responder
Agradecido por:
#32

(14-09-2025, 05:00 PM)spascual90 escribió:  Hola Tehani,
relativo a tu comentario "Mala idea es poner separados acelerómetro y magnetómetro". Yo me refiero a que Fenix puede funcionar de dos maneras distintas:
IMU interna (prioriza control a precisión en rumbo): Fenix calcula rumbo magnético (en base a los 3 sensores: M, A, G) y monitoriza aceleraciones (A, G). La debilidad es que el rumbo magnético no va a ser tan preciso porque la medida del magnetómetro se ve distorsionada por la electrónica del propio piloto.
IMU externa + interna (prioriza precisión en rumbo frente a control): El rumbo magnético se recibe de una IMU externa (en base a 3 sensores externos: M, A, G) y Fenix sigue monitorizando aceleraciones (A, G). El rumbo magnético lo puede recibir con una frecuencia de 1Hz y extrapolar linealmente el valor entre medias. En términos de control no es lo ideal, pero te lleva al rumbo deseado sin interferencias magnéticas en la lectura del rumbo.

Esto es una solución a las limitaciones del procesador a tener inputs a 10Hz. Si tuviese un procesador más potente no necesitaría la IMU interna, claro está.

El Magnetómetro QMC5883 es el que uso después de vivir una tortura buscando y probando varios.
Se supone que es el sustituto del Rockwell HMC5883 (Pero no es 100% compatible). Tiene una sensibilidad excelente, es rápido y sin mucho ruido. De él extraigo lecturas cada 10mS, y conjuntamente del MPU6050 que me da gyro y acelerómetro. Va montado en la misma PCB GY-87 que los demás sensores:
https://es.aliexpress.com/item/400061948...pt=glo2esp

Bueno, con esto quiero decir que estos tiempos son 100 veces menores que 1 segundo que comentas (Tiempo de muestreo y entrada al filtro Mahony: 10mS). Si usas un magnetómetro más lento (1Hz es excesivamente lento), debes usar igualmente el filtro Mahony, pero poniendo a 0 las tres variables del magnetómetro en cada llamada a la función, que no hay que olvidar que es un filtro de fusión de sensores.
Te aconsejo encarecidamente usar una CPU exclusiva para un gyro externo de 9 ejes y enviar los datos al piloto a través de un bus robusto, que puede ser RS485/422 como se ha dicho por aquí. Con esa solución matas tres pájaros de un tiro: Reducir ruido al alejar sensores de la parte de potencia y otros cables, mejoras posición del sensor en el barco, y aligeras carga de trabajo del procesador principal del piloto.

Insisto que un acelerómetro interno sólo podrá alterar la precisión del magnetómetro externo por no estar sus ejes perfectamente alineados. Ni te cuento si la caja de control está colgando de un mamparo en bañera con la forma del roof...

Si sientes que te duele Gaza, aunque estés a miles de kilómetros, es porque tu corazón está haciendo justo lo que tiene que hacer: sentir.
Responder
Agradecido por:
#33

Interesante el simulador, aunque me sigue faltando la parte física (banco de pruebas) que serviría para comprobar errores de posición del timón cuando el motor esté trabajando en condiciones reales de máxima carga y a la vez, comprobar si toda la parte de potencia aguanta horas en esas condiciones y no se calienta en exceso.
PD: Hace unos días pasé por la nave del oráculo don Antonio Jubilao. Más que nada para chafardear qué tal le iba con su barco. En esas ocasiones solemos hablar también del piloto, y aproveché para pedirle que fuera pensando en un artilugio mecánico con freno para construir ese banco de pruebas. Iremos viendo...

Si sientes que te duele Gaza, aunque estés a miles de kilómetros, es porque tu corazón está haciendo justo lo que tiene que hacer: sentir.
Responder
Agradecido por:
#34

Un análisis que creo que puede ser útil resulta de la revisión de las diferentes generaciones de pilotos de caña y de rueda desde los años 80 hasta la actualidad.
En el caso del fabricante Raymarine, los pilotos anteriores al cambio de milenio incorporaban un fluxgate con cardan mecánico integrado en el propio brazo. Estos son basicamente los Autohelm 800, 1000, ST1000 con sus variantes, y ST2000. Por su parte Simrad también emplea fluxgate de bobinas con cardan mecánico en sus TP22 y 32.

A principios de los 2000, Raymarine pasó a utilizar los sensores de estado sólido de 9 ejes en una cápsula similar a un platillo volante en sus pilotos ev100, separada del piloto de caña y de rueda, comunicándose a través del bus nmea2000
Simrad sigue fabricando los mismos TP22/32 con fluxgate.

De esto qué puede deducir?
Mi opinión es que el fluxgate es mucho menos preciso que el sensor de 9 ejes EV-1, pero a su vez es más robusto ante perturbaciones, y de construcción más costosa.
Para minimizar las perturbaciones y para mejorar la respuesta se instala separado del piloto, aunque estemos considerendo los pilotos más "económicos" de la familia Raymarine.

Si sientes que te duele Gaza, aunque estés a miles de kilómetros, es porque tu corazón está haciendo justo lo que tiene que hacer: sentir.
Responder
Agradecido por:
#35

(14-09-2025, 05:23 PM)spascual90 escribió:  Y el simulador que he desarrollado se trata de un programa que corre en el PC y que trabaja con Fenix en modo "IMU externa".
El programa incorpora lógica de la dinámica de un barco con las fuerzas que influyen en su velocidad y rumbo, principalmente potencia de motor, pala de timón, resistencia a la rotación, viento sobre las velas y olas. Es un modelo muy sencillo que se puede ir haciendo más complejo según las necesidades.

La secuencia de inicio de un test de virada sería,
SIM a Fenix: Comando de entrar a modo Automático
SIM a Fenix: Comando de virar 100 a estribor

Cada segundo,
Fenix a SIM: Posición de timón, contribución KP, KI, KD
SIM a Fenix: Rumbo actual

En la secuencia de test se definen las condiciones de inicio y final:
Inicio: Iniciar test cuando se produzca un cambio de rumbo mayor de 2 grados
Fin: Parar test cuando el rumbo se mantenga estable más de 5 segundos

Durante la ejecución puedes ver, no solo el rumbo, sino también la evolución del timón comparado con los inputs del PID lo que te permite ver qué contribución (P, I , D) está influyendo en cada momento en la posición del timón. Adjunto pantallazo de ejemplo.

Y al final del test el programa proporciona una serie de métricas de rendimiento que te permiten comparar con otras simulaciones, por ejemplo cambiando la lógica de control PID o simplemente cambiando el valor de los parámetros KP, KI, KD.

Las salidas del test son de este estilo,

*** Start Simulation ***
Empieza test
Test: Virar a estribor 100º
$PEMC,00*37 (Comando de entrar a modo Automático)
$PEMC,02,S*4A (Comando de virar 100 a estribor)

¡Rumbo ha salido del equilibrio! Comenzando supervisión...
¡Rumbo estable durante 5.0 segundos tras haber salido del equilibrio! Parando simulación.

Métricas de rendimiento acumuladas:
Total time(seg): 98.8810
Initial error: 89.1522
ITAE: 68471.2074
IAE: 2232.7596
ISE: 92787.2681
Control_Effort: 5004.3847
Error_Integral: -407.0631

Para ajustar las ganacias Kp,Ki,Kd te aconsejo que uses  el Método de Ziegler–Nichols. Con este metodo puedes calcular Ki y Kd a partir de Kp. Aunque supongo que ya lo conoceras.
https://en.wikipedia.org/wiki/Ziegler%E2...ols_method

Aqui esta la tabla PID para calcular Ki y Kd una vez que has obtenido Ku que es el valor critico o de oscilacion del sistema de Kp. Utiliza la linea "classic PID"
Responder
Agradecido por:
#36

(14-09-2025, 08:47 PM)Tehani escribió:  Un análisis que creo que puede ser útil resulta de la revisión de las diferentes generaciones de pilotos de caña y de rueda desde los años 80 hasta la actualidad.
En el caso del fabricante Raymarine, los pilotos anteriores al cambio de milenio incorporaban un fluxgate con cardan mecánico integrado en el propio brazo. Estos son basicamente los Raytheon 800, 1000, ST1000 con sus variantes, y ST2000. Por su parte Simrad también emplea fluxgate de bobinas con cardan mecánico en sus TP22 y 32.

A principios de los 2000, Raymarine pasó a utilizar los sensores de estado sólido de 9 ejes en una cápsula similar a un platillo volante en sus pilotos ev100, separada del piloto de caña y de rueda, comunicándose a través del bus nmea2000
Simrad sigue fabricando los mismos TP22/32 con fluxgate.

De esto qué puede deducir?
Mi opinión es que el fluxgate es mucho menos preciso que el sensor de 9 ejes EV-1, pero a su vez es más robusto ante perturbaciones, y de construcción más costosa.
Para minimizar las perturbaciones y para mejorar la respuesta se instala separado del piloto, aunque estemos considerendo los pilotos más "económicos" de la familia Raymarine.

Si, pero tu ya lo has comentado en otros post, de la dificultad  y de la importancia de calibrar los sensores de de 9 ejes, para evitar un fallo constante y acumulativo que surgiria de una falta de calibracion.
Por otra parte respecto a lo que ha comentado Sergio de dejar el sensor interno y añadir uno externo, el problema que veo es a cual de los dos haces caso?
Los cálculos trigonométricas de los diferentes ejes y resultante consumen bastantes recursos del microprocesador. Sin embargo la propuesta de tehani de dedicar un microprocesado sólo para el sensor( llamémoslo gyrosensor) es la mejor opción e incluso se le puede añadir el receptor GPS.
Este módulo dr gyrosensor y GPS lo conectaría con la "central" por bus rs485  mejor que por nmea183  o nmea2000.  Porqué?  Si utilizamos nmea183  o nmea2000  hay que incluir nuevas bibliotecas que ocupan mucho sitio. Las sentencias son mucho mas grandes que enviarlas por un propio  protocolo rs485 limitando la velocidad de procesamiento
Responder
Agradecido por:
#37

(14-09-2025, 05:30 PM)spascual90 escribió:  Gypsylyon, te agradezco tu ofrecimiento. Apenas tengo tiempo para dedicarle al proyecto en su arquitectura actual y de momento mi objetivo es terminarlo, con las decisiones ya tomadas para bien o para mal. Por supuesto siéntete libre de adaptarlo o hacerle mejoras en otra arquitectura pero yo no puedo embarcarme en esa singladura.

Saludos
Sergio

Te he mandado un privado.
Responder
Agradecido por:


Posibles temas similares…
Tema / Autor Respuestas Vistas Último mensaje

Salto de foro:


Usuarios navegando en este tema: 1 invitado(s)