He repasado la web de fenix y resulta que ya la conocí desde el principio, pero ni me acordaba ya.
También he seguido el hilo que tienen en Cruisers Forum y me he dado una vuelta por los listados del software que tienen colgado en Github.
Total, que he enviado un privado a Sergio a través de la web de Cruisers para ver si contactamos y charlamos un rato.
Yo os contaré si hay novedades.

(05-09-2025, 04:33 PM)Tehani escribió:  La documentación tiene buena pinta. También lo ví hace un par de años, lo analizaré más a fondo para ver avances.
Pero tu enlace no funciona.
Prueba este:
https://fenix-autopilot.com/system-specification/

Google traduttore fa brutti scherzi, ho corretto il link. (Google Translate is acting up, I fixed the link.)

Google Translate está funcionando mal, arreglé el enlace.

(05-09-2025, 09:40 PM)Tehani escribió:  He repasado la web de fenix y resulta que ya la conocí desde el principio, pero ni me acordaba ya.
También he seguido el hilo que tienen en Cruisers Forum y me he dado una vuelta por los listados del software que tienen colgado en Github.
Total, que he enviado un privado a Sergio a través de la web de Cruisers para ver si contactamos y charlamos un rato.
Yo os contaré si hay novedades.

Por motivos de salud y edad, me vi obligado a vender mi barco. Ahora, para no quedarme de brazos cruzados (como me recomendaron los médicos), me he estado divirtiendo, como aficionado e incompetente, duplicando algunos proyectos de bricolaje. Con gusto habría comprado tu REM y también tu Pylot. Sigo el progreso. Tengo un par de placas Fenix avanzadas; si a alguien le interesa, se las envío gratis. Además de una placa para el Pypilot canadiense de Sean. Por cierto, el PCNautic es una copia mejorada del Pypilot de Sean. ¡Mucha suerte y siempre vientos favorables!

