Cita:
Originalmente publicado por Capicua
Como antes dicho no se trata de polemizar y sin dudas si sos tu quien lo dices y " tu " concibes OP menos aun.
Mismo así creo que se trata de un trabajo colaborativo en que muchos aquí y en otros sitios colaboran con ideas, algunas buenas y otras solo ideas.
Me quedan dudas de lo que afirmas del cableado o bien no te he entendido o no es bien así. O tal vez le falte capacidad a la PI para procesar tanta información.
Reitero la idea es no polemizar, yo lo veo así .
Analicemos las informaciones mas básicas que eventualmente podemos querer del motor y de forma rápida y sin sofisticar mucho yo diría que mínimamente, a mi me gustaría saber que hay flujo de agua salada y que la temperatura del motor esta dentro de un rango predefinido. Porque? Bueno porque tengamos flujo de agua salada no significa que tengamos refrigeración del motor. Observa que para el ejemplo estoy dejando de lado flujo de combustible, presión de acetite, etc. En esta configuración mínima, TM , S. de flujo precisaríamos 4 hilos para llevar información +,- , Temp, Pulso. Detalle ha ser considerado. No se sabe hoy por hoy cual será el comportamiento del un conversor A/D, bajo la influencia de las posibles interferencias. Ademas que habría que cubrir todas las posibilidades de múltiplos usuarios. Les regalo el peludo de blindar la comunicación, pero les vale intentarl…. Radio, VHF, HF , repley del alternador , encendido de heladera, ruido del pwm del Piloto, pwm del conversor chino 12 /5V y por hay va. 
A mi me queda claro que son justamente los motivo que tu das, los que justifica un modulo que comunique en forma serial bajo algún protocolo.
El problema de marinisación de un arduino nano se resume a un tubete de epoxi. Por otro lado el ejercito de sensores , SD , etc para mi es la misma. Los sensores porque no serian los mismo?
Lo que me gustaria.
En mi caso para el Motor y tal vez el de otros, un único arduino nano podría informar:
Temperatura del refrigerante.
Temperatura del agua de la salida escape.
Presión de aceite.
Flujo de refrigerante.
Flujo de diésel.
Corriente que esta entregando el alternador.
Conmutar los bancos de baterías.
Alarmar en algunos casos.
Mandar de forma serial toda la información por dos hilos comunes a OP.
Detalle el tamaño de el cableado seria mínima dada la proximidad de todos los elementos, la alimentación seria directa del motor
La esposa le pregunta al marido , querido que querés comer? El marido le responde que una unos tapas de jamón ibérico, queso …. . La esposa le responde, te pregunte que querías comer, no lo que te gustaría comer, preferís arroz con huevo o huevo con arroz. 
Cuanto te refieres a la comunicación vía, NMEA 0183, NMEA 2000, Signal K. Estos protocolos tienen reservadas sentencias que incorporen los medidores de flujo o la temperatura del motor, etc. Creo que no, y de ser así se complica. No? 
 |
