Enriqueciendo conocimientos con vuestros comentarios, se puede deducir que los sensores de multiples ejes que llevan los pilotos comerciales son parecidos a esas tarjetas IMU que usamos en la Raspberry ?
Y si fuera asi, la diferencia tan grande en precio seria dificil de justificar....
Quizas queda fuera del hilo, pero en los plotter que conozco hecho en falta una pagina con la animacion de un velero con los ejes de movimiento instantaneo como en openplotter.
Y para acabar, supongo que el proyecto de piloto automatico alternativo que iniciasteis hace un tiempo se quedo por el camino. No hay muchas alternativas fiables en el mercado, recuerdo Pypilot y Pelagiic, y cosas DIY con arduinos .
Saludos

(09-12-2022, 11:28 AM)Juan Solis escribió:  Enriqueciendo conocimientos con vuestros comentarios, se puede deducir que los sensores de multiples ejes que llevan los pilotos comerciales son parecidos a esas tarjetas IMU que usamos en la Raspberry ? 
Y si fuera asi, la diferencia tan grande en precio seria dificil de justificar....
Quizas queda fuera del hilo, pero en los plotter que conozco hecho en falta una pagina con la animacion de un velero con los ejes de movimiento instantaneo como en openplotter.
Y para acabar, supongo que el proyecto de piloto automatico alternativo que iniciasteis hace un tiempo se quedo por el camino. No hay muchas alternativas fiables en el mercado, recuerdo Pypilot y Pelagiic, y cosas DIY con arduinos .
Saludos

Creo que los IMU que se usan para la raspi son los MPU9255. Éstos no tienen una CPU integrada, son más baratos, pero el filtro Kalman debe ejecutarlo el procesador principal de la raspi. (es una carga apreciable).
Hay varios fabricantes y calidades muy distintas de estos sensores. Y su precio también difiere bastante.
No hace mucho, intenté abrir un ACU100 de Raymarine (el platillo en cuestión), pero no encontré la manera de hacerlo sin romper la caja. Así que sigo sin saber qué sensores usan.

Por otra parte, creo que, aunque el precio del sensor esté en 50-60€ o menos, hay que calibrarlo en fábrica para mejorar el tiempo de respuesta en el arranque, luego hay que añadir un uC que pase del I2c o SPI (buses de comunicación con estos sensores), a NMEA2000, con su protocolo ISO, certificaciones e historias varias.

Añade la placa de circuito, caja externa con su molde de inyección, montaje de componentes, conectores, desarrollo de software, etiquetas, manuales, márgenes de distribución, etc.
Nada de eso sale barato.

En cuanto al piloto STE300 de Ocenav:
Si quiero comercializarlo, tengo que hacer aún pruebas intensivas navegando, pasar certificaciones y fabricar una tirada mínima de 100 unidades. De momento veo mucho riesgo si me lanzo a hacerlo.

En cuanto al MPU9250 o 9255:
Hace unos años, antes de encontrar el BNO055 adapté los filtros Mahony, Madgwick y Kalman al procesador del ATM105 usando el MPU9255.
Comparé estos tres filtros, peeeerooo:
Después de bastantes cientos de horas de trabajo, tuve que sucumbir. Ese IMU, aunque el fabricante sostenía que podía comunicarse por SPI con el procesador principal, en realidad tenía un defecto porque ese chip tiene incrustado un magnetómetro de otro fabricante y, entre ellos se comunican por I2c. (Es un rollo muy largo de explicar, y que seguro no le interesa a nadie...).

Fue imposible la comunicación con SPI, y el I2c es un bus muy exigente que requiere gran atención de la CPU principal.
Total, que prácticamente se necesita un procesador dedicado al sensor, que eso es lo que hacen Raymarine y los demas.

Bien, voy a documentar un poco algo referente a los cacharrillos que ayer me trajo Juan Solís.
Trajo 3 cajas llenas de cosas:
- Una con 2 plotters Garmin 723, uno de ellos, hecho polvo, al cual hay que soldar unos conectores para los tres cables planos (ZIF) del display, que él compró como recambio.
Inexplicablemente, esos 3 conectores estaban desoldados de la placa y desaparecidos. He engordado la cesta de compras de Aliexpress. Son baratillos, pero hay que llevar especial cuidado, porque dos de ellos van con los contactos abajo (lado pcb), y el otro va con los contactos arriba.
Cuando lleguen, veremos qué tal...

