[jiauka]

Simbad:
Los MFD / Plotters de marcas conocidas no son muy diferentes a un PC o tablet. Lo único que los diferencia es la carcasa y una conectividad NMEA2000 nativa.
..

Uff,

Las tablets y PCs con pantalla, llevan batería,los MFDs, no.
La pantalla de los MFDs suele ser visible a simple vista.
El consumo de los MFDs, es mucho menor.
Jamás llevan Windows como sistema operativo.
Nunca he visto 1 MFD  con CPU Intel.

Sobre el papel pueden pacererse, en la realidad de HW y SW no se parecen en casi nada.

[Auskalo]

Estas entre dos caminos que no parecen muy compatibles entre sí, o low cost o algo de calidad y a precio de mercado.
Entre los baratos, yo veo dos vías, los plug and play (pelagic y cpt) y los open (pypilot en sus diferentes versiones y creadores y arduinos varios). 
Ahí se ven dos tipos de clientes distintos, quien quiere algo hecho que sea conectar y listo, que busca algo económico y fiable, tal vez a costa de la precisión de un equipo de primera marca. Y quien busca algo que pueda "crear", modificar, o customizar, en los open, tal vez a costa de fiabilidad y un soporte comercial detrás.
Si vas por la calidad a precio comercial ahí también tienes clientes distintos, el que busca algo que simplemente cumpla, con una relación calidad precio adecuada (raymarine) y quiénes buscan una serie de prestaciones que otros equipos no tienen o no tienen su fama (NKE para solitarios y B&G para regatas) o fiabilidad (furuno o simrad)
En la parte técnica nada puedo aportar, como usuario, si que valoro el que haya algo físico y cableado para operar y ver los datos, aunque sea una pantalla simple como los raymarine, el mando es un extra pero prefiero algo más consistente y duro de base.
Y evidentemente que sea fiable, duro, y no haya que ser ingeniero para calibrarlo y usarlo.
Para hacerlo más conocido pues tal vez podrías "exponsorizar" con alguna unidad a algún regatista conocido o crucerista que pueda tener difusión en nuestro entorno ( youtuber o blog) que puedan usarlo y familiarizarse con él y luego dar su opinión .
También recuerdo que una vez vi un vídeo donde un navegante comparaba creo que era un raymarine con un NKE, y simplemente  viendo la estela que dejaba uno y otro y el movimiento de la rueda en las mismas condiciones dejaba claro cuál funcionaba mejor. Hoy en día miramos mucho YouTube y foros antes de comprar para crearnos una opinión del producto, y son buenos lugares para mostrar tu producto.
Espero que te salga bien la cosa, y ya que has invertido tanto tiempo puedas obtener un retorno.
Saludos.
Auskalo.

[gypsylyon]

El precio final de un producto se calcula en funcion de muchos factores.
Uno claro es el coste de la materia prima o de los elementos, en caso del piloto de la elctronica que se necesita. A eso hay que añadir los costes de desarrollo que suelen ser los mas elevados, ya que esta un equipo de profesionales involucrado. Eso son un monton de horas de mano de obra que no son baratas.
Hay que realizar un estudio de mercado para saber cuantas unidades se pueden llegar a vender. Finalmente se reacalcula el coste de roduccion en funcion de las unidades que se van a fabricar. Hay que añadir el coste de control de calidad, fallos en unidades de produccion, devoluciones, etc. Luego viene el otro factor de coste, que es la comercializacion con gastos en publicidad y comisiones a los vendedores.

Asi que depenciendo de la cantidad de produccion y el margen de ganancias que se decida tener, el costo de produccion puede representar hasta el 80% del precio de venta. Cuantas menos unidades se venda, mas caro sera el producto. Para ello tiene que tener una excelente calidad y desde luego ofrecer algo que la competencia no lo puede hacer

[Tehani]

Yo no imagino manejando el piloto con el móvil en la mano en situaciones meteorológicas comprometidas, cualquier cosa móvil, de quita y pon, en un barco termina por no ser practica. 
Se nota que no tienes un control remoto, y no digo de quién...