(For health reasons and age, I was forced to sell my boat. Now, to avoid sitting idle (as recommended by the doctors), I've been having fun, as an amateur and incompetent person, duplicating some DIY projects. I would have gladly purchased your REM and your Pylot as well. I'm still following the progress. I have a couple of advanced Fenix boards; if anyone is interested, I'll send them free of charge. As well as a board for Canadian Sean's Pypilot. By the way, the PCNautic is a spruced-up copy of Sean's Pypilot. Good luck, and fair winds, always!)

(05-09-2025, 03:59 PM)Tehani escribió:  Ví una vez el PCnautic, pero ya no me acuerdo de sus características. Tendría que volver a analizar. Si estás interesado, y dependiendo de tu programa de avegación, mira si te interesa que funcione en modo viento y track. También interesa su conectividad con otros equipos (nmea0183, nmea2000...).

Sin exagerar, conozco el Ev100 casi como si lo hubiera hecho yo.
Cuando desarrollé la parte de control de los pilotos evolution con Ocenav, lo hice usando un piloto Ev100 de caña. (nmea2000, SeatalkNG). De eso ya hace unos nueve años...

PD: Tengo cuatro prototipos hechos de mi piloto STE300 y estoy interesado en hacer pruebas reales en navegación durante este invierno. Lo digo por si alguien por aquí cerca de Cartagena se ofrece. Necesito que el barco ya tenga una unidad de potencia, sea hidráulica, de rueda o de caña interior o exterior.

Gracias, Tehani. Es un 26 pies y el programa es navegacíon por Galicia y Cantábrico. Mi barco tiene la electrónica básica y busco algo lo más simple posible que pueda hacer modo viento y track. Tengo muchas cosas que hacerle pero el piloto Plastimo ya no funciona bien (aunque ahora lo uso, qué remedio) y para gastar el dinero dos veces, primero un sustituto y luego algo más modular, prefiero esperar.

La parte más delicada y difícil de poner a punto en un piloto es el girocompás. Si no se calibra bien dará errores de rumbo y el piloto hará cosas raras.
La forma como los de fenix proponen para que el propio usuario calibre el gyro me parece bastante problemática. Barata pero con resultados impredecibles. Este dispositivo debería calibrarse en fábrica bajo condiciones libres de perturbaciones electromagnéticas. Me ha hecho gracia ver que usan el mismo algoritmo Mahoni de fusión para 9 ejes que uso yo en mi Gyro. No obstante pienso que les falta algo de preprocesamiento contra el ruido (no me enrrollo porque aquí hay mucha tela).
https://foronavegantes.net/thread-1010-p...l#pid99017
Como problema añadido estoy viendo que estos pilotos DIY están alojando en el interior de la misma caja la parte de potencia y el gyro. Opino que esto es un error.
Estas cuestiones se las plantearé a Sergio si establecemos contacto, y le propondré alternativas.

He analizado las características del brazo (actuador) que propone y no me parece mal para un barco hasta unas 3,5T aprox, con caña, que iría bien en tu 26'. Pero no puedo saber qué tal soportará el ambiente salino a medio largo plazo.

Contacto establecido.
Hemos hablado un rato sobre detalles del gyro y del plan de vida de cada uno. Seguiremos hablando.
De momento trabaja lejos, pero tiene el barco bastante cerca de donde estoy. Probablemente nos veamos dentro de unos meses.
Mientras voy a ver si termino los últimos cambios de software del piloto STE300, y lo pruebo en carga para ver si se calienta mucho. El gyro está terminado (aunque eso está prohibido decirlo con tanta alegría...).

Buenos días a todos,

soy Sergio, desarrollador del proyecto de piloto automático Fenix. Gracias a Max y a Jose Luis (Tehani) por atraerme hacia este foro. Creo que es el principio de algo grande .

Llevo desarrollando Fenix desde 2017 de manera discontinua, en mis ratos libres.

https://fenix-autopilot.com/
https://spascual90.gitbook.io/fenix-autopilot
https://www.youtube.com/@FenixAutopilot


El objetivo principal del proyecto es, además de entretenerme y aprender,

construir un piloto automático de brazo con buen rendimiento en su gama, con las funcionalidades que realmente se necesitan para un plan de viaje costero, interfaces de comunicación básicas, basado en componentes estándar que permita su fácil integración y con ello lo que se busca es una excelente relación calidad/ precio.

En este sentido, creo que es importante que el proyecto sea realista en sus objetivos para que llegue a buen puerto. Mi objetivo no es hacer un "pata negra" sino el mejor piloto automático dentro de la gama básica. Mi objetivo son esos navegantes que buscan renovar sus "viejos Autohelm ST1000" con un presupuesto limitado buscando mejor rendimiento, un look&feel del interfaz atractivo y bajo coste de mantenimiento. Para aquellos que además tienen ciertos conocimientos de informática/electrónica (que en el mundo náutico haberlos haylos) pueden liarse con la integración con plotter, anemometros o incluso hacer uso de los terminales de sus antiguos pilotos automáticos que ya tienen instalados en la bañera. Ellos pueden beneficiarse de capacidades  de integración NMEA0183 que proporciona Fenix con Openplotter via USB.

Tengo bastantes conocimientos de programación y física, y sólo básicos de electrónica, por ese motivo el proyecto tiene un alto nivel de exigencia en términos de SW donde dedico el 95% del tiempo, y bastante básico en la parte de HW.

En principio no tengo animo de comercializarlo, pero no lo descarto si llego a un producto que cumpla con los estándares de calidad exigibles.

Una vez hechas las presentaciones, y sabiendo que Tehani me lee, paso a desarrollar alguna ideas que se han mencionado y de paso abrir debate,

- ESP32 o Arduino: es indudable que ESP32 tiene mayor capacidad en todos los sentidos. Si empezase el proyecto hoy con lo que sé empezaría con ESP32, pero no es el caso. De momento Arduino me ha permitido centrarme y desarrollar los objetivos del proyecto. Efectivamente si quiero incorporar requisitos más ambiciosos tendré que migrar al ESP32.

- IMU externa o interna: es indudable que externa mejora la calidad de la lectura del magnetómetro, pero no veo el beneficio para el giroscopo y acelerómetro que además requieren alta frecuencia de refresco para anticiparse a los giros no deseados (eg. orzada). Mi propuesta implementada en Fenix es la siguiente, IMU interna con lectura de los 3 sensores y (opcionalmente) capacidad para recibir mensajes heading (HDG) externos que prevalezcan frente a la lectura de magnetómetro interna. Esto requiere no solo leer los mensajes HDG sino también extrapolar el valor de heading hasta la recepción de un nuevo HDG.

- Calibración de fábrica o usuario: De fábrica siempre, lo que pasa es que Fenix está desarrollado como proyecto DIY por lo que el usuario y el fabricante son la misma persona, razón por la cual he desarrollado herramientas y videos ilustrativos del proceso.

- Interfaces de comunicaciones avanzadas o básicas: Fenix sólo implementa NMEA0183 a través de USB lo cual es suficiente para conectarse con Openplotter que además de ser un plotter ofrece infinitas opciones de interconexión con otros dispositivos (sensores y de control) a través de cualquier estándar existente (NMEA2000, Signal K,...). Es decir, las limitaciones de Fenix las mitiga Openplotter.

- HW profesional o amateur/DIY: Estando en juego la seguridad de la embarcación y sus tripulantes, creo que hay que poner todos los medios razonables para evitar que el uso del piloto automático dañe elementos de seguridad como la radio o sobrecalentamiento del propio piloto automático. Actualmente Fenix no implementa las medidas de protección EMI, de inversión de corriente y monitorización del motor suficientes y es un área de mejora.
Por otro lado, creo que para empezar a comercializar, el uso de placas de desarrollo (ie. Arduino Mega + Cytron MD10C) ahorra mucho tiempo de diseño, ensamblaje y fabricación frente a diseñar placas desde cero. El coste por unidad será significativamente mayor, pero por lo menos no tienes que comprar 100 unidades a fondo perdido. 
@Tehani: No sé si existe alguna fuente de alimentación comercial que se pueda utilizar entre Fenix y la batería sin tener de diseñar una ad hoc. Si no existe, la solución intermedia es interesante para pequeñas series de producción: desarrollo de fuente de alimentación ad hoc junto con placas de desarrollo comerciales. ¿Sería posible?

- Prueba de mar o simulador: Vivo lejos del mar y eso hace que desarrolle el piloto con pocas oportunidades de hacer pruebas sobre el barco. Eso me ha animado a desarrollar un simulador de dinámica de barco que me permite validar el rendimiento del piloto ante ciertos escenarios o estímulos que son difíciles de reproducir en la realidad. Mi experiencia es que incluso estando cerca del mar, hay que probar en el simulador, un entorno controlado, cientos de veces hasta encontrar los parámetros que mejor se adaptan, y sólo después hacer la prueba de mar para validad la simulación.

¿Entonces qué le falta a Fenix para cumplir sus objetivos?
- Terminar de desarrollar el controlador PID para anticiparse a los cambios de rumbo no comandados
- Desarrollar una solución HW que proporcione una fuente de alimentación con las protecciones necesarias
- Pruebas y más pruebas en simulador para encontrar los parámetros de control iniciales
- Pruebas y más pruebas en barco para validar que el comportamiento es el esperado

Creo que está bien como introducción y para despertar mentes. El debate está servido.

Un saludo navegantes
Sergio

En hora buena por este impresionante proyecto.
Lo que es increíble esque te entre el código en un arduino nano (ATmega328P) con solo 30KB útiles. También la velocidad de 16MHz del AT mega contra lo 240MHz del núcleo Tensilica LX6 del ESP32.
Desde luego la migración a un esp32 con 4MB mínimo y alguno con 16MB va a merecer la pena.
Tehani trabaja con los STM , pero estos son difíciles de programar con el IDE de Arduino.
Aunque yo pienso que los ESP 32 son muy similares a los STM.
Me alegro por este hilo , seguro que algunos lo vamos a disfrutar

(11-09-2025, 08:34 AM)gypsylyon escribió:  En hora buena por este impresionante proyecto.
Lo que es increíble esque te entre el código en un arduino nano (ATmega328P)  con solo 30KB útiles. También la velocidad de 16MHz del AT mega contra lo 240MHz del núcleo Tensilica LX6 del ESP32.
Desde luego la migración a un esp32 con 4MB mínimo y alguno con 16MB va a merecer la pena.
Tehani trabaja con los STM , pero estos son difíciles de programar con el IDE de Arduino.
Aunque yo pienso que los ESP 32 son muy similares a los STM.
Me alegro por este hilo , seguro que algunos lo vamos a disfrutar

Cuidado que uso un Arduino Mega, no Nano! Jajaja.
Gracias
Sergio

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.

(10-09-2025, 07:39 PM)spascual90 escribió:  - ESP32 o Arduino: es indudable que ESP32 tiene mayor capacidad en todos los sentidos. Si empezase el proyecto hoy con lo que sé empezaría con ESP32, pero no es el caso. De momento Arduino me ha permitido centrarme y desarrollar los objetivos del proyecto. Efectivamente si quiero incorporar requisitos más ambiciosos tendré que migrar al ESP32.

El c++ que usas y las librerías de arduino que también usas, permiten esa migración sin muchos problemas. Vale la pena hacerlo por prestaciones (ESP32 tiene bus CAN para nmea2000, WiFi y bluetooth), precio y soporte de librerías y ejemplos de la comunidad DIY.

- IMU externa o interna: es indudable que externa mejora la calidad de la lectura del magnetómetro, pero no veo el beneficio para el giroscopo y acelerómetro que además requieren alta frecuencia de refresco para anticiparse a los giros no deseados (eg. orzada). Mi propuesta implementada en Fenix es la siguiente, IMU interna con lectura de los 3 sensores y (opcionalmente) capacidad para recibir mensajes heading (HDG) externos que prevalezcan frente a la lectura de magnetómetro interna. Esto requiere no solo leer los mensajes HDG sino también extrapolar el valor de heading hasta la recepción de un nuevo HDG.

Mala idea es poner separados acelerómetro y magnetómetro, ya que el acelerómetro determina la orientación en tres ejes que genera un quaternion de rotación que el filtro Mahoni aplica en el procesado de los datos del magnetómetro. Si ambos sensores no están alineados, el filtro dará errores considerables. (Es casi lo mismo que el cardan mecánico de un fluxgate, pero hecho por software usando el acelerómetro para saber las inclinaciones en tres ejes por gravedad). Solución: Todos sensores en dispositivo aparte con procesador especializado, que es lo que están haciendo los pata negra.
La comunicación entre gyro y piloto se hace en nmea2000 con una tasa de 10 datos (heading, rotation y attitude) por segundo.

- Calibración de fábrica o usuario: De fábrica siempre, lo que pasa es que Fenix está desarrollado como proyecto DIY por lo que el usuario y el fabricante son la misma persona, razón por la cual he desarrollado herramientas y videos ilustrativos del proceso.

Estas cosas no se pueden dejar en manos del usuario. Hacer una buena calibración tanto del acelerómetro como del magnetómetro no es tarea fácil. Si no quieres que te llamen luego a todas horas, mejor presenta un gyro terminado, programado y calibrado.

- Interfaces de comunicaciones avanzadas o básicas: Fenix sólo implementa NMEA0183 a través de USB lo cual es suficiente para conectarse con Openplotter que además de ser un plotter ofrece infinitas opciones de interconexión con otros dispositivos (sensores y de control) a través de cualquier estándar existente (NMEA2000, Signal K,...). Es decir, las limitaciones de Fenix las mitiga Openplotter.

Me parece que sería muy conveniente que el dispositivo fuera más abierto y que no quedara limitado a ser usado con openplotter u OpenCPN. Ya sé que esto es full DIY, pero muchos usuarios tienen electrónicas con nmea2000, y aún quedan bastantes con seatalk1. Yo aprovecharía las librerías NMEA2000 para ESP32, para darle un sentido extra a la migración.

- HW profesional o amateur/DIY: Estando en juego la seguridad de la embarcación y sus tripulantes, creo que hay que poner todos los medios razonables para evitar que el uso del piloto automático dañe elementos de seguridad como la radio o sobrecalentamiento del propio piloto automático. Actualmente Fenix no implementa las medidas de protección EMI, de inversión de corriente y monitorización del motor suficientes y es un área de mejora.
Por otro lado, creo que para empezar a comercializar, el uso de placas de desarrollo (ie. Arduino Mega + Cytron MD10C) ahorra mucho tiempo de diseño, ensamblaje y fabricación frente a diseñar placas desde cero. El coste por unidad será significativamente mayor, pero por lo menos no tienes que comprar 100 unidades a fondo perdido.

Es lógico que pienses así porque no estás muy bregado en hardware. Actualmente es posible que te hagan 5 PCB por nada y menos, y seleccionando el transporte como ePacket, lo tienes en casa por menos de 20€ y en 15días.
Luego sueldas y montas tú los componentes. Un módulo ESP32 puede soldarse fácilmente.
Haz la prueba aquí:
https://cart.jlcpcb.com/quote
Dejas todas las opciones porvdefecto y sólo rellenas en el formulario la cantidad y las dimensiones en mm. No hace falta enviar gerbers para el presupuesto.

@Tehani: No sé si existe alguna fuente de alimentación comercial que se pueda utilizar entre Fenix y la batería sin tener de diseñar una ad hoc. Si no existe, la solución intermedia es interesante para pequeñas series de producción: desarrollo de fuente de alimentación ad hoc junto con placas de desarrollo comerciales. ¿Sería posible?

Esta mañana hemos hablado en privado de eso, y de los filtros EMI que se podrían poner para evitar interferencias. El puente de mosfets para el puente H va directo a 12v (filtro EMI en medio), y para la CPU y control, basta con un regulador miniatura de 0,060€, 1A, 5v y alto rendimiento por ser conmutado. Sustituye pin a pin a los típicos 78xx.

- Prueba de mar o simulador: Vivo lejos del mar y eso hace que desarrolle el piloto con pocas oportunidades de hacer pruebas sobre el barco. Eso me ha animado a desarrollar un simulador de dinámica de barco que me permite validar el rendimiento del piloto ante ciertos escenarios o estímulos que son difíciles de reproducir en la realidad. Mi experiencia es que incluso estando cerca del mar, hay que probar en el simulador, un entorno controlado, cientos de veces hasta encontrar los parámetros que mejor se adaptan, y sólo después hacer la prueba de mar para validad la simulación.

Interesante. Me gustaría que dieras más detalles.

¿Entonces qué le falta a Fenix para cumplir sus objetivos?
- Terminar de desarrollar el controlador PID para anticiparse a los cambios de rumbo no comandados
- Pruebas y más pruebas en simulador para encontrar los parámetros de control iniciales
- Pruebas y más pruebas en barco para validar que el comportamiento es el esperado

Yo también necesito acabar haciendo las pruebas de mar. Lo demás está hecho, e incluso a disposición para modificarlo para adaptar el hardware a tus necesidades.
Pero recuerda lo que te he dicho en privado: cuando vayas añadiendo cosas y trabajo de desarrollo, irás alejándote de la idea de presentarlo como DIY.

Sergio,conoces esta página?
https://open-boat-projects.org/en/

Aquí te puedes orientar para saltar a nmea2000

Para un proyecto que casi he terminado, pero que no tiene nada que ver con la nautica, he desarrollado un protocolo para bus rs485 con checksum, para conectar un Leonardo con varios esp32.
Lo podrías utilizar para externalizar el IMU y acelerometro.
La biblioteca es corta y su uso mas fácil que nmea183 y por supuesto nmea2000. Funciona en halbduplex tipo máster slave.
El imu y acelerometro lo lees con un esp32 (por ejemplo un beetle) y envías la lectura por el bus al ATMega. La biblioteca la he desarrollado que tu puedes desde el ATMEGA solicitar la información del esp32 con el IMU y acelerometro.
Hay una biblioteca de esp32 muy sencilla para leer los datos preprocesados del BN055.
Así que si tienes interés me lo dices.

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á.

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