Ir al contenido

← Todas las funcionalidades

Inspección visual (visión artificial)Raspberry Pi + cámara USBFicherosInfraestructura

Configuración JSON persistente y gestión de referencias golden

Cada parámetro ajustado que una estación de visión olvida al reiniciar es una llamada de teléfono desde la línea. Este patrón de configuración de sistema de visión, de un despliegue real de inspección visual en línea de producción, guarda los ajustes de cámara (enfoque, brillo, contraste, saturación) y los seis parámetros de procesado en un config.json plano, y almacena cada referencia golden como un PNG ya preprocesado en una carpeta references/. Tras un corte de corriente, la Raspberry Pi arranca directamente como una estación de inspección operativa y calibrada.

Un único fichero JSON como fuente única de verdad

Los parámetros de cámara, procesado y matching viven en un único fichero legible que los sliders de la GUI escriben y el pipeline lee. El cargador rellena las claves ausentes con valores de fábrica, de modo que añadir un parámetro en una actualización de software nunca rompe una estación instalada. Que sea JSON plano también significa que puedes hacer diff entre las configuraciones de dos estaciones o respaldar una copiando un solo fichero.

Fija la cámara a través de V4L2

A las cámaras USB de consumo les encanta el autofocus y la autoexposición, que cambian la imagen en silencio entre dos piezas consecutivas y arruinan los umbrales fijos. Al arrancar, los valores guardados se aplican mediante cv2.VideoCapture.set: primero autofocus off, después enfoque manual, brillo, contraste y saturación. A partir de ahí la cámara se comporta como un sensor industrial fijo, y cada pieza se captura en las mismas condiciones ópticas — la condición previa para tener umbrales estables aguas abajo.

Guarda las referencias preprocesadas, no en bruto

Las referencias golden se guardan como PNG después de que el pipeline completo de preprocesado ya se haya ejecutado, un fichero por variante de producto. Ese trabajo ocurre exactamente una vez en el momento de la captura en lugar de en cada ciclo de inspección, y garantiza que el template matcher siempre compara elementos equivalentes: mismo recorte, mismo CLAHE, misma binarización. Cambiar de producto es simplemente seleccionar otro fichero de references/ — sin recalibración, sin paradas.

Un fragmento de la implementación

Tal cual del ejemplo desplegado en el Raspberry Pi + cámara USB — cópialo libremente:

def load_config(path=CONFIG_PATH):
    """Loads config.json; if it does not exist, creates it with the defaults."""
    if os.path.exists(path):
        with open(path, "r", encoding="utf-8") as f:
            cfg = json.load(f)
        # Fills in new keys that did not exist in older versions
        for section, values in DEFAULT_CONFIG.items():
            cfg.setdefault(section, {})
            for k, v in values.items():
                cfg[section].setdefault(k, v)
        return cfg
    save_config(DEFAULT_CONFIG, path)
    return dict(DEFAULT_CONFIG)

El ejemplo completo es un programa entero — cabecera de conexionado, setup y bucle principal — listo para adaptar a tu aplicación.

Preguntas frecuentes

¿Por qué JSON en lugar de una base de datos o un fichero INI?

Una estación, unas pocas decenas de parámetros, editados por un solo proceso. JSON viene incluido en Python, es legible para el soporte remoto y trivial de comparar y respaldar. Una base de datos añade trabajo de operación sin beneficio a esta escala.

¿Qué pasa si config.json falta o está corrupto?

El cargador lo recrea desde los valores de fábrica para que la estación siempre arranque. En ese caso se pierden los valores ajustados, y por eso el despliegue guarda una copia del fichero en cada cambio de producto.

¿Conviene versionar las imágenes de referencia?

Ayuda. Los PNG de references/ más config.json definen por completo el comportamiento de la estación, así que hacer commit de ambos te da una instantánea completa y restaurable de cualquier configuración validada.

Funcionalidades relacionadas