Con respecto a los actuadores es cierto que ya se hablo e incluso se buscaron alternativas, no apareciendo nada, pero creo que tienes un nicho de mercado, muchos tenemos pilotos antiguos, yo mismo aun llevo un Autohelm ST6000, con lo cual ya tenemos el motor y el display, actualizar la electrónica a un precio razonable es un incentivo importante, yo necesitaría 3500€ SOLO para una electrónica Raymarine EV 400    
Esa es la idea original, tal como se dijo al principio en este hilo. Será necesario comprar el actuador sólo para instalaciones nuevas.

Estaría bien que alguien se ofreciera para negociar con Hy-pro o Lecomble & Schmittt. Eso supongo que lo habrán hecho tanto B&G, NKE como Garmin, ya que incorporan estos actuadores en sus pilotos.

Uff,

Las tablets y PCs con pantalla, llevan batería,los MFDs, no. ¿Y qué?
La pantalla de los MFDs suele ser visible a simple vista. Todas las pantallas se ven a "simple vista".
El consumo de los MFDs, es mucho menor.  No me atrevería a asegurarlo en términos generales, y a igualdad de tamaño de pantalla.
Jamás llevan Windows como sistema operativo.  Desde luego, muchos MFD llevan Linux (como la raspi). Windows habría que pagarlo aparte.
Nunca he visto 1 MFD  con CPU Intel.  ¿Has desmontado muchos?

Sobre el papel pueden pacererse, en la realidad de HW y SW no se parecen en casi nada.
Me parece que no has entendido el concepto. Lo que estamos comentando es que todos llevan chips sobre una PCB no tropicalizada. En ambiente marino, lo mismo dá que sea un procesador de arquitectura Hardward que Von Neuman. Todos trabajan bajo esas condiciones.

Jiauka: Muestra algo de lo que dices que haces. Aún estoy esperando esas capturas N2k y esa "ingeniería inversa" de los equipos Simrad y B&G, que te ofreciste a facilitar en este mismo hilo. Ya no me hacen falta, pero te lo agradecería igual.
Por mi parte, como recordarás, hace años te pasé mis fuentes del software de procesamiento NMEA2000 de bajo nivel (Lo más complicado) y las funciones del protocolo ISO. ¿Has hecho algo con eso?.
Te lo dí con la mejor intención y era para aportar algo a la causa "Open". Tal como te comenté, esperaba que lo publicaras en GitHub, pero nada de nada.
Me sentí como un pardillo cuando constaté tu falta de colaboración, pero ya no me importa que lo tengas, puesto que lo he corregido y mejorado enormemente en este tiempo. Por supuesto, las miles de horas de trabajo que este software lleva detrás, sin colaboración de ningún tipo, hacen que el conjunto haya dejado de ser "Open" definitivamente.

He intentado aportar lo mejor que sé en este foro, en éste y otros hilos.
Creo que toca retirada, por lo menos durante un tiempo. Esto me consume recursos para ocuparme de Ocenav y de los animales.
Así que tranquilo, no te chistaré. Pero mi consejo final es que seas algo menos prepotente en tus réplicas a las intervenciones de los demás.

[Tehani]

...
Ahí se ven dos tipos de clientes distintos, quien quiere algo hecho que sea conectar y listo, que busca algo económico y fiable, tal vez a costa de la precisión de un equipo de primera marca. Y quien busca algo que pueda "crear", modificar, o customizar, en los open, tal vez a costa de fiabilidad y un soporte comercial detrás.

Bueno, hay mucha polémica sobre esto. Lo que creo que es cierto, es que un usuario medio ni quiere ni debería dedicarse a los inventos, y por eso, los sistemas DIY como pipylot no proliferan demasiado.
Por eso, este STE300 es de tipo "plug and play", independiente de raspis ni de MFD / plotters, ni equipos de viento de nadie en concreto.

En la parte técnica nada puedo aportar, como usuario, si que valoro el que haya algo físico y cableado para operar y ver los datos, aunque sea una pantalla simple como los raymarine, el mando es un extra pero prefiero algo más consistente y duro de base.