También trajo uno de esos conversores de señales analógicas a N2k.
Imposible ver lo de dentro porque está dentro de un bloque de resina. (Ya me parecía que el chisme pesaba mucho...).
También trajo un sensor de timón, pero con sólo 2 salidas, no hay acceso a los 3 terminales, o sea, mal asunto...
Según el manual de un Reactor de Garmin para barazos mecánicos, el sensor de timón tiene que ser con tres salidas. Las de un pote normal y corriente.

Y ahora, para mi gusto, viene lo más interesante:
El / los pilotos Garmin Reactor, y algunas de sus diferencias.
Me trajo un conjunto formado por un GHP Reactor (el cerebrito con sensores AHRS), una ECU GHP 10, y un display GHC 20, y algunos conectores y cables (no todos).
En principio, me dijo que la unidad ECU GHP 10 tenía los Mosfets fritos. Bueno, haciéndole caso, he vuelto a engordar la lista con un paquete de 10 IRFB3306, que soportan 160 amperios de pico, casi ná... En realidad, lo que importa de esos mosfet es que tienen una resistencia de conducción muy baja: 3,3 miliohmios. Eso va bien para tensiones de alimentación bajas: 12 - 24v.

Aquí vienen los peros:
Antes de desoldar y comprobar los Mosfets, se me ha ocurrido montar la instalación con todo, incluyendo N2k y el motor de limpiaparabrisas que tengo para las pruebas del piloto de Ocenav.
1a cosa que "olía mal": En el ECU GHP10, tanto el conector de alimentación como el que lo comunica con el CCU (computador de rumbo) son diferentes. Entran, pero el cierre es por bayoneta en el ECU, y los de los cables son roscados.
2a cosa: No había comunicación entre el ECU y la CCU. Entre esas dos unidades hay un bus CAN "especial", independiente de NMEA2000.
Mirando con analizador lógico, veo que sólo "habla" la unidad ECU, no hay intercambio con la CCU. He desmontado también la CCU y he seguido las señales a través de los interfaces hasta las mismísimas CPU. Nada, lo dicho. Sólo habla la ECU.
3a cuestión: Pelea intensa para buscar manuales de cada componente y no existen. Sólo hay de los packs, viendo que el ACU en cuestión no concuerda con la CCU del manual, que es cilíndrica...

Conclusión: No es compatible este conjunto de ACU y CCU. Esta ACU (Mosfets) concuerda con un piloto ya obsoleto que era para motoras con gobierno exclusivamente hidráulico. El manual se encuentra como GHP 10.
Buscando más manuales, veo que los Reactor 40 se fabrican con dos opciones: Hidráulica y electromecánica. Parece que la CCU sirve para ambas.
Es un verdadero lío el tema de referencias Garmin, y lo indocumentadas que están.
Reactor a secas, Reactor 40, GHP 10, GHP 12, y sus conjuntos y versiones, porque incluso se ha cambiado la forma de la caja en los ACU.
Pero atando cabos, actualmente hay dos versiones principales, con variantes en la CCU que aceptan motores Yamaha, Volvo y alguno más. Esta ACU, actualmente se llama GHP12, y ha cambiado de forma, tal como he comentado antes.
Las versiones en los ACU hacen referencia al control de unidades hidráulicas, electromecánicas o de electroválvulas.
Como Juan estaba interesado en poner una unidad electromecánica de Raymarine tipo 1, he rebuscado más y:
Es curioso cómo se expresa el manual para las unidades electromecánicas: "Connecting to an existing Drive Unit". Supongo que no quieren decir abiertamente que se pueden conectar a un brazo Raymarine, y dan las conexiones para el motor y para el embrague.
También es curioso cómo evitan mencionar los sensores de timón de B&G. Sólo dicen que son compatibles los de potenciómetro con 3 contactos y no son compatibles los que dan salida de frecuencia (estos últimos son los de B&G).