No te preocupes, tengo bastante claro las diferencias entre una polémica y una discusión asi que puedes hablar con total libertad que aquí nadie se va a enfadar
También me viene al pelo tu mensaje para explicar como se toman las decisiones en un proyecto abierto, libre y colaborativo como este porque seguro que a alguien le interesa.
En primer lugar existe un lugar donde el código de un proyecto es expuesto publicamernte (repositorio), en nuestro caso es este:
https://github.com/sailoog/openplotter
Ahí es donde reside la copia original (master) y diferentes copias del original que se usan para probar codigo nuevo y que será incorporado al master una vez se compruebe que no tiene fallos, estas copias dentro del mismo repositorio se llaman branches:
https://github.com/sailoog/openplotter/branches
En este repositorio solo yo tengo permiso de hacer cambios con lo cual solo yo tengo la última palabra sobre la dirección que debe llevar el proyecto. Ahora viene lo bueno, cualquier persona puede hacer una copia de mi repositorio y entonces solo esa persona tendrá permisos para cambiar su copia, en nuestro caso estas son las copias que se han hecho de openplotter:
https://github.com/sailoog/openplotter/network/members
Estas personas pueden cear sus propias branches dentro de su repositorio y añadir funcionalidades al programa. En cualquier momento esta persona puede enviar los cambios que ha hecho en su repositorio al repositorio original, el mio, para que yo decida si incluyo sus nuevas funcionalidades (pull request). En esta página esto se ve claramente:
https://github.com/sailoog/openplotter/network
Las modificaciones que se han incorporado al repositorio original quedan incorporadas como ramas de este, pero lo mas importante que refleja esta gráfica es que hay ramas que no se han incorporado al repositorio original y siguen su curso independientemente.
Con esto intento mostrar que en caso de conflicto en la concepción del proyecto yo tengo siempre la última palabra en añadir cosas pero si no se llega a un consenso no puedo impedir que esa persona siga desarrollando esa concepción diferente del proyecto libremente. Todo queda reflejado y no hay dudas de la autoria de cada parte. Es una selección natural ya que si resulta que esa persona estaba en lo cierto y su concepción era la mas adecuada, la gente empezará a replicar su repositorio y evolucionar a partir de él y no del mio. Por lo tanto cualquier desarrollador de proyectos libres tendrá especial cuidado en analizar objetivamente cualquier cambio sugerido si no quiere que versiones mejores de su programa le pasen por delante. En el caso de OpenPlotter esto aun no ha pasado, las únicas inyecciones de código que se han rechazado han sido las que contenían errores y las ramas independientes que existen no han sido propuestas para incorporación al repositorio principal por las razones que sus autores hayan creído convenientes. Yo podría en cualquier momento "reclamar" esas modificaciones y añadirlas al repositorio principal clicando un solo botón aunque no hayan sido sugeridas.
Espero que esta explicación os sirva para entender porque algunos locos nos empeñamos en "regalar" nuestro trabajo. La calidad de un producto constantemente auditado por cientos de personas tiene que ser obligadamente muy alta y a la vez esa dinámica de desarrollo nos permite a simples desarrolladores individuales plantearnos grandes proyectos que sería imposible emprender por cuenta propia.
La mayoría de softwares propietarios y cerrados no durarían ni un solo dia en un entorno libre donde no hay trampas posibles. Si el famoso software de los motores volkswagen que engañó a medio mundo hubiera sido libre y abierto, jamas hubiera llegado a instalarse en un coche, hubiera ahorrado a sus creadores millones de euros en responsabilidades civiles y lo que es más importante, no solo mediría con más exactitud las emisiones sino que además probablemente habría versiones personalizadas que te enviarían datos a tu movil o te harían el cafe por la mañana
En cuanto al contenido de tu propuesta, algunas aclaraciones:
Como ya te comenté en mi último mensaje, tu propuesta de modulos independientes me parece tan valida como la de un solo modulo central y por eso en este momento OpenPlotter es compatible con ambas. Dependerá de las caracteristicas de cada barco o preferencias del usuario. Personalmente prefiero la simplicidad y emplear los menos dispositivos posibles y si me puedo ahorrar los arduino pues me los ahorraré.
De hecho creo que lo que estás buscando es algo como esto:
https://bitbucket.org/R_P_Ryan/enginemonitor/wiki/Home en su momento crecé varios emails con el autor para asegurar la compatibilidad con openplotter y consensuamos el usar Signal K como comunicación pero por alguna misteriosa razón el tipo desapareció del mapa y no concluyó la implementación.
La Raspberry tiene capacidad para todo lo que enumeras y además para ejecutar opencpn, decodificar AIS, actuar como servidor y bailar una sardana
y tengo mis dudas sobre la capacidad de un arduino nano para gestionar todos los sensores que necesitas y además generar la información en el protocolo escogido.
Al contrario de lo que supones, N2K y Signal K no solo contiene sentencias para manejar flujos, temperaturas de varios motores a la vez, etc. sino que SK también tiene sentencias para manejar sensores personalizados que no bubieran sido contemplados en su concepción.
En cuanto a las posibles interferencias que puedan haber en los convertidores AD ya han sido contempladas y existirán controles para realizar medias de mediciones y correctores o offsets.
Si decides trabajar en algunos de estos módulos independientes que comentas cuenta con toda la ayuda que necesites por mi parte para asegurar la plena compatibilidd con openplotter.