MinimOSD es un proyecto open source para superponer (On Screen Display) ciertos datos de telemetría en el vídeo transmitido por FPV en el aeromodelismo. Actualmente otro desarrollador del proyecto Ardupilot ha reescrito el código de MinimOSD y lo ha llamado MinimOSD Extra.

Las placas OSD que se ven en las tiendas de aeromodelismo son básicamente en dos formatos: el llamado Minim OSD (formato grande que trabaja a 5V y a 12V) y el Micro Minim OSD (formato  reducido, con mismo chip y mismas prestaciones, pero que precisa menos espacio y peso, funcionando además sólo a 5V).

Vamos a ver cómo flashear el firmware en estas placas OSD y cómo configurarlo con la última versión.

Conexión del OSD al USB del PC

Para configurar, leer y guardar, así como para instalar el firmware, necesitamos comunicarnos con la placa por medio del USB. Pero ambas placas OSD sólo disponen de comunicación serial al estado más básico (TTL), por lo que necesitamos un conversor USB<->TTL, comúnmente llamados conversores FTDI (nombre de la empresa de fabricante de varios chips).

Conversor FT232RL

Vale cualquier conversor, pero debe funcionar con la lógica de 5V. Yo suelo usar el de la imagen, un clon muy común del chip FT232RL.

Veamos ahora como conectarlos.

Pinout para MinimOSD

La conexión entre el MinimOSD y el conversor FTDI es la siguiente:

La correspondencia de pines es la siguiente:

Minim OSD FTDI232RL
BLK CTS
GND GND
5V VCC
RX TX
TX RX
GRN DTR

Pinout para Micro MinimOSD

La conexión entre el Micro MinimOSD y el conversor FTDI es la siguiente:

La correspondencia de pines es la siguiente:

FTDI232 Micro MinimOSD
GND GND
CTS GND
VCC +5V
TX RX
RX TX
DTR DTR

Instalando el firmware y configuración del OSD

Ambas placas tienen el mismo chip, un Atmel, por lo que el firmware puede ser recompilado con el IDE de Arduino. Cosa que no será necesaria porque están disponibles los diferentes binarios preparados para leer los distintos protocolos de telemetría actuales. Tanto Pixhawk como APM utilizan MAVLINK como protocolo de telemetría.

Aunque el chip nos lo suelen vender con algún tipo de firmware (o quizá no), conviene actualizarlo a la última versión y, obviamente, a la compilación coincidente con el protocolo de telemetría con el que lo vamos a alimentar. En nuestro caso, Mavlink.