Lamentablemente, no puedo realizar capturas de los mensajes nmea2000 entre el display GHC20 y el GHP reactor, porque como no se detecta la unidad ACU, da error.
Pero bueno, como ya tenía todo panza arriba y abierto en canal, me he dedicado a explorar la "intimidades" de estos Garmin.
Ahora viene lo más técnico, y para mi gusto, lo más interesante.
Primera cosa: Me ha sorprendido mucho el procesador tan justito de la unidad "ACU" (la de los mosfets). Es un Atmel bastante antiguo de 8 bits con sólo 2k de RAM y a una frecuencia irrisoria. Eso sí, tiene bus CAN. Increíble... pero no tanto, porque eso empieza a mostrar un cambio importante respecto a otras marcas.
Para los forofos de la Raspberry: Sí, señor@s, la CCU (Unidad de rumbo) lleva un sensor AHRS MPU9150, que es la versión más antigua y simple del MPU9255.
Este sensor no está provisto de CPU para ejecutar el filtro Kalman.
Pues nada, que en la placa hay dos microcontroladores bastante potentillos, uno conectado al sensor (STM32F373) por I2c, y comunicado por bus serie asíncrono (USART) con la otra CPU (STM32F405).
Bueno, y qué?
He realizado capturas con analizador lógico con resultados que llevan a conclusiones sorprendentes:
La ACU es un bicho bastante bastante tonto. Viene a ser equivalente a lo que hace el arduino del piloto Pypilot de Sean Depargnier.
La CCU es el verdadero cerebro, y recoge datos del IMU de 9 ejes "CADA 10 mS", o sea, 100 veces por segundo.
Digo, bueno, eso es la entrada del filtro Kalman del F373, vamos a ver los datos digeridos que envía el F373 al procesador principal: "LA MISMA TASA: 100 veces por segundo", y a una velocidad de bus de 115200 baudios. Toda leshe...
Os recuerdo aquí que en NMEA2000, el heading, viento, y coordenadas se envían 10 veces por segundo. Este chisme está calculando rumbo 10 VECES MÁS RÁPIDO!!!

Y aquí viene una conclusión: Al tener el sensor más cerca del computador de rumbo, y sin NMEA2000 por medio con cosas de AIS y porquerías varias; este piloto puede ser mucho más preciso y fiable que las familias Raymarine, Simrad y B&G (no pongo la mano en el fuego porque hay más factores como la pericia de los programadores).
Si os fijáis en las instalaciones de los pilotos Ray, Simrad y B&G, veréis que tanto la ACU, como el CCU y display están conectados al mismo bus NMEA2000 compartido por todos los demás componentes (sensores, AIS, GPS, motores y porras varias).
Desde luego, la solución Garmin es más fiable y rápida para los datos vitales, de la misma manera que hacían los antiguos pilotos de Robertson.

Sabia que lo dejaba en buenas manos. He independientemente de que no se pueda arreglar, me alegra que pueda servir para mejorar ,aun mas, los productos de Ocenav.
Ojala sirva para dar un empujon a ese proyecto de control de piloto automatico que tienes en desarrollo. Quizas algun tipo de Crowfounding o compra conjunta de unos cuantos interesados, pudiera dar el ultimo empujon a que se materialice.
Me apunto primero en la lista

Ahora viene la moraleja, que es una dedicatoria para los forofos de la Raspberry y Pypilot (es decir, Pinguino, Saillog, Jiauka, Gypsylyon, y tantos otros):
No es posible que una Raspberry comunique a esa tasa de 100 Hz, habiendo procesado el filtro Kalman y comunicado con el sensor MPU9255 por I2c. Eso además de cargar con el sistema operativo, Python, OpenCPN, plugins de SignalK, Openplotter con mogollón de conexiones de red, etc, etc, etc, etc...
Me troncho con el plugin de comunicación Seatalk con GPIO.
Alguien dirá que el procesador de la raspy es muy potente. Y sí, lo es, pero todo tiene un límite. Máxime cuando estamos hablando que la raspy funciona con un sistema operativo multitarea. Los tiempos de comunicación con el sensor y entregando datos del filtro Kalman son muy precisos: cada 10 milisegundos. Eso es simplemente imposible con la forma de programar la raspberry. El estilo de los programadores de este entorno NO ES NADA EFICIENTE.

(18-12-2022, 07:48 PM)Juan Solis escribió:  Sabia que lo dejaba en buenas manos. He independientemente de que no se pueda arreglar, me alegra que pueda servir para mejorar ,aun mas, los productos de Ocenav.
Ojala sirva para dar un empujon a ese proyecto de control de piloto automatico que tienes en desarrollo. Quizas algun tipo de  Crowfounding  o  compra conjunta de unos cuantos interesados, pudiera dar el ultimo empujon a que se materialice.
Me apunto primero en la lista

Juan, lo que me pedías acerca de que el plotter Garmin sirviera de botonera para controlar otro piloto, lo veo difícil difícil anque sea el STE300.
Hay demasiadas combinaciones posibles, y además, todos los dispositivos en la red NMEA2000 deben identificarse por código de fabricante y producto, y también usan un montón de PGN propietarios (un montón de cada padre y madre).
Sencillamente, no quiero volverme más loco de lo que estoy. Me conformo con mi situación mental actual.
Pero gracias de todos modos.