Normal que pienses así. Me parece que tú tampoco tienes un control remoto de alguien que conozco.

Para hacerlo más conocido pues tal vez podrías "exponsorizar" con alguna unidad a algún regatista conocido o crucerista que pueda tener difusión en nuestro entorno ( youtuber o blog) que puedan usarlo y familiarizarse con él y luego dar su opinión .

Lo he hecho varias veces y el resultado ha sido nefasto para mí. Hay mucho caradura suelto. Una vez el gateway instalado en su barco, adiós muy buenas. No pienso hacerlo más.

También recuerdo que una vez vi un vídeo donde un navegante comparaba creo que era un raymarine con un NKE, y simplemente  viendo la estela que dejaba uno y otro y el movimiento de la rueda en las mismas condiciones dejaba claro cuál funcionaba mejor. Hoy en día miramos mucho YouTube y foros antes de comprar para crearnos una opinión del producto, y son buenos lugares para mostrar tu producto.

Todo eso está trucado, es fácil hacer que un piloto vaya mal tocando los ajustes. Si miras otro vídeo con el sponsor de Raymarine, o de quien quieras, resultará que el mejor no será NKE. Pecamos de creernos todo lo que se cuelga en youtube.

Espero que te salga bien la cosa, y ya que has invertido tanto tiempo puedas obtener un retorno.
Saludos.
Auskalo.

Gracias Auskalo.

[Velero Simbad]

Tehani, si te refieres a un control remoto como este, estamos de acuerdo, pero eso no es lo mismo que un móvil, no hay pantalla táctil, es compacto etc ... nada que ver

[jiauka]

Estaría bien que alguien se ofreciera para negociar con Hy-pro o Lecomble & Schmittt. Eso supongo que lo habrán hecho tanto B&G, NKE como Garmin, ya que incorporan estos actuadores en sus pilotos.


Jiauka: Muestra algo de lo que dices que haces. Aún estoy esperando esas capturas N2k y esa "ingeniería inversa" de los equipos Simrad y B&G, que te ofreciste a facilitar en este mismo hilo. Ya no me hacen falta, pero te lo agradecería igual.
Por mi parte, como recordarás, hace años te pasé mis fuentes del software de procesamiento NMEA2000 de bajo nivel (Lo más complicado) y las funciones del protocolo ISO. ¿Has hecho algo con eso?.
Te lo dí con la mejor intención y era para aportar algo a la causa "Open". Tal como te comenté, esperaba que lo publicaras en GitHub, pero nada de nada.
Me sentí como un pardillo cuando constaté tu falta de colaboración, pero ya no me importa que lo tengas, puesto que lo he corregido y mejorado enormemente en este tiempo. Por supuesto, las miles de horas de trabajo que este software lleva detrás, sin colaboración de ningún tipo, hacen que el conjunto haya dejado de ser "Open" definitivamente.

He intentado aportar lo mejor que sé en este foro, en éste y otros hilos.
Creo que toca retirada, por lo menos durante un tiempo. Esto me consume recursos para ocuparme de Ocenav y de los animales.
Así que tranquilo, no te chistaré. Pero mi consejo final es que seas algo menos prepotente en tus réplicas a las intervenciones de los demás.

Las tramas de la botonera b&G te las envié hace como 3 años...

En fin...sobre el consejo, lo mismo digo

[Tehani]

Las tramas de la botonera b&G te las envié hace como 3 años...

En fin...sobre el consejo, lo mismo digo

Nunca me has enviado nada, Si esa información la hubiera tenido hace tres años, no hubiera tenido que ir a Gran Canaria a realizar capturas.
Eso digo, en fin...

[Tehani]

Vamos a ver si le damos el empujón final para el bautizo de este piloto.
Visité a Jubilao en su astillero, y no le hizo ascos a montarlo en su nuevo barco.

[Tehani]