Este es el literal traducido a castellano desde las instrucciones que nos suministra el programador (el proyecto está en: https://github.com/night-ghost/minimosd-extra, por si queremos echarle un vistazo a la versión en inglés).

  1. Bajar el último programa MinimOSD Extra. Vendrá con los binarios precompilados y un programita para Windows que nos ayuda en la configuración del OSD: https://github.com/night-ghost/minimosd-extra/blob/master/osd_latest.zip?raw=true
  2. Ejecutar OSD_Config.exe
  3. Conectar el OSD a un conversor serial USB<->TTL. Ya lo teníamos conectado. Asegurarse que están los drivers del conversor instalados y, una vez asegurados, ver con un programa visor de dispositivos USB el COM al que está conectado.

Una vez dentro del programa vamos a proceder a flashearla con la última versión del firmware. Algunas veces, al intentar subir el firmware me ha dado problemas de sincronización que, tras reintentar, desaparecen por completo. Veamos el proceso:

  1. Seleccionar el puerto COM en la pantalla de OSD_Config.
  2. Click Options -> Update Firmware. Selecciona el archivo Character_Updater_FW.hex dentro de la carpeta «FW_+_Char». Esto realmente no es el firmware, es un firmware especial que sirve exclusivamente para subir a la placa la tipografía.
  3. Click Options -> Update CharSet. Selecciona la última versión de la tipografía. Es el archivo MinimOSD_2.4.1.X.mcm dentro de la carpeta «FW_+Char». El programador dice que es obligatorio actualizar siempre la tipografía si actualizamos el firmware principal, por motivos de compatibilidad.
  4. Click Options -> Update Firmware (esta es la definitiva). Selecciona el archivo más reciente y compatible con nuestra telemetría. En nuestro caso MinimOsd_Extra_Uni.946DV-MAVLINK-release.hex. Está en la misma carpeta, «FW_+_Char». Ya tenemos flasheada la placa.

Con la última versión correcta del firmware, lo configuraremos y añadiremos a nuestro OSD las variables de telemetría que más nos gusten. En cuanto a configuración destacaría lo siguiente:

  1. Selecciona el modo de vídeo de tu cámara FPV. En Europa es PAL, pero puedes poner AUTO si no lo sabes o no lo has configurado en la cámara. En caso de que no sea el modo correcto la imagen saldrá, pero estará fuera de fase y en blanco y negro. La solución es cambiar el modo, en el OSD o en la cámara.
  2. Antes de configurar nada más conviene hacer un reset de la EPROM del OSD, para que no se mezclen las configuraciones antigua y nueva, especialmente si nuestro chip venía precargado con alguna versión.
  3. Configurar los parámetros que queramos visualizar.

Conexión a APM/Pixhawk

La conexión a Pixhawk/APM es sencilla. APM tiene un pin menos, pero no se utiliza. Básicamente se conectan los 5V, el GND y se conectan invertidos los pines TX y RX.

Conexionado de OSD, cámara VTX del FPV

En la imagen superior podemos ver resumido todo el conexionado. Teniendo en cuenta el pinout de cada OSD y el voltaje de cada placa (que difiere entre la versión normal y la micro +5V/+12V), podemos dividir el montaje en tres bloques independientes unidos por conectores. De esta manera facilitamos el mantenimiento posterior.

Del esquema anterior podemos resaltar varios aspectos que minimizarán el ruido eléctrico en el vídeo:

  1. Mantener los cables lo más cortos posible.
  2. Se añaden condensadores de low ESR en la entrada de alimentación de la cámara y en la salida de alimentación del VTX.
  3. Los VTX suelen venir con dos tomas de tierra independientes. Una es para su propia alimentación, directo de la LIPO. Otra es del vídeo, que debería estar compartida con la cámara. Por eso el cable de tierra de la cámara debe conectarse, además de a la PDB de donde salen los +5V, al propio OSD donde va conectada también la tierra del vídeo. Nos aseguramos así que los recorridos de la toma tierra sean similares.

Por otro lado podemos optar por hacer el conexionado de la placa OSD a la cámara, transmisor FPV y a la propia Pixhawk a través de una placa de conexiones o placa de distribución. Esta última versión es algo más costosa y añade algo de peso pero presenta ciertas ventajas a tener en cuenta:

  1. Podremos añadir algún condensador suplementario que evite algo de ruido eléctrico.
  2. Podremos también añadir conectores con posibilidad de intercambiar elementos.

Una versión que yo he utilizado con cierta fortuna en algunos modelos, es la siguiente:

Para hacerlo correctamente, conectar primero la LIPO y luego esta placa al conversor USB y al PC.

En esta configuración, para conectar la placa al PC/USB primero debo conectarla a la LIPO porque si no, se calienta en exceso el cable de tierra, probablemente al intentar alimentar el conjunto FPV.

Parámetros configuración conexión MAVLINK

Personalmente he conectado MinimOSD a TELEM1, TELEM2 e incluso a SERIAL4/5. En todos ellos me ha funcionado sin necesidad de retocar ningún parámetro más allá del protocolo y de la velocidad.

La correspondencia de puertos serie de Pixhawk con los conectores y su función es esta:

PUERTO SERIE CONECTOR FUNCIÓN
SERIAL0 CONSOLA / USB
SERIAL1 TELEM1 Función (protocolo) y velocidad seleccionable. Frecuencia de operación seleccionable. Se suele usar para telemetría MAVLINK.
SERIAL2 TELEM2 Función (protocolo) y velocidad seleccionable. Frecuencia de operación seleccionable. Se suele usar para telemetría MAVLINK.
SERIAL3 GPS GPS 1.

Función (protocolo) y velocidad seleccionable. Frecuencia de operación seleccionable. Se puede usar para telemetría  MAVLINK o para GPS, por ejemplo. Por defecto es GPS.

SERIAL4 SERIAL 4/5 GPS 2.

Función (protocolo) y velocidad seleccionable. Se puede usar para telemetría MAVLINK  o para un segundo GPS, por ejemplo. Por defecto no es nada.

SERIAL5 SERIAL 4/5 Debug

Es recomendable usar TELEM1 o 2, porque la frecuencia de los mensajes es configurable. En el puerto SERIAL3 también, pero ahí se suele conectar el GPS.

Tomando con el conector el TELEM1, tendríamos que obligatoriamente configurar:

SERIAL1_PROTOCOL = 1 (MAVLINK)
SERIAL1_BAUD = 57 (57.600 baudios)

Y la frecuencia de envío de paquetes (normalmente esto no es necesario configurarlo):

SR1_EXT_STAT, 2 ( 2hz for waypoints, GPS raw, fence data, current waypoint, etc)
SR1_EXTRA1, 5 ( 5hz for attitude and simulation state)
SR1_EXTRA2, 2 ( 2hz for VFR_Hud data )
SR1_EXTRA3, 3 ( 3hz for AHRS, Hardware Status, Wind )
SR1_POSITION, 2 ( 2hz for location data )
SR1_RAW_SENS, 2 ( 2hz for raw imu sensor data )
SR1_RC_CHAN, 5 ( 5hz for radio input or radio output data )

Parámetro extra: retraso de inicio de la telemetría

En determinadas ocasiones me ha resultado de utilidad reducir el comienzo del envío de los paquetes de telemetría por el puerto correspondiente, probablemente porque cuando la Pixhawk comienza a enviarlos, el OSD no está iniciado y ambos dispositivos se desincronizan irremediablemente.

En estos casos aparecerá el temido NO MAVLINK DATA y el OSD no será capaz de sincronizarse con el puerto serial de la Pixhawk.

Para retrasar el comienzo de envío de mensajes de telemetría por cualquier puerto, poner:

TELEM_DELAY=7

Esto retrasará el arranque de telemetría 7 segundos, que en mi caso han resultado siempre suficientes para evitar este problema.

Parámetro extra: control de flujo en los mensajes de telemetría

La Pixhawk puede establecer, detectar y desactivar el control de flujo en los puertos serie 1 y 2 (Telem1 y Telem2).

Cuando está activado, PX esperará a recibir mensajes de petición de datos de telemetría para enviarlos. Si no recibe dichas peticiones y el control de flujo está activado, no se mandaran datos y aparecerá el fatídico mensaje NO INPUT DATA.

BRD_SER1_RTSCTS=0
BRD_SER2_RTSCTS=0

Si fijamos el parámetro correspondiente a nuestro puerto a cero, desactivaremos el control de flujo y obligarnos a la PX a mandar los mensajes de telemetría a la cadencia marcada para cada tipo de mensaje en MHz, sin esperar solicitudes. Esa cadencia por segundo se establece en los parámetros vistos anteriormente.

Con este parámetro a 2, que es la opción por defecto, PX debería detectar si el dispositivo conectado soporta control de flujo. Muchos usuarios han reportado que fijándolo a cero su MinimOSD ha comenzado a funcionar correctamente, lo que quiere decir que probablemente no siempre la PX sea capaz de detectar que MinimOSD no tiene control de flujo… porque no tiene, ¿no?

Notas y soluciones exotéricas al «NO INPUT DATA»

Con todo lo visto hasta ahora pienso que tenemos suficientes elementos para hacer que nuestro OSD funcione a las mil maravillas. Pero si hemos leído hasta este apartado es que siguen los problemas. Veamos soluciones poco ortodoxas y muy poco probadas, basadas más en creencias de funcionamiento que en hechos científicos.

Correspondencia equívoca de los SRx y los puertos serie

Parece que hay cierta confusión en cuanto a los puertos serial referenciazos por SRx. Parece que el SR0 (usb), SR1 (Telem1) y SR2 (Telem2) son esos mismos puertos, pero el SR3 puede variar: «Serial SR3 does not necessarily correspond to serial 3 just the 3rd Mavlink port enabled in order used.»

En algunos foros de ardupilot se apunta la posibilidad de que algunas veces no arranque el puerto de telemetría y habría que reiniciar.

He tocado los parámetros para SR0 y SR1 y ya no recuerdo cuales eran los originales

Apunto aquí también los valores por defecto de los puertos SR0 y SR1, por si tenemos que restaurarlos ante un funcionamiento errático tras tocarlos. Ojo, porque SR0 es el USB y podemos dejar la PX fuera de juego:

SR0_RAW_SENS=2
SR0_EXT_STAT=2
SR0_RC_CHAN=2
SR0_RAW_CTRL=2
SR0_POSITION=2
SR0_EXTRA1=2
SR0_EXTRA2=2
SR0_EXTRA3=2
SR0_PARAMS=0
SR1_RAW_SENS=2
SR1_EXT_STAT=2
SR1_RC_CHAN=5
SR1_RAW_CTRL=3
SR1_POSITION=3
SR1_EXTRA1=10
SR1_EXTRA2=2
SR1_EXTRA3=2
SR1_PARAMS=10

Desconexión del cable TX del OSD

Llegados a este punto he llegado a leer en foros que hay usuarios que desconectan el cable TX del OSD. En teoría el OSD no tiene que mandar nada a la PX, por lo que la desconexión no debería afectar a su funcionamiento.

En la práctica pienso que es algo equivalente a desactivar el control de flujo del que hablábamos en un punto anterior, pero a lo bruto. Si el OSD no puede mandar nada físicamente, la Pixhawk se dará cuenta que no tiene capacidad de control de flujo y lo desactivará.