(18-12-2022, 07:51 PM)Tehani escribió:  Ahora viene la moraleja, que es una dedicatoria para los forofos de la Raspberry y Pypilot (es decir, Pinguino, Saillog, Jiauka, Gypsylyon, y tantos otros):
No es posible que una Raspberry comunique a esa tasa de 100 Hz, habiendo procesado el filtro Kalman y comunicado con el sensor MPU9255 por I2c. Eso además de cargar con el sistema operativo, Python, OpenCPN, plugins de SignalK, Openplotter con mogollón de conexiones de red, etc, etc, etc, etc...
Me troncho con el plugin de comunicación Seatalk con GPIO.
Alguien dirá que el procesador de la raspy es muy potente. Y sí, lo es, pero todo tiene un límite. Máxime cuando estamos hablando que la raspy funciona con un sistema operativo multitarea. Los tiempos de comunicación con el sensor y entregando datos del filtro Kalman son muy precisos: cada 10 milisegundos. Eso es simplemente imposible con la forma de programar la raspberry. El estilo de los programadores de este entorno NO ES NADA EFICIENTE.

Programando en  Python si que es difícil llegar a esas velocidades, pero programando en C si se puede.
Ahora he modificado una biblioteca de C para con botones similar el ratón y el teclado.  Quitando que uso un montón de GPIOs de la Raspy,  funciona sin quitarle recursos a la Raspy

(18-12-2022, 07:51 PM)Tehani escribió:  Ahora viene la moraleja, que es una dedicatoria para los forofos de la Raspberry y Pypilot (es decir, Pinguino, Saillog, Jiauka, Gypsylyon, y tantos otros):
No es posible que una Raspberry comunique a esa tasa de 100 Hz, habiendo procesado el filtro Kalman y comunicado con el sensor MPU9255 por I2c. Eso además de cargar con el sistema operativo, Python, OpenCPN, plugins de SignalK, Openplotter con mogollón de conexiones de red, etc, etc, etc, etc...
Me troncho con el plugin de comunicación Seatalk con GPIO.
Alguien dirá que el procesador de la raspy es muy potente. Y sí, lo es, pero todo tiene un límite. Máxime cuando estamos hablando que la raspy funciona con un sistema operativo multitarea. Los tiempos de comunicación con el sensor y entregando datos del filtro Kalman son muy precisos: cada 10 milisegundos. Eso es simplemente imposible con la forma de programar la raspberry. El estilo de los programadores de este entorno NO ES NADA EFICIENTE.

No entiendo tu animadversión a las raspberry, signalk, etc. Son una forma de que desarrolladores "alejados del hardware" interaccionen de una forma fácil con él.

¿Que no son como una solución profesional?
Puede ser, pero pueden ser el germen de otras cosas mejores y/o evolucionar.
Linux empezó como un pasatiempo de un chico de universidad y mira que es ahora.

Ya que comentas sobre las raspberry, usando el medio de comunicación "nativo" de los PC's que es el ethernet, puede manejar sin despeinarse muchísimos más paquetes por segundo de los que necesita un piloto y barco entero, esto es un hecho. 10, 100, 1000 ó 10000 paquetes por segundo no son nada para una raspberry pi en capacidad de procesamiento.

Cada tecnología tiene sus ámbitos y si la sacas de su contexto es fácil encontrar sus vergüenzas.

(19-12-2022, 10:25 AM)josefu escribió:  No entiendo tu animadversión a las raspberry, signalk, etc. Son una forma de que desarrolladores "alejados del hardware" interaccionen de una forma fácil con él.

¿Que no son como una solución profesional?
Puede ser, pero pueden ser el germen de otras cosas mejores y/o evolucionar.
Linux empezó como un pasatiempo de un chico de universidad y mira que es ahora.

Ya que comentas sobre las raspberry, usando el medio de comunicación "nativo" de los PC's que es el ethernet, puede manejar sin despeinarse muchísimos más paquetes por segundo de los que necesita un piloto y barco entero, esto es un hecho. 10, 100, 1000 ó 10000 paquetes por segundo no son nada para una raspberry pi en capacidad de procesamiento.

Cada tecnología tiene sus ámbitos y si la sacas de su contexto es fácil encontrar sus vergüenzas.

Estamos de acuerdo. Cada tecnología tiene su campo de aplicación.
No me malinterpretes, no es animadversión. Simplemente he repasado mucho código de OpenCPN y algunos plugins y no me gusta nada: Duplicidad, estructuras ineficientes, montón de funciones totalmente estúpidas de una sola línea, includes para aburrir, etc, etc.