Bueno, hace mucho que no doy la lata por aquí, y no es que no haya pasado nada...
En este tiempo, el girocompás ha experimentado un montón de transformaciones, tanto de hardware como de software.
El piloto se ha ido desarrollando simultáneamente, y ha estado avanzando a medida que el gyro, en sus distintas fases, ha sido capaz de entregar datos utilizables.
En estos momentos, el desarrollo de ambos productos ya lleva algo más de cinco años, aunque no a "full time", claro.
Ha sido curioso abordar dos problemáticas tan distintas: La del gyro desde el punto de vista matemático y del procesamiento DSP (Digital Signal Processing), y la del piloto, que ha exigido por un lado aplicar conocimientos de navegación y análisis de respuesta de otros pilotos, y por otro la supervisión automática de los sensores, GPS, setup y órdenes de usuario, Siempre teniendo en mente de que cada barco es un mundo, y que no tienen nada que ver las reacciones de un velero, con las de una motora o un mercante de miles de toneladas.

Lo primero que hice fue experimentar hace más de seis años usando una placa convencional de un ATM105 a la que soldé una placa de sensores, el famoso MPU9255, que está compuesto por un MPU6050 (acelerómetro + gyro) y un magnetómetro Asahi KASEY AK8963C incrustado dentro del mismo chip de InvenSense.
Ese MPU9255 me dio mal resultado porque después de pelear varias semanas, comprobé que en ese chisme no hay manera de comunicar con el magnetómetro por bus SPI (por mucho que lo diga el fabricante). Con este MPU9255 ya preparé todo para trabajar con el famoso filtro Kalman extendido.
El filtro Kalman tiene un procesado impresionante, así que cuando me enteré de que el BNO055 ya lo tenía integrado en su CPU interna, me decidí a usarlo porque el procesador principal del gyro ya tenía mucha carga con las comunicaciones Seatalk, NMEA's, WiFi, GNSS y USB.



También hice otro prototipo que Gypsy estuvo probando en Suiza:



Esta es una de las primeras pruebas ya conectado al recién horneado piloto (que aún no tenía nombre...):

Pero claro, tenía que hacer una placa porque el BNO055 no podía soldarse fácilmente en un ATM105...

[Tehani]

Recocaré el post anterior, que he tenido que dejar para ir a comer.
Pondré fotos y colgaré algún documento y/o enlace.
Por supuesto, si alguien está interesando en algún tema o quiere documentación precisa, estoy a disposición para facilitarla.
Seguiré luego añadiendo fotos, y seguiré con el final temporal (porque nunca se puede asegurar cuándo acabará realmente).

[onilum]

Admirable! 

 Jamás imaginaba la cantidad de horas de trabajo que hay detrás del desarrollo de un proyecto similar, tu constancia y determinación bien justifican los precios de algunos componentes electrónicos que los más comunes de los mortales solo vemos como cajas a la que hemos normalizado que realizan su trabajo y además criticamos por ser de un coste elevado.

 Enhorabuena y gracias por exponerlo aquí aunque no pueda entender muchas cosas es muy interesante poder saber como se desarrollan estos equipos de primera mano!

[Tehani]

Retocado el primer post de esta serie. Seguimos...

Llegué a hacer dos prototipos distintos de la placa del Gyro, y varias pruebas de sensores con bastante mala pata en dos de ellas.
La primera versión de PCB tenía salidas Seatalk, NMEA2000, NMEA0183, WiFi y USB para datos de heading, velocidad de rotación, cabeceo y escora, además de los datos propios del GNSS (GPS de varias constelaciones). Entonces diseñé la primera PCB específica del gyro para este sensor.
El microcontrolador usado para el gyro es el STM32F072, que es el mismo que el empleado en el gateway REM072. Es muy pequeño, con tan sólo 48 pines y tiene de todo: i2c para los sensores, cuatro USARTS para comunicar con el módulo WiFi, Seatalk, GNSS y NMEA0183; tiene bus CAN para NMEA2000 y USB modo device:






Eso supuso un follón en las conexiones y cable, y dificultad de instalación por parte del usuario. El GNSS que usé por aquel entonces era un UBLOX m8n que puso también dificultades de espacio dentro de la cúpula. Se pudo resolver diseñando un soporte plástico especial e imprimiéndolo en la 3D. Desde el principio, el conjunto se compone de cuatro niveles de PCB en sandwich: Placa base, alimentador, sensores y GNSS:







Fue otra pelea a muerte: Este sensor tiene autocalibración durante el funcionamiento normal, pero cuando arranca da un heading imprevisible. Para corregir el problema, tuve que escribir un sistema de calibración de fábrica y guardar los parámetros en la flash del propio microcontrolador. No fue suficiente con eso, porque pude comprobar que el BNO055 llega a bloquear el bus i2c durante varios milisegundos de una forma bastante aleatoria, y eso se traduce tanto en el bloqueo de la CPU principal como en la fluctuación de los tiempos de salida de esos datos por NMEA2000. Por si fuera poco, dos de estos sensores dieron problemas de funcionamiento: uno dejó de dar datos, y en otro dejó de funcionar un eje del acelerómetro. Simplemente inaceptable.

Gypsy también tuvo problemas con esta primera versión BNO055.

[Tehani]

Diseñé una caja cúpula para poder albergar el conjunto en el exterior del barco. Incluso la imprimí, pero no quedaba bien. Buscando en fabricantes de todo el mundo encontré ésta de Altinkaya enclosures en Turquía, que impuso sus minúsculas medidas al diseño de las placas de circuito:

 

Bueno, tenía una PCB ya con i2c. Podía ser buen momento para intentarlo otra vez con el MPU9255, pero tenía que partir de cero otra vez con el software de calibración y filtrado. Me animó ver que el piloto Garmin Reactor que me trajo Juan Solís llevaba ese mismo sensor.
Se trataba de corregir mediante calibración las derivas del giróscopo, el offset (descentrado) del acelerómetro y magnetómetro (eso que se llama distorsión "hard iron"), y la conversión del elipsoide del magnetómetro a una esfera (eso que se llama distorsión "soft iron").



Revisé muchísimo código (Arduino y ARM) y artículos de doctorados de todo el mundo. Había calibraciones muy simples y otras complejísimas y poco documentadas sin pagar derechos. Desde luego, seguir el proceso mal indicado por InvenSense fue un auténtico fracaso. El procesado interno del MPU9255 es del todo contraproducente.