Sólo digo que bastantes aplicaciones, aunque estén bien desarrolladas, no son apropiadas para la implementación con Raspberry.

Y voy a poner un ejemplo relacionado con el piloto:
Imagina que por una causa externa (perturbación radioeléctrica, fallo de alimentación, etc) se cuelga el procesador y se bloquea o desconecta el piloto sin previo aviso.
Veo muy difícil, por no decir imposible, que una Raspberry que esté haciendo de piloto se recupere en un tiempo razonable (milisegundos), y sea capaz de retomar el control allí donde se colgó.
Haciendo perrerías tanto a los gateways como al piloto STE300, el sistema resetea por un watchdog analógico (fallo de tensión) y otro por timer hardware especializado (ventana temporal), de manera que el sistema sigue funcionando sin que el usuario se haya enterado.
En cuanto a las comunicaciones, sí es verdad de las ráfagas de datos en ethernet tienen un ancho de banda enorme, pero estamos hablando de grandes tramas de datos sin un control temporal estricto. Ya ves, bien diferente de los 16 bytes que envía un procesador a otro en la misma placa del CCU, cada 10 milisegundos exactamente.
Otra razón es el consumo. La CPU STM32F405 que monta el CCU de Garmin es la misma que uso yo en el STE300 y en el nuevo gateway ATM200. Es una pequeña bestia con FPU que consume unos 120mA a 3.3v. Con una fuente conmutada de calidad que mide 10x18mm en la misma placa, el consumo en el lado de 12v se reduce a menos de 50mA.

Cualquier comparativa es estéril y es confundir churras con merinas: Estamos de acuerdo.

Para que sea algo más digerible el tema, pongo algunas fotos.

Ésta es la del desastre de mesa de trabajo:



Esta es del ACU, los Mosfet están en el otro lado de la placa:



Y ésta es del CCU, se pueden ver los dos uC STM32 y arriba, el MPU 9150:

Demostrado: No todo depende de las capacidades del hardware.
Según opinión de contactos profesionales, los pilotos Garmin están en la edad de piedra en lo que respecta al software, si se comparan a los actuales Evolution de Ray.
Hasta tal punto que un instalador especializado en Garmin, hace años que dejó de instalar pilotos de esta marca.
Me cuenta que reportó los problemas a Garmin en España, y que fueron transmitidos a Garmin USA, SIN RESPUESTA.

La forma de proceder es equivalente a lo que hace Raymarine con el soporte de sus MDF o plotters: No hacer nada de nada.

Y todo eso tiene una única lectura:
"Cada mochuelo a su olivo".
Garmin es bueno en su línea de GPS, MFD y plotters, aunque para mi gusto les falta implementar el software ARPA en el radar, y por propia experiencia es bastante desastre en lo que respecta a la sección N2k de los AIS.
Raymarine es bueno haciendo pilotos. Los sensores son retimbrados de Airmar y de los TackTick (marca absorbida): hay buenos, regulares y malos.
Simrad / B&G son una mezcolanza de fusiones y adquisiciones de empresas, con un nulo cuidado por compatibilizar sus propios equipos. La evolución de Robertson y los primeros Brookes and Gatehouse hacia los nuevos Simrad y B&G deja bastante que desear, según otro instalador con toda una vida de experiencia en estas marcas.
Navico, hoy en día es más que esa mezcolanza: a Simrad y B&G hay que añadir Lowrance, Mastervolt, Ancor, Attwood, Bep, Blue Sea, C-Map, CZone, Marinco, y algunas más. También algunas menos, puesto que la política de rentabilidad del grupo ha hecho desaparecer algunas marcas y modelos de equipos, dejanto tirados a los usuarios.

Pero todos ellos quieren imponer su ley, de manera que todos han desarrollado sistemas integrados MFD - Displays - CCU y ACU/ECU con protocolos propietarios.
En otras palabras, y como ejemplo: Un MFD Plotter Raymarine nunca podrá manejar un piloto de otra marca. Ni tampoco Un MFD de los demás podrá controlar otro piloto que no sea de la misma marca.
Como hay cierta confusión con los conceptos de control del piloto, lo aclaro ahora:
- Una es la gestión de órdenes de teclado, es decir STBY - AUTO, +1, etc. A eso me refiero cuando hablo de incompatibilidad.
- La otra, por suerte está normalizada por la NMEA: Es el envío de las sentencias o PGN desde el MFD para que el piloto pueda trabajar en modo TRACK / NAV. Actualmente ya son compatibles entre marcas diferentes, pero no lo fueron en los comienzos de NMEA2000.