Finalmente encontré unos documentos PDF de ST Microelectronics (el fabricante del STM32) que describían el procedimiento para la calibración y el cálculo de la matriz de rotación para el acelerómetro (https://www.st.com/resource/en/design_ti...ronics.pdf).

Depués de desenpolvar mi odiada álgebra de la carrera, me puse a trabajar con esas condenadas matrices y cuaternions. Con respecto a la calibración del magnetómetro, encontré varios programas para hacerlo: Magmaster (malísimo), Magcal (necesita un archivo de entrada con los datos en bruto y luego hay que escribir la calibración a mano), y el campeón: MotionCal (https://www.pjrc.com/store/prop_shield.html), que se instala en un PC, recibe datos por USB, y envía la matriz de calibración también por USB.
El único problema de ese software es que está pensado para otros sensores con diferente sensibilidad; así que tuve que analizar más software para ver qué proporcionalidad en microteslas por LSB usaban, y adaptarme. Ese programa Motioncal no está pulido del todo, pero la parte del magnetómetro está bastante bien. Usa el mismo algoritmo que la tarea magcal del filtro Kalman de Freescale. (https://www.nxp.com/docs/en/data-sheet/XSFLK_DS.pdf).

Primeras pruebas estáticas de respuesta: Vamos encaminados pero los sensores producen mucho ruido superpuesto.


La gráfica inferior es el heading magnético en centésimas de grado, y la distancia horizontal entre las bolitas es de 0,1 segundo.


Empecé a escribir filtros digitales (DSP) de paso alto para el giróscopo y de paso bajo para el acelerómetro y magnetómetro. Mejoró la cosa, pero me dí cuenta de que el magnetómetro AK8963C incrustado en el MPU9255 tenía una baja resolución (pocos microteslas por bit) y eso afectaba a la precisión del conjunto.
Más búsquedas por internet me hicieron ver que existía una plaquita de sensores MPU6050 + magnetómetro separado de Rockwell HMC5883. Bueno, por casa tenía una plaquita con un HMC5883 e hice un sandwich con la del MPU9255.



Con eso mejoró mucho la precisión, así que pedí cinco supuestas placas GY-87 (MPU6050 + HMC5883 + BMP180). Digo supuestas porque al recibirlas, estaban marcadas como HW-290 y el HMC5883 estaba suplantado por otro chip. Evidentemente no funcionaban, y las devolví.
Se trataba de buscar más, y al hacerlo me enteré de que Rockwell hacía dos años que dejó de fabricar esos magnetómetros y había cedido los derechos de explotación a un fabricante chino. Este fabricante anuncia que su chip QMC5883 es compatible, pero no lo es sin modificar el software totalmente. Por tanto NO es compatible. Pues nada a rehacer de nuevo el software y a pedir placas previa consulta al vendedor. Del nuevo chip no me gustó que no tuviera programado un procedimiento interno para crear un campo magnético como hacía el Rockwell, y así calcular con precisión la sensibilidad (pero qué le vamos a hacer, no hay otra...). Me tranquilizó un poco que todo el mundo lo está usando; incluso los que montan conjuntos con los GNSS UBLOX para el "dead reckoning" (estima mediante sensores inerciales y brújula).

[Tehani]

Bueno, en ese momento, nuevo diseño de la placa principal y decisiones varias: La salida de datos estaría limitada a Seatalk y NMEA2000, el puerto USB se usaría sólo para la calibración, desaparecía el NMEA0183 y la WiFi se usaría únicamente para el setup y las actualizaciones de software.
Busqué un conector estanco con 7 pines: +12v, 0v, Seatalk, USB D+, USB D-, CAN+ y CAN-. Encontré dos muy buenos del mismo fabricante de dos tamaños distintos, y al recibirlos, me dí cuenta de que tenía que poner el grande para facilitar las conexiones. La base de ese conector se atornilla a la caja y al soldarlo es un soporte más para el conjunto interno de PCB's del gyro que ayuda al sistema de torretas hexagonales:



Además, compré unos módulos GNSS UBLOX 10 más avanzados, muchísimo más pequeños y con menos consumo de energía:




Hice cinco prototipos, reutilizando piezas de los otros cinco hechos con la primera versión de PCB's. Otro trabajazo de campeonato...
Y seguimos con pruebas estáticas de estabilidad, así como el diseño e impresión 3D de un soporte para la calibración con niveles de burbuja:



Calibración del magnetómetro con el programa MotionCal:



El análisis de resultados dio varios frutos que llevaron a la mejora de la comunicación i2c porque aparecían algunos errores muy de vez en cuando, pero aparecían.
También apliqué otro filtro más en las lecturas del aceletrómetro y magnetómetro: La mediana (que no es lo mismo que la media aritmética). Me lié también con temas de estadística...
Ya os he comentado que empecé con el filtro Kalman, que resultaba muy pesado para un microcontrolador que no fuera muy potente, así que todo lo realizado con los dos prototipos de PCB's lo hice con el filtro Madgwick, que comparado en varios artículos, daba una respuesta similar al Kalman sin tanta carga para la CPU. Estudiando más, leí otro artículo que decía que el algoritmo "gradient descent" de este filtro añadía ruido extra en algunas condiciones, cosa que comprobé y era cierta. Por eso pasé a usar otro filtro de fusión similar: El Mahony.  https://github.com/dccharacter/AHRS (Aquí están los dos).
Comparando, el filtro Kalman no es exigente con los datos en bruto que proceden de los sensores, ya que el filtrado digital previo está integrado y establece una compensación para el ruido del giróscopo. Los filtros de fusión Madgwick y Mahony requieren un procesado previo bastante intenso como ya he comentado.

Como la WiFi dejaba de usarse como salida de datos, hice que estuviera activa durante cinco minutos desde la puesta en marcha. Si en ese tiempo no se conecta nadie para el setup o para actualizar, simplemente se desactiva. De esa manera, el gyro en su conjunto pasa a consumir tan sólo 30mA (0,375W).