Hardware Compatible

info

SecureVu soporta múltiples detectores que funcionan en distintos tipos de hardware:

La mayoría del hardware

Coral EdgeTPU: El Google Coral EdgeTPU está disponible en formatos USB, Mini PCIe y m.2, lo que permite una amplia compatibilidad con distintos dispositivos.
Hailo: El módulo de aceleración de IA Hailo8 y Hailo8L está disponible en formato m.2 con un HAT para dispositivos RPi, ofreciendo una amplia compatibilidad con distintos dispositivos.
Community Supported MemryX: El módulo de aceleración MX3 está disponible en formato m.2, ofreciendo amplia compatibilidad en diversas plataformas.
Community Supported DeGirum: Servicio para usar dispositivos de hardware en la nube o localmente. Hardware y modelos disponibles en la nube en su sitio web.

AMD

ROCm: ROCm puede ejecutarse en GPUs discretas AMD para proporcionar una detección de objetos eficiente.
ONNX: ROCm será detectado y utilizado automáticamente como detector en la imagen SecureVu -rocm cuando se configure un modelo ONNX compatible.

Apple Silicon

Apple Silicon: Apple Silicon puede ejecutarse en dispositivos M1 y versiones más recientes de Apple Silicon.

Intel

OpenVino: OpenVino puede ejecutarse en GPUs Intel Arc, GPUs integradas Intel y CPUs Intel para proporcionar una detección de objetos eficiente.
ONNX: OpenVINO será detectado y utilizado automáticamente como detector en la imagen SecureVu predeterminada cuando se configure un modelo ONNX compatible.

GPU Nvidia

ONNX: Las GPUs Nvidia serán detectadas y utilizadas automáticamente como detector en la imagen SecureVu -tensorrt cuando se configure un modelo ONNX compatible.

Nvidia Jetson Community Supported

TensortRT: TensorRT puede ejecutarse en dispositivos Jetson, usando uno de los muchos modelos predeterminados.
ONNX: TensorRT será detectado y utilizado automáticamente como detector en la imagen SecureVu -tensorrt-jp6 cuando se configure un modelo ONNX compatible.

Rockchip Community Supported

RKNN: Los modelos RKNN pueden ejecutarse en dispositivos Rockchip con NPUs integradas.

Synaptics Community Supported

Synaptics: Los modelos synap pueden ejecutarse en dispositivos Synaptics (p. ej. astra machina) con NPUs integradas.

Para pruebas

Detector CPU (no recomendado para uso real): Usa una CPU para ejecutar el modelo tflite; no se recomienda y en la mayoría de los casos OpenVINO puede usarse en modo CPU con mejores resultados.

nota

No se pueden mezclar múltiples detectores para la detección de objetos (p. ej.: OpenVINO y Coral EdgeTPU no pueden usarse para la detección de objetos al mismo tiempo).

Esto no afecta el uso del hardware para acelerar otras tareas como la búsqueda semántica

Detectores Oficialmente Soportados

SecureVu ofrece varios tipos de detectores integrados. De forma predeterminada, SecureVu usará un único detector CPU. Otros detectores pueden requerir configuración adicional como se describe a continuación. Al usar múltiples detectores, estos se ejecutarán en procesos dedicados pero tomarán de una cola común de solicitudes de detección de todas las cámaras.

Detector Edge TPU

El tipo de detector Edge TPU ejecuta modelos TensorFlow Lite utilizando el delegado Google Coral para la aceleración por hardware. Para configurar un detector Edge TPU, establece el atributo "type" en "edgetpu".

El dispositivo Edge TPU puede especificarse usando el atributo "device" según la Documentación de la API Python de TensorFlow Lite. Si no se establece, el delegado usará el primer dispositivo que encuentre.

tip

Consulta los pasos comunes de solución de problemas de Edge TPU si el Edge TPU no es detectado.

Coral USB simple

detectors:
  coral:
    type: edgetpu
    device: usb

Múltiples Corals USB

detectors:
  coral1:
    type: edgetpu
    device: usb:0
  coral2:
    type: edgetpu
    device: usb:1

Coral nativo (Dev Board)

advertencia: puede tener problemas de compatibilidad después de v0.9.x

detectors:
  coral:
    type: edgetpu
    device: ""

Coral PCIE/M.2 simple

detectors:
  coral:
    type: edgetpu
    device: pci

Múltiples Corals PCIE/M.2

detectors:
  coral1:
    type: edgetpu
    device: pci:0
  coral2:
    type: edgetpu
    device: pci:1

Combinación de Corals

detectors:
  coral_usb:
    type: edgetpu
    device: usb
  coral_pci:
    type: edgetpu
    device: pci

Modelos compatibles con EdgeTPU

Modelo	Notas
Mobiledet	Modelo predeterminado
YOLOv9	Más preciso pero más lento que el modelo predeterminado

Mobiledet

Se incluye un modelo TensorFlow Lite en el contenedor en /edgetpu_model.tflite y es el que usa este tipo de detector de forma predeterminada. Para usar tu propio modelo, monta el archivo en el contenedor y proporciona la ruta con model.path.

YOLOv9

Los modelos YOLOv9 compilados para TensorFlow Lite y correctamente cuantizados son compatibles, pero no se incluyen de forma predeterminada. Consulta las instrucciones para descargar un modelo con soporte para Google Coral.

tip

Usuarios de SecureVu+: Sigue las instrucciones para establecer un ID de modelo en tu archivo de configuración.

Configuración e instalación de YOLOv9

Después de colocar los archivos descargados del modelo tflite y las etiquetas en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  coral:
    type: edgetpu
    device: usb

model:
  model_type: yolo-generic
  width: 320 # <--- debe coincidir con el imgsize del modelo, típicamente 320
  height: 320 # <--- debe coincidir con el imgsize del modelo, típicamente 320
  path: /config/model_cache/yolov9-s-relu6-best_320_int8_edgetpu.tflite
  labelmap_path: /config/labels-coco17.txt

Ten en cuenta que debido a las limitaciones de hardware del Coral, el labelmap es un subconjunto de las etiquetas COCO e incluye solo 17 clases de objetos.

Hailo-8

Este detector está disponible para su uso con los módulos de aceleración de IA Hailo-8 y Hailo-8L. La integración detecta automáticamente la arquitectura de tu hardware mediante la CLI de Hailo y selecciona el modelo predeterminado apropiado si no se especifica un modelo personalizado.

Consulta la documentación de instalación para obtener información sobre cómo configurar el hardware Hailo.

Configuración

Al configurar el detector Hailo, tienes dos opciones para especificar el modelo: una ruta local o una URL. Si se proporcionan ambas, el detector verificará primero el modelo en la ruta local indicada. Si el archivo no se encuentra, descargará el modelo desde la URL especificada. El archivo del modelo se almacena en caché en /config/model_cache/hailo.

YOLO

Usa esta configuración para modelos basados en YOLO. Cuando no se proporciona una ruta o URL de modelo personalizado, el detector descarga automáticamente el modelo predeterminado según el hardware detectado:

Hardware Hailo-8: Usa YOLOv6n (predeterminado: yolov6n.hef)
Hardware Hailo-8L: Usa YOLOv6n (predeterminado: yolov6n.hef)

detectors:
  hailo:
    type: hailo8l
    device: PCIe

model:
  width: 320
  height: 320
  input_tensor: nhwc
  input_pixel_format: rgb
  input_dtype: int
  model_type: yolo-generic
  labelmap_path: /labelmap/coco-80.txt

  # El detector selecciona automáticamente el modelo predeterminado según tu hardware:
  # - Para hardware Hailo-8: YOLOv6n (predeterminado: yolov6n.hef)
  # - Para hardware Hailo-8L: YOLOv6n (predeterminado: yolov6n.hef)
  #
  # Opcionalmente, puedes especificar una ruta de modelo local para reemplazar el predeterminado.
  # Si se proporciona una ruta local y el archivo existe, se usará en lugar de descargarlo.
  # Ejemplo:
  # path: /config/model_cache/hailo/yolov6n.hef
  #
  # También puedes reemplazarlo usando una URL personalizada:
  # path: https://hailo-model-zoo.s3.eu-west-2.amazonaws.com/ModelZoo/Compiled/v2.14.0/hailo8/yolov6n.hef
  # asegúrate de darle la configuración correcta según el modelo

SSD

Para modelos basados en SSD, proporciona una ruta de modelo o URL a tu modelo SSD compilado. La integración verificará primero la ruta local antes de descargar si es necesario.

detectors:
  hailo:
    type: hailo8l
    device: PCIe

model:
  width: 300
  height: 300
  input_tensor: nhwc
  input_pixel_format: rgb
  model_type: ssd
  # Especifica la ruta del modelo local (si está disponible) o URL para SSD MobileNet v1.
  # Ejemplo con ruta local:
  # path: /config/model_cache/h8l_cache/ssd_mobilenet_v1.hef
  #
  # O reemplazar usando una URL personalizada:
  # path: https://hailo-model-zoo.s3.eu-west-2.amazonaws.com/ModelZoo/Compiled/v2.14.0/hailo8l/ssd_mobilenet_v1.hef

Modelos personalizados

El detector Hailo es compatible con todos los modelos YOLO compilados para hardware Hailo que incluyan postprocesamiento. Puedes especificar una URL personalizada o una ruta local para descargar o usar tu modelo directamente. Si se proporcionan ambas, el detector verifica primero la ruta local.

detectors:
  hailo:
    type: hailo8l
    device: PCIe

model:
  width: 640
  height: 640
  input_tensor: nhwc
  input_pixel_format: rgb
  input_dtype: int
  model_type: yolo-generic
  labelmap_path: /labelmap/coco-80.txt
  # Opcional: Especifica una ruta de modelo local.
  # path: /config/model_cache/hailo/custom_model.hef
  #
  # Alternativamente, o como respaldo, proporciona una URL personalizada:
  # path: https://custom-model-url.com/path/to/model.hef

Para modelos adicionales listos para usar, visita: https://github.com/hailo-ai/hailo_model_zoo

Hailo8 es compatible con todos los modelos del Hailo Model Zoo que incluyen postprocesamiento HailoRT. Puedes elegir cualquiera de estos modelos preconfigurados para tu implementación.

Nota: El parámetro config.path puede aceptar una ruta de archivo local o una URL que termine en .hef. Cuando se proporciona, el detector verificará primero si la ruta es una ruta de archivo local. Si el archivo existe localmente, lo usará directamente. Si el archivo no se encuentra localmente o si se proporcionó una URL, intentará descargar el modelo desde la URL especificada.

Detector OpenVINO

El tipo de detector OpenVINO ejecuta un modelo OpenVINO IR en CPUs AMD e Intel, GPUs Intel y NPUs Intel. Para configurar un detector OpenVINO, establece el atributo "type" en "openvino".

El dispositivo OpenVINO a utilizar se especifica mediante el atributo "device" según las convenciones de nomenclatura de la Documentación de dispositivos. Los dispositivos más comunes son CPU, GPU o NPU.

OpenVINO es compatible con plataformas Intel de 6ª generación (Skylake) y posteriores. También se ejecutará en CPUs AMD aunque no tiene soporte oficial para ellas. Se requiere una plataforma Intel compatible para usar el dispositivo GPU o NPU con OpenVINO. Para conocer los requisitos detallados del sistema, consulta los Requisitos del sistema de OpenVINO

tip

Sistemas NPU + GPU: Si tienes tanto NPU como GPU disponibles (procesadores Intel Core Ultra), usa NPU para la detección de objetos y GPU para enriquecimientos (búsqueda semántica, reconocimiento facial, etc.) para obtener el mejor rendimiento y compatibilidad.

Al usar muchas cámaras, un solo detector puede no ser suficiente para mantener el ritmo. Se pueden definir múltiples detectores siempre que haya recursos de GPU disponibles. Un ejemplo de configuración sería:

detectors:
  ov_0:
    type: openvino
    device: GPU # o NPU
  ov_1:
    type: openvino
    device: GPU # o NPU

Modelos compatibles con OpenVINO

Modelo	GPU	NPU	Notas
YOLOv9	✅	✅	Recomendado para GPU y NPU
RF-DETR	✅	✅	Requiere iGPU XE o Arc
YOLO-NAS	✅	✅
MobileNet v2	✅	✅	Modelo rápido y ligero, menos preciso que los modelos más grandes
YOLOX	✅	?
D-FINE	❌	❌

SSDLite MobileNet v2

Se incluye un modelo OpenVINO en el contenedor en /openvino-model/ssdlite_mobilenet_v2.xml y es el que usa este tipo de detector de forma predeterminada. El modelo proviene del Open Model Zoo de Intel SSDLite MobileNet V2 y está convertido a un modelo IR de precisión FP16.

Configuración de MobileNet v2

Usa la configuración de modelo que se muestra a continuación cuando uses el detector OpenVINO con el modelo OpenVINO predeterminado:

detectors:
  ov:
    type: openvino
    device: GPU # O NPU

model:
  width: 300
  height: 300
  input_tensor: nhwc
  input_pixel_format: bgr
  path: /openvino-model/ssdlite_mobilenet_v2.xml
  labelmap_path: /openvino-model/coco_91cl_bkgr.txt

YOLOX

Este detector también soporta YOLOX. SecureVu no incluye ningún modelo YOLOX precargado, por lo que deberás proporcionar tus propios modelos.

YOLO-NAS

Los modelos YOLO-NAS son compatibles, pero no se incluyen de forma predeterminada. Consulta la sección de modelos para más información sobre cómo descargar el modelo YOLO-NAS para usar en SecureVu.

Configuración e instalación de YOLO-NAS

Después de colocar el modelo onnx descargado en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  ov:
    type: openvino
    device: GPU

model:
  model_type: yolonas
  width: 320 # <--- debe coincidir con lo que se estableció en el notebook
  height: 320 # <--- debe coincidir con lo que se estableció en el notebook
  input_tensor: nchw
  input_pixel_format: bgr
  path: /config/yolo_nas_s.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

YOLO (v3, v4, v7, v9)

Los modelos YOLOv3, YOLOv4, YOLOv7 y YOLOv9 son compatibles, pero no se incluyen de forma predeterminada.

tip

El detector YOLO ha sido diseñado para soportar modelos YOLOv3, YOLOv4, YOLOv7 y YOLOv9, pero también puede ser compatible con otras arquitecturas de modelos YOLO.

Configuración e instalación de YOLOv

aviso

Si estás usando un modelo SecureVu+, no debes definir ninguno de los parámetros model que se indican a continuación en tu configuración excepto path. Consulta la documentación del modelo SecureVu+ para más información sobre cómo configurar tu modelo.

Después de colocar el modelo onnx descargado en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  ov:
    type: openvino
    device: GPU # o NPU

model:
  model_type: yolo-generic
  width: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  height: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/yolo.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

RF-DETR

RF-DETR es un modelo basado en DETR. Los modelos exportados como ONNX son compatibles, pero no se incluyen de forma predeterminada. Consulta la sección de modelos para más información sobre cómo descargar el modelo RF-DETR para usar en SecureVu.

aviso

Debido al tamaño y la complejidad del modelo RF-DETR, solo se recomienda ejecutarlo con tarjetas gráficas Arc discretas.

Configuración e instalación de RF-DETR

Después de colocar el modelo onnx descargado en tu carpeta config/model_cache, puedes usar la siguiente configuración:

detectors:
  ov:
    type: openvino
    device: GPU

model:
  model_type: rfdetr
  width: 320
  height: 320
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/rfdetr.onnx

D-FINE

D-FINE es un modelo basado en DETR. Los modelos exportados como ONNX son compatibles, pero no se incluyen de forma predeterminada. Consulta la sección de modelos para más información sobre cómo descargar el modelo D-FINE para usar en SecureVu.

aviso

Actualmente los modelos D-FINE solo se ejecutan en OpenVINO en modo CPU; las GPUs actualmente fallan al compilar el modelo

Configuración e instalación de D-FINE

Después de colocar el modelo onnx descargado en tu carpeta config/model_cache, puedes usar la siguiente configuración:

detectors:
  ov:
    type: openvino
    device: CPU

model:
  model_type: dfine
  width: 640
  height: 640
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/dfine-s.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

Detector Apple Silicon

La NPU en Apple Silicon no puede accederse desde dentro de un contenedor, por lo que primero debe configurarse el cliente detector de Apple Silicon. Se recomienda usar la imagen Docker de SecureVu con el sufijo -standard-arm64, por ejemplo ghcr.io/securecorp-mexico/securevu2:stable-standard-arm64.

Instalación

Configura el cliente detector de Apple Silicon y ejecuta el cliente
Configura el detector en SecureVu e inicia SecureVu

Configuración

Usando la configuración del detector a continuación se conectará al cliente:

detectors:
  apple-silicon:
    type: zmq
    endpoint: tcp://host.docker.internal:5555

Modelos compatibles con Apple Silicon

No se incluye ningún modelo predeterminado; los siguientes formatos son compatibles:

YOLO (v3, v4, v7, v9)

Los modelos YOLOv3, YOLOv4, YOLOv7 y YOLOv9 son compatibles, pero no se incluyen de forma predeterminada.

tip

El detector YOLO ha sido diseñado para soportar modelos YOLOv3, YOLOv4, YOLOv7 y YOLOv9, pero también puede ser compatible con otras arquitecturas de modelos YOLO. Consulta la sección de modelos para más información sobre cómo descargar modelos YOLO para usar en SecureVu.

Cuando SecureVu se inicia con la siguiente configuración, se conectará al cliente detector y transferirá el modelo automáticamente:

detectors:
  apple-silicon:
    type: zmq
    endpoint: tcp://host.docker.internal:5555

model:
  model_type: yolo-generic
  width: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  height: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/yolo.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

Detector GPU AMD/ROCm

Instalación

El soporte para GPUs AMD se proporciona usando el detector ONNX. Para utilizar la GPU AMD para la detección de objetos, usa una imagen Docker de SecureVu con el sufijo -rocm, por ejemplo ghcr.io/securecorp-mexico/securevu2:stable-rocm.

Configuración de Docker para acceso a la GPU

ROCm necesita acceso a los dispositivos /dev/kfd y /dev/dri. Cuando Docker o SecureVu no se ejecutan como root, también se deben agregar los grupos video (y posiblemente render y ssl/_ssl).

Al ejecutar Docker directamente, se deben agregar los siguientes parámetros para acceso a los dispositivos:

$ docker run --device=/dev/kfd --device=/dev/dri  \
    ...

Al usar Docker Compose:

services:
  securevu:
    ...
    devices:
      - /dev/dri
      - /dev/kfd

Para referencia sobre los ajustes recomendados, consulta ejecutar ROCm/pytorch en Docker.

Configuración de Docker para reemplazar la versión del chipset GPU

Tu GPU puede funcionar perfectamente sin ninguna configuración especial, pero en muchos casos necesitan ajustes manuales. La pila de software AMD/ROCm incluye un conjunto limitado de drivers de GPU y para modelos más nuevos o faltantes deberás reemplazar la versión del chipset por una versión anterior/genérica para que funcione.

Además, AMD/ROCm no soporta "oficialmente" las GPUs integradas. Aún así funciona con la mayoría de ellas, pero requiere ajustes especiales. Hay que configurar la variable de entorno HSA_OVERRIDE_GFX_VERSION. Consulta el reporte de error de ROCm para contexto y ejemplos.

Para la compilación de SecureVu con rocm hay alguna detección automática:

gfx1031 -> 10.3.0
gfx1103 -> 11.0.0

Si tienes algo diferente, es posible que necesites reemplazar HSA_OVERRIDE_GFX_VERSION al iniciar Docker. Supongamos que la versión que necesitas es 10.0.0, entonces debes configurarla desde la línea de comandos así:

$ docker run -e HSA_OVERRIDE_GFX_VERSION=10.0.0 \
    ...

Al usar Docker Compose:

services:
  securevu:
    ...
    environment:
      HSA_OVERRIDE_GFX_VERSION: "10.0.0"

Determinar qué versión necesitas puede ser complicado ya que no puedes saber el nombre del chipset y el driver a partir del nombre de la marca AMD.

primero asegúrate de que el entorno rocm funcione correctamente ejecutando /opt/rocm/bin/rocminfo en el contenedor de SecureVu — debe listar tanto la CPU como la GPU con sus propiedades
encuentra la versión del chipset que tienes (gfxNNN) en la salida de rocminfo (ver a continuación)
usa un motor de búsqueda para consultar qué HSA_OVERRIDE_GFX_VERSION necesitas para el nombre gfx dado ("gfxNNN ROCm HSA_OVERRIDE_GFX_VERSION")
reemplaza HSA_OVERRIDE_GFX_VERSION con el valor correspondiente
si las cosas no funcionan, revisa los registros de Docker de SecureVu

Verificar si AMD/ROCm está funcionando y encontró tu GPU

$ docker exec -it securevu /opt/rocm/bin/rocminfo

Determinar la versión del chipset de tu GPU AMD:

Desestablecemos HSA_OVERRIDE_GFX_VERSION para evitar que un reemplazo existente interfiera con el resultado:

$ docker exec -it securevu /bin/bash -c '(unset HSA_OVERRIDE_GFX_VERSION && /opt/rocm/bin/rocminfo |grep gfx)'

Modelos compatibles con ROCm

tip

El kernel de GPU AMD es conocido por ser problemático especialmente al convertir modelos al formato mxr. El enfoque recomendado es:

Deshabilitar la detección de objetos en la configuración.
Iniciar SecureVu con el detector onnx configurado; el modelo principal de detección de objetos se convertirá al formato mxr y se almacenará en caché en el directorio de configuración.
Una vez que esto haya terminado, como lo indican los registros, habilita la detección de objetos en la interfaz de usuario y confirma que funciona correctamente.
Volver a habilitar la detección de objetos en la configuración.

Consulta los modelos compatibles con ONNX para los modelos soportados; hay algunas advertencias:

Los modelos D-FINE no son compatibles
Se sabe que los modelos YOLO-NAS no funcionan bien en GPUs integradas

ONNX

ONNX es un formato abierto para construir modelos de aprendizaje automático; SecureVu soporta la ejecución de modelos ONNX en CPU, OpenVINO, ROCm y TensorRT. Al iniciar, SecureVu intentará automáticamente usar una GPU si hay una disponible.

info

Si se usa la compilación correcta para tu GPU, esta será detectada y utilizada automáticamente.

AMD
- ROCm será detectado y utilizado automáticamente con el detector ONNX en la imagen SecureVu -rocm.
Intel
- OpenVINO será detectado y utilizado automáticamente con el detector ONNX en la imagen SecureVu predeterminada.
Nvidia
- Las GPUs Nvidia serán detectadas y utilizadas automáticamente con el detector ONNX en la imagen SecureVu -tensorrt.
- Los dispositivos Jetson serán detectados y utilizados automáticamente con el detector ONNX en la imagen SecureVu -tensorrt-jp6.

tip

detectors:
  onnx_0:
    type: onnx
  onnx_1:
    type: onnx

Modelos compatibles con ONNX

Modelo	GPU Nvidia	GPU AMD	Notas
YOLOv9	✅	✅	Soporta CUDA Graphs para rendimiento óptimo en Nvidia
RF-DETR	✅	❌	Soporta CUDA Graphs para rendimiento óptimo en Nvidia
YOLO-NAS	⚠️	⚠️	No compatible con CUDA Graphs
YOLOX	✅	✅	Soporta CUDA Graphs para rendimiento óptimo en Nvidia
D-FINE	⚠️	❌	No compatible con CUDA Graphs

No se incluye ningún modelo predeterminado; los siguientes formatos son compatibles:

YOLO-NAS

Configuración e instalación de YOLO-NAS

aviso

Si estás usando un modelo YOLO-NAS de SecureVu+, no debes definir ninguno de los parámetros model que se indican a continuación en tu configuración excepto path. Consulta la documentación del modelo SecureVu+ para más información sobre cómo configurar tu modelo.

Después de colocar el modelo onnx descargado en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  onnx:
    type: onnx

model:
  model_type: yolonas
  width: 320 # <--- debe coincidir con lo que se estableció en el notebook
  height: 320 # <--- debe coincidir con lo que se estableció en el notebook
  input_pixel_format: bgr
  input_tensor: nchw
  path: /config/yolo_nas_s.onnx
  labelmap_path: /labelmap/coco-80.txt

YOLO (v3, v4, v7, v9)

Los modelos YOLOv3, YOLOv4, YOLOv7 y YOLOv9 son compatibles, pero no se incluyen de forma predeterminada.

tip

Configuración e instalación de YOLOv

aviso

Después de colocar el modelo onnx descargado en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  onnx:
    type: onnx

model:
  model_type: yolo-generic
  width: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  height: 320 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/yolo.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

YOLOx

Los modelos YOLOx son compatibles, pero no se incluyen de forma predeterminada. Consulta la sección de modelos para más información sobre cómo descargar el modelo YOLOx para usar en SecureVu.

Configuración e instalación de YOLOx

Después de colocar el modelo onnx descargado en tu carpeta de configuración, puedes usar la siguiente configuración:

detectors:
  onnx:
    type: onnx

model:
  model_type: yolox
  width: 416 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  height: 416 # <--- debe coincidir con el imgsize establecido durante la exportación del modelo
  input_tensor: nchw
  input_dtype: float_denorm
  path: /config/model_cache/yolox_tiny.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

RF-DETR

Configuración e instalación de RF-DETR

Después de colocar el modelo onnx descargado en tu carpeta config/model_cache, puedes usar la siguiente configuración:

detectors:
  onnx:
    type: onnx

model:
  model_type: rfdetr
  width: 320
  height: 320
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/rfdetr.onnx

D-FINE

Configuración e instalación de D-FINE

Después de colocar el modelo onnx descargado en tu carpeta config/model_cache, puedes usar la siguiente configuración:

detectors:
  onnx:
    type: onnx

model:
  model_type: dfine
  width: 640
  height: 640
  input_tensor: nchw
  input_dtype: float
  path: /config/model_cache/dfine_m_obj2coco.onnx
  labelmap_path: /labelmap/coco-80.txt

Ten en cuenta que el labelmap usa un subconjunto del conjunto completo de etiquetas COCO que tiene solo 80 objetos.

Detector CPU (no recomendado)

El tipo de detector CPU ejecuta un modelo TensorFlow Lite utilizando la CPU sin aceleración por hardware. Se recomienda usar un tipo de detector con aceleración por hardware para un mejor rendimiento. Para configurar un detector basado en CPU, establece el atributo "type" en "cpu".

peligro

El detector CPU no se recomienda para uso general. Si no tienes hardware GPU o Edge TPU, usar el Detector OpenVINO en modo CPU suele ser más eficiente que usar el detector CPU.

El número de hilos utilizados por el intérprete puede especificarse usando el atributo "num_threads" y su valor predeterminado es 3.

Se incluye un modelo TensorFlow Lite en el contenedor en /cpu_model.tflite y es el que usa este tipo de detector de forma predeterminada. Para usar tu propio modelo, monta el archivo en el contenedor y proporciona la ruta con model.path.

detectors:
  cpu1:
    type: cpu
    num_threads: 3
  cpu2:
    type: cpu
    num_threads: 3

model:
  path: "/custom_model.tflite"

Al usar detectores CPU, puedes agregar un detector CPU por cámara. Agregar más detectores que el número de cámaras no debería mejorar el rendimiento.

Detector Deepstack / CodeProject.AI Server

El detector Deepstack / CodeProject.AI Server para SecureVu te permite integrar las capacidades de detección de objetos de Deepstack y CodeProject.AI en SecureVu. CodeProject.AI y DeepStack son plataformas de IA de código abierto que pueden ejecutarse en varios dispositivos como Raspberry Pi, Nvidia Jetson y otro hardware compatible. Es importante tener en cuenta que la integración se realiza a través de la red, por lo que los tiempos de inferencia pueden no ser tan rápidos como los detectores nativos de SecureVu, pero aún ofrece una solución eficiente y confiable para la detección y seguimiento de objetos.

Instalación

Para comenzar con CodeProject.AI, visita su sitio web oficial y sigue las instrucciones para descargar e instalar el servidor de IA en tu dispositivo preferido. Las instrucciones detalladas de configuración para CodeProject.AI están fuera del alcance de la documentación de SecureVu.

Para integrar CodeProject.AI en SecureVu, deberás realizar los siguientes cambios en tu archivo de configuración de SecureVu:

detectors:
  deepstack:
    api_url: http://<your_codeproject_ai_server_ip>:<port>/v1/vision/detection
    type: deepstack
    api_timeout: 0.1 # segundos

Reemplaza <your_codeproject_ai_server_ip> y <port> con la dirección IP y el puerto de tu servidor CodeProject.AI.

Para verificar que la integración funciona correctamente, inicia SecureVu y observa los registros en busca de mensajes de error relacionados con CodeProject.AI. Además, puedes revisar la interfaz web de SecureVu para ver si los objetos detectados por CodeProject.AI se muestran y rastrean correctamente.

Detectores con soporte de la comunidad

MemryX MX3

Este detector está disponible para su uso con el módulo acelerador MemryX MX3 en formato M.2. SecureVu soporta el MX3 en plataformas de hardware compatibles, proporcionando una detección de objetos eficiente y de alto rendimiento.

Consulta la documentación de instalación para obtener información sobre cómo configurar el hardware MemryX.

Para configurar un detector MemryX, simplemente establece el atributo type en memryx y sigue la guía de configuración a continuación.

Configuración

Para configurar el detector MemryX, usa el siguiente ejemplo de configuración:

MemryX MX3 PCIe simple

detectors:
  memx0:
    type: memryx
    device: PCIe:0

Múltiples módulos PCIe MemryX MX3

detectors:
  memx0:
    type: memryx
    device: PCIe:0

  memx1:
    type: memryx
    device: PCIe:1

  memx2:
    type: memryx
    device: PCIe:2

Modelos compatibles

Los modelos MemryX .dfp se descargan automáticamente en tiempo de ejecución, si está habilitado, en el contenedor en /memryx_models/model_folder/.

YOLO-NAS

El modelo YOLO-NAS incluido en este detector se descarga de la Sección de modelos y se compila a DFP con mx_nc.

Nota: El modelo predeterminado para el detector MemryX es YOLO-NAS 320x320.

El tamaño de entrada para YOLO-NAS puede establecerse en 320x320 (predeterminado) o 640x640.

El tamaño predeterminado de 320x320 está optimizado para menor uso de CPU y tiempos de inferencia más rápidos.

Configuración

A continuación se muestra la configuración recomendada para usar el modelo YOLO-NAS (pequeño) con el detector MemryX:

detectors:
  memx0:
    type: memryx
    device: PCIe:0

model:
  model_type: yolonas
  width: 320 # (Puede establecerse en 640 para mayor resolución)
  height: 320 # (Puede establecerse en 640 para mayor resolución)
  input_tensor: nchw
  input_dtype: float
  labelmap_path: /labelmap/coco-80.txt
  # Opcional: El modelo normalmente se obtiene a través del runtime, por lo que 'path' puede omitirse a menos que quieras usar un modelo personalizado o local.
  # path: /config/yolonas.zip
  # El archivo .zip debe contener:
  # ├── yolonas.dfp          (un archivo que termina en .dfp)
  # └── yolonas_post.onnx    (opcional; solo si el modelo incluye una red de postprocesamiento recortada)

YOLOv9

El modelo YOLOv9s incluido en este detector se descarga del GitHub original como en la Sección de modelos y se compila a DFP con mx_nc.

Configuración

A continuación se muestra la configuración recomendada para usar el modelo YOLOv9 (pequeño) con el detector MemryX:

detectors:
  memx0:
    type: memryx
    device: PCIe:0

model:
  model_type: yolo-generic
  width: 320 # (Puede establecerse en 640 para mayor resolución)
  height: 320 # (Puede establecerse en 640 para mayor resolución)
  input_tensor: nchw
  input_dtype: float
  labelmap_path: /labelmap/coco-80.txt
  # Opcional: El modelo normalmente se obtiene a través del runtime, por lo que 'path' puede omitirse a menos que quieras usar un modelo personalizado o local.
  # path: /config/yolov9.zip
  # El archivo .zip debe contener:
  # ├── yolov9.dfp          (un archivo que termina en .dfp)

YOLOX

El modelo proviene del OpenCV Model Zoo y está precompilado a DFP.

Configuración

A continuación se muestra la configuración recomendada para usar el modelo YOLOX (pequeño) con el detector MemryX:

detectors:
  memx0:
    type: memryx
    device: PCIe:0

model:
  model_type: yolox
  width: 640
  height: 640
  input_tensor: nchw
  input_dtype: float_denorm
  labelmap_path: /labelmap/coco-80.txt
  # Opcional: El modelo normalmente se obtiene a través del runtime, por lo que 'path' puede omitirse a menos que quieras usar un modelo personalizado o local.
  # path: /config/yolox.zip
  # El archivo .zip debe contener:
  # ├── yolox.dfp          (un archivo que termina en .dfp)

SSDLite MobileNet v2

El modelo proviene del OpenMMLab Model Zoo y ha sido convertido a DFP.

Configuración

A continuación se muestra la configuración recomendada para usar el modelo SSDLite MobileNet v2 con el detector MemryX:

detectors:
  memx0:
    type: memryx
    device: PCIe:0

model:
  model_type: ssd
  width: 320
  height: 320
  input_tensor: nchw
  input_dtype: float
  labelmap_path: /labelmap/coco-80.txt
  # Opcional: El modelo normalmente se obtiene a través del runtime, por lo que 'path' puede omitirse a menos que quieras usar un modelo personalizado o local.
  # path: /config/ssdlite_mobilenet.zip
  # El archivo .zip debe contener:
  # ├── ssdlite_mobilenet.dfp          (un archivo que termina en .dfp)
  # └── ssdlite_mobilenet_post.onnx    (opcional; solo si el modelo incluye una red de postprocesamiento recortada)

Usar un modelo personalizado

Para usar tu propio modelo:

Empaqueta tu modelo compilado en un archivo .zip.
El .zip debe contener el archivo .dfp compilado.
Dependiendo del modelo, el compilador también puede generar una red de postprocesamiento recortada. Si está presente, tendrá el sufijo _post.onnx.
Monta el archivo .zip en el contenedor y especifica su ruta usando model.path en tu configuración.
Actualiza labelmap_path para que coincida con las etiquetas de tu modelo personalizado.

Para instrucciones detalladas sobre la compilación de modelos, consulta la documentación del Compilador MemryX y los Tutoriales.

# El detector selecciona automáticamente el modelo predeterminado si no se proporciona nada en la configuración.
#
# Opcionalmente, puedes especificar una ruta de modelo local como archivo .zip para reemplazar el predeterminado.
# Si se proporciona una ruta local y el archivo existe, se usará en lugar de descargarlo.
#
# Ejemplo:
# path: /config/yolonas.zip
#
# El archivo .zip debe contener:
# ├── yolonas.dfp          (un archivo que termina en .dfp)
# └── yolonas_post.onnx    (opcional; solo si el modelo incluye una red de postprocesamiento recortada)

Detector NVidia TensorRT

Los dispositivos Nvidia Jetson pueden usarse para la detección de objetos utilizando las bibliotecas TensorRT. Debido al tamaño de las bibliotecas adicionales, este detector solo se proporciona en imágenes con el sufijo de etiqueta -tensorrt-jp6, p. ej. ghcr.io/securecorp-mexico/securevu2:stable-tensorrt-jp6. Este detector está diseñado para funcionar con modelos Yolo para la detección de objetos.

Generar modelos

El modelo utilizado para TensorRT debe preprocesarse en la misma plataforma de hardware en la que se ejecutará. Esto significa que cada usuario debe realizar una configuración adicional para generar un archivo de modelo para la biblioteca TensorRT. Se incluye un script que generará varios modelos comunes.

La imagen SecureVu generará archivos de modelo durante el inicio si el modelo especificado no se encuentra. Los modelos procesados se almacenan en la carpeta /config/model_cache. Normalmente la ruta /config ya está mapeada a un directorio en el host y model_cache no necesita mapearse por separado a menos que el usuario quiera almacenarlo en una ubicación diferente en el host.

De forma predeterminada, no se generará ningún modelo, pero esto puede cambiarse especificando la variable de entorno YOLO_MODELS en Docker. Se pueden listar uno o más modelos en formato separado por comas y cada uno será generado. Los modelos solo se generarán si el archivo {model}.trt correspondiente no está presente en la carpeta model_cache, por lo que puedes forzar la regeneración de un modelo eliminándolo de tu carpeta de datos de SecureVu.

Si tienes un dispositivo Jetson con DLAs (Xavier u Orin), puedes generar un modelo que se ejecutará en la DLA añadiendo -dla al nombre del modelo, p. ej. especifica YOLO_MODELS=yolov7-320-dla. El modelo se ejecutará en DLA0 (SecureVu no soporta actualmente DLA1). Las capas incompatibles con DLA recurrirán a ejecutarse en la GPU.

Si tu GPU no soporta operaciones FP16, puedes pasar la variable de entorno USE_FP16=False para deshabilitarlo.

Los modelos específicos pueden seleccionarse pasando una variable de entorno al comando docker run o en tu archivo docker-compose.yml. Usa el formato -e YOLO_MODELS=yolov4-416,yolov4-tiny-416 para seleccionar uno o más nombres de modelos. Los modelos disponibles se muestran a continuación.

Modelos disponibles

yolov3-288
yolov3-416
yolov3-608
yolov3-spp-288
yolov3-spp-416
yolov3-spp-608
yolov3-tiny-288
yolov3-tiny-416
yolov4-288
yolov4-416
yolov4-608
yolov4-csp-256
yolov4-csp-512
yolov4-p5-448
yolov4-p5-896
yolov4-tiny-288
yolov4-tiny-416
yolov4x-mish-320
yolov4x-mish-640
yolov7-tiny-288
yolov7-tiny-416
yolov7-640
yolov7-416
yolov7-320
yolov7x-640
yolov7x-320

Un fragmento de ejemplo de docker-compose.yml que convierte los modelos yolov4-608 y yolov7x-640 se vería así:

securevu:
  environment:
    - YOLO_MODELS=yolov7-320,yolov7x-640
    - USE_FP16=false

Parámetros de configuración

El detector TensorRT puede seleccionarse especificando tensorrt como tipo de modelo. La GPU deberá pasarse al contenedor Docker usando los mismos métodos descritos en la sección Aceleración por hardware. Si pasas múltiples GPUs, puedes seleccionar qué GPU se usa para un detector con el parámetro de configuración device. El parámetro device es un valor entero del índice de la GPU, como se muestra por nvidia-smi dentro del contenedor.

El detector TensorRT usa archivos de modelo .trt que se ubican en /config/model_cache/tensorrt de forma predeterminada. La ruta del modelo y las dimensiones utilizadas dependerán del modelo que hayas generado.

Usa la configuración a continuación para trabajar con los modelos TRT generados:

detectors:
  tensorrt:
    type: tensorrt
    device: 0 #Este es el valor predeterminado, selecciona la primera GPU

model:
  path: /config/model_cache/tensorrt/yolov7-320.trt
  labelmap_path: /labelmap/coco-80.txt
  input_tensor: nchw
  input_pixel_format: rgb
  width: 320 # DEBE coincidir con el modelo elegido, p. ej. yolov7-320 -> 320, yolov4-416 -> 416
  height: 320 # DEBE coincidir con el modelo elegido, p. ej. yolov7-320 -> 320 yolov4-416 -> 416

Synaptics

La detección de objetos acelerada por hardware es compatible con los siguientes SoCs:

SL1680

Esta implementación usa la conversión de modelos Synaptics, versión v3.1.0.

Esta implementación está basada en el sdk v1.5.0.

Consulta la documentación de instalación para obtener información sobre cómo configurar el hardware NPU de la serie SL.

Configuración

Al configurar el detector Synap, debes especificar el modelo: una ruta local.

SSD Mobilenet

Se incluye un modelo synap en el contenedor en /mobilenet.synap y es el que usa este tipo de detector de forma predeterminada. El modelo proviene de Synap-release Github.

Usa la configuración de modelo que se muestra a continuación cuando uses el detector synaptics con el modelo synap predeterminado:

detectors: # requerido
  synap_npu: # requerido
    type: synaptics # requerido

model: # requerido
  path: /synaptics/mobilenet.synap # requerido
  width: 224 # requerido
  height: 224 # requerido
  tensor_format: nhwc # valor predeterminado (opcional. Si cambias el modelo, es requerido)
  labelmap_path: /labelmap/coco-80.txt # requerido

Plataforma Rockchip

La detección de objetos acelerada por hardware es compatible con los siguientes SoCs:

RK3562
RK3566
RK3568
RK3576
RK3588

Esta implementación usa el RKNN-Toolkit2 de Rockchip, versión v2.3.2.

tip

Al usar muchas cámaras, un solo detector puede no ser suficiente para mantener el ritmo. Se pueden definir múltiples detectores siempre que haya recursos de NPU disponibles. Un ejemplo de configuración sería:

detectors:
  rknn_0:
    type: rknn
    num_cores: 0
  rknn_1:
    type: rknn
    num_cores: 0

Requisitos previos

Asegúrate de seguir las instrucciones de instalación específicas de Rockchip.

tip

Puedes obtener la carga de tu NPU con el siguiente comando:

$ cat /sys/kernel/debug/rknpu/load
>> NPU load:  Core0:  0%, Core1:  0%, Core2:  0%,

Modelos compatibles con RockChip

Este config.yml muestra todas las opciones relevantes para configurar el detector y las explica. Todos los valores mostrados son los valores predeterminados (excepto dos). Las líneas que se requieren al menos para usar el detector están marcadas como requeridas; todas las demás líneas son opcionales.

detectors: # requerido
  rknn: # requerido
    type: rknn # requerido
    # número de núcleos NPU a usar
    # 0 significa elegir automáticamente
    # aumentar para mejor rendimiento si tienes una NPU multinúcleo, p. ej. establecer en 3 en rk3588
    num_cores: 0

El tiempo de inferencia fue determinado en un rk3588 con 3 núcleos NPU.

Modelo	Tamaño en mb	Tiempo de inferencia en ms
deci-fp16-yolonas_s	24	25
deci-fp16-yolonas_m	62	35
deci-fp16-yolonas_l	81	45
securevu-fp16-yolov9-t	6	35
rock-i8-yolox_nano	3	14
rock-i8_yolox_tiny	6	18

Todos los modelos se descargan automáticamente y se almacenan en la carpeta config/model_cache/rknn_cache. Después de actualizar SecureVu, deberías eliminar los modelos más antiguos para liberar espacio.
También puedes proporcionar tu propio modelo .rknn. No debes guardar tus propios modelos en la carpeta rknn_cache; guárdalos directamente en la carpeta model_cache u otra subcarpeta. Para convertir un modelo al formato .rknn consulta rknn-toolkit2 (requiere una máquina x86). Ten en cuenta que solo hay postprocesamiento para los modelos soportados.

YOLO-NAS

model: # requerido
  # nombre del modelo (se descargará automáticamente) o ruta a tu propio archivo de modelo .rknn
  # los valores posibles son:
  # - deci-fp16-yolonas_s
  # - deci-fp16-yolonas_m
  # - deci-fp16-yolonas_l
  # tu yolonas_model.rknn
  path: deci-fp16-yolonas_s
  model_type: yolonas
  width: 320
  height: 320
  input_pixel_format: bgr
  input_tensor: nhwc
  labelmap_path: /labelmap/coco-80.txt

aviso

Los pesos preentrenados de YOLO-NAS de DeciAI están sujetos a su licencia y no pueden usarse comercialmente. Para más información, consulta: https://docs.deci.ai/super-gradients/latest/LICENSE.YOLONAS.html

YOLO (v9)

model: # requerido
  # nombre del modelo (se descargará automáticamente) o ruta a tu propio archivo de modelo .rknn
  # los valores posibles son:
  # - securevu-fp16-yolov9-t
  # - securevu-fp16-yolov9-s
  # - securevu-fp16-yolov9-m
  # - securevu-fp16-yolov9-c
  # - securevu-fp16-yolov9-e
  # tu yolo_model.rknn
  path: securevu-fp16-yolov9-t
  model_type: yolo-generic
  width: 320
  height: 320
  input_tensor: nhwc
  labelmap_path: /labelmap/coco-80.txt

YOLOx

model: # requerido
  # nombre del modelo (se descargará automáticamente) o ruta a tu propio archivo de modelo .rknn
  # los valores posibles son:
  # - rock-i8-yolox_nano
  # - rock-i8-yolox_tiny
  # - rock-fp16-yolox_nano
  # - rock-fp16-yolox_tiny
  # tu yolox_model.rknn
  path: rock-i8-yolox_nano
  model_type: yolox
  width: 416
  height: 416
  input_tensor: nhwc
  labelmap_path: /labelmap/coco-80.txt

Convertir tu propio modelo onnx al formato rknn

Para convertir un modelo onnx al formato rknn usando rknn-toolkit2 debes:

Colocar uno o más modelos en formato onnx en el directorio config/model_cache/rknn_cache/onnx en tu host Docker (esto puede requerir privilegios de sudo).
Guardar el archivo de configuración en config/conv2rknn.yaml (ver a continuación para más detalles).
Ejecutar docker exec <securevu_container_id> python3 /opt/conv2rknn.py. Si la conversión fue exitosa, los modelos rknn se colocarán en config/model_cache/rknn_cache.

Este es un archivo de configuración de ejemplo que debes ajustar a tu modelo onnx específico:

soc: ["rk3562", "rk3566", "rk3568", "rk3576", "rk3588"]
quantization: false

output_name: "{input_basename}"

config:
  mean_values: [[0, 0, 0]]
  std_values: [[255, 255, 255]]
  quant_img_RGB2BGR: true

Explicación de los parámetros:

soc: Una lista de todos los SoCs para los que deseas construir el modelo rknn. Si no especificas este parámetro, el script intentará detectar tu SoC y construirá el modelo rknn para ese.
quantization: true: cuantización de entero de 8 bits (i8), false: flotante de 16 bits (fp16). Predeterminado: false.
output_name: El nombre de salida del modelo. Están disponibles las siguientes variables:
- quant: "i8" o "fp16" dependiendo de la configuración
- input_basename: el nombre base del modelo de entrada (p. ej. "my_model" si el modelo de entrada se llama "my_model.onnx")
- soc: el SoC para el que se construyó este modelo (p. ej. "rk3588")
- tk_version: Versión de rknn-toolkit2 (p. ej. "2.3.0")
- ejemplo: Especificar output_name = "securevu-{quant}-{input_basename}-{soc}-v{tk_version}" podría resultar en un modelo llamado securevu-i8-my_model-rk3588-v2.3.0.rknn.
config: Configuración pasada a rknn-toolkit2 para la conversión del modelo. Para una explicación de todos los parámetros disponibles, consulta la sección "2.2. Model configuration" de este manual.

DeGirum

DeGirum es un detector que puede usar cualquier tipo de hardware listado en su sitio web. DeGirum puede usarse con hardware local a través de un servidor AI de DeGirum, o mediante el uso de @local. También puedes conectarte directamente al AI Hub de DeGirum para ejecutar inferencias. Nota importante: Este detector no puede usarse con fines comerciales.

Configuración

Inferencia con servidor AI

Antes de comenzar con el archivo de configuración para esta sección, primero debes lanzar un servidor AI. DeGirum tiene un servidor AI listo para usar como contenedor Docker. Agrega esto a tu docker-compose.yml para comenzar:

degirum_detector:
  container_name: degirum
  image: degirum/aiserver:latest
  privileged: true
  ports:
    - "8778:8778"

Todo el hardware compatible se encontrará automáticamente en tu host del servidor AI siempre que los runtimes y drivers relevantes estén correctamente instalados en tu máquina. Consulta el sitio de documentación de DeGirum si tienes algún problema.

Una vez completado, cambiar el archivo config.yml es sencillo.

degirum_detector:
  type: degirum
  location: degirum # Establecer al nombre del servicio (degirum_detector), nombre del contenedor (degirum), o un host:puerto (192.168.29.4:8778)
  zoo: degirum/public # El zoológico de modelos públicos de DeGirum. El nombre del zoológico debe estar en formato "workspace/zoo_name". degirum/public está disponible para todos, así que siéntete libre de usarlo si no sabes por dónde empezar. Si no estás obteniendo un modelo del AI Hub, deja esto y 'token' en blanco.
  token: dg_example_token # Para autenticación con el AI Hub. Obtén este token a través de la sección "tokens" en la página principal del [AI Hub](https://hub.degirum.com). Puede dejarse en blanco si estás obteniendo un modelo del zoológico público y ejecutando inferencias en tu hardware local usando @local o un servidor AI de DeGirum local

Configurar un modelo en el config.yml es similar a configurar un servidor AI. Puedes establecerlo en:

Un modelo listado en el AI Hub, dado que el nombre correcto del zoológico esté listado en tu detector
- Si esto es lo que eliges hacer, el modelo correcto se descargará en tu máquina antes de ejecutarse.
Un directorio local que actúe como zoológico. Consulta el sitio de documentación de DeGirum para más información.
Una ruta a algún model.json.

model:
  path: ./mobilenet_v2_ssd_coco--300x300_quant_n2x_orca1_1 # directorio al modelo .json y archivo
  width: 300 # el ancho es el primer número en la sección "int"x"int" del nombre del modelo
  height: 300 # el alto es el segundo número en la sección "int"x"int" del nombre del modelo
  input_pixel_format: rgb/bgr # consulta el model.json para determinar cuál usar aquí

Inferencia local

También es posible eliminar la necesidad de un servidor AI y ejecutar el hardware directamente. El beneficio de este enfoque es que eliminas los cuellos de botella que ocurren al transferir los resultados de predicción del contenedor Docker del servidor AI al de SecureVu. Sin embargo, el método para implementar la inferencia local es diferente para cada dispositivo y combinación de hardware, por lo que generalmente no vale la pena el esfuerzo. Una guía general para lograrlo sería:

Asegurarse de que el contenedor Docker de SecureVu tenga el runtime que deseas usar. Por ejemplo, ejecutar @local para Hailo significa asegurarse de que el contenedor que estás usando tenga el runtime de Hailo instalado.
Para verificar que el runtime es detectado por el detector DeGirum, asegúrate de que el comando degirum sys-info muestre correctamente los runtimes que deseas instalar.
Crear un detector DeGirum en tu archivo config.yml.

degirum_detector:
  type: degirum
  location: "@local" # Para acceder a dispositivos y modelos del AI Hub
  zoo: degirum/public # El zoológico de modelos públicos de DeGirum. El nombre del zoológico debe estar en formato "workspace/zoo_name". degirum/public está disponible para todos, así que siéntete libre de usarlo si no sabes por dónde empezar.
  token: dg_example_token # Para autenticación con el AI Hub. Obtén este token a través de la sección "tokens" en la página principal del [AI Hub](https://hub.degirum.com). Puede dejarse en blanco si estás obteniendo un modelo del zoológico público y ejecutando inferencias en tu hardware local usando @local o un servidor AI de DeGirum local

Una vez que degirum_detector esté configurado, puedes elegir un modelo a través de la sección 'model' en el archivo config.yml.

model:
  path: mobilenet_v2_ssd_coco--300x300_quant_n2x_orca1_1
  width: 300 # el ancho es el primer número en la sección "int"x"int" del nombre del modelo
  height: 300 # el alto es el segundo número en la sección "int"x"int" del nombre del modelo
  input_pixel_format: rgb/bgr # consulta el model.json para determinar cuál usar aquí

Inferencia en la nube del AI Hub

Si no posees el hardware que deseas ejecutar, también existe la opción de ejecutar inferencias en la nube. Ten en cuenta que es posible que debas reducir los fps de detección ya que la latencia de red ralentiza significativamente este método de detección. Para uso con SecureVu, recomendamos encarecidamente usar un servidor AI local como se describe arriba. Para configurar inferencias en la nube:

Regístrate en el AI Hub de DeGirum.
Obtén un token de acceso.
Crea un detector DeGirum en tu archivo config.yml.

degirum_detector:
  type: degirum
  location: "@cloud" # Para acceder a dispositivos y modelos del AI Hub
  zoo: degirum/public # El zoológico de modelos públicos de DeGirum. El nombre del zoológico debe estar en formato "workspace/zoo_name". degirum/public está disponible para todos, así que siéntete libre de usarlo si no sabes por dónde empezar.
  token: dg_example_token # Para autenticación con el AI Hub. Obtén este token a través de la sección "tokens" en la página principal del (AI Hub)[https://hub.degirum.com).

Una vez que degirum_detector esté configurado, puedes elegir un modelo a través de la sección 'model' en el archivo config.yml.

model:
  path: mobilenet_v2_ssd_coco--300x300_quant_n2x_orca1_1
  width: 300 # el ancho es el primer número en la sección "int"x"int" del nombre del modelo
  height: 300 # el alto es el segundo número en la sección "int"x"int" del nombre del modelo
  input_pixel_format: rgb/bgr # consulta el model.json para determinar cuál usar aquí

Modelos

Algunos tipos de modelos no están incluidos en SecureVu de forma predeterminada.

Descarga de modelos

Aquí hay algunos consejos para obtener diferentes tipos de modelos

Descarga del modelo D-FINE

D-FINE puede exportarse como ONNX ejecutando el comando a continuación. Puedes copiar y pegar todo en tu terminal y ejecutar, cambiando MODEL_SIZE=s en la primera línea a tamaño s, m o l.

docker build . --build-arg MODEL_SIZE=s --output . -f- <<'EOF'
FROM python:3.11 AS build
RUN apt-get update && apt-get install --no-install-recommends -y libgl1 && rm -rf /var/lib/apt/lists/*
COPY --from=ghcr.io/astral-sh/uv:0.8.0 /uv /bin/
WORKDIR /dfine
RUN git clone https://github.com/Peterande/D-FINE.git .
RUN uv pip install --system -r requirements.txt
RUN uv pip install --system onnx onnxruntime onnxsim onnxscript
# Create output directory and download checkpoint
RUN mkdir -p output
ARG MODEL_SIZE
RUN wget https://github.com/Peterande/storage/releases/download/dfinev1.0/dfine_${MODEL_SIZE}_obj2coco.pth -O output/dfine_${MODEL_SIZE}_obj2coco.pth
# Modify line 58 of export_onnx.py to change batch size to 1
RUN sed -i '58s/data = torch.rand(.*)/data = torch.rand(1, 3, 640, 640)/' tools/deployment/export_onnx.py
RUN python3 tools/deployment/export_onnx.py -c configs/dfine/objects365/dfine_hgnetv2_${MODEL_SIZE}_obj2coco.yml -r output/dfine_${MODEL_SIZE}_obj2coco.pth
FROM scratch
ARG MODEL_SIZE
COPY --from=build /dfine/output/dfine_${MODEL_SIZE}_obj2coco.onnx /dfine-${MODEL_SIZE}.onnx
EOF

Descarga del modelo RF-DETR

RF-DETR puede exportarse como ONNX ejecutando el comando a continuación. Puedes copiar y pegar todo en tu terminal y ejecutar, cambiando MODEL_SIZE=Nano en la primera línea a tamaño Nano, Small o Medium.

docker build . --build-arg MODEL_SIZE=Nano --rm --output . -f- <<'EOF'
FROM python:3.12 AS build
RUN apt-get update && apt-get install --no-install-recommends -y libgl1 && rm -rf /var/lib/apt/lists/*
COPY --from=ghcr.io/astral-sh/uv:0.10.4 /uv /bin/
WORKDIR /rfdetr
RUN uv pip install --system rfdetr[onnxexport] torch==2.8.0 onnx==1.19.1 transformers==4.57.6 onnxscript
ARG MODEL_SIZE
RUN python3 -c "from rfdetr import RFDETR${MODEL_SIZE}; x = RFDETR${MODEL_SIZE}(resolution=320); x.export(simplify=True)"
FROM scratch
ARG MODEL_SIZE
COPY --from=build /rfdetr/output/inference_model.onnx /rfdetr-${MODEL_SIZE}.onnx
EOF

Descarga del modelo YOLO-NAS

Puedes construir y descargar un modelo compatible con pesos preentrenados usando este notebook que puede ejecutarse directamente en Google Colab.

aviso

El tamaño de imagen de entrada en este notebook está establecido en 320x320. Esto resulta en menor uso de CPU y tiempos de inferencia más rápidos sin afectar el rendimiento en la mayoría de los casos, debido a la forma en que SecureVu recorta los fotogramas de video a las áreas de interés antes de ejecutar la detección. El notebook y la configuración pueden actualizarse a 640x640 si se desea.

Descarga de modelos YOLO

YOLOx

Los modelos YOLOx pueden descargarse desde el repositorio de YOLOx.

YOLOv3, YOLOv4 y YOLOv7

Para exportar como ONNX:

git clone https://github.com/NateMeyer/tensorrt_demos
cd tensorrt_demos/yolo
./download_yolo.sh
python3 yolo_to_onnx.py -m yolov7-320

YOLOv9 para soporte de Google Coral

Descarga el modelo, monta el archivo en el contenedor y proporciona la ruta con model.path. Ten en cuenta que el modelo enlazado requiere un archivo labelmap de 17 etiquetas que incluye solo 17 clases COCO.

YOLOv9 para otros detectores

El modelo YOLOv9 puede exportarse como ONNX usando el comando a continuación. Puedes copiar y pegar todo en tu terminal y ejecutar, cambiando MODEL_SIZE=t e IMG_SIZE=320 en la primera línea al tamaño de modelo que deseas convertir (los tamaños de modelo disponibles son t, s, m, c y e; los tamaños de imagen comunes son 320 y 640).

docker build . --build-arg MODEL_SIZE=t --build-arg IMG_SIZE=320 --output . -f- <<'EOF'
FROM python:3.11 AS build
RUN apt-get update && apt-get install --no-install-recommends -y cmake libgl1 && rm -rf /var/lib/apt/lists/*
COPY --from=ghcr.io/astral-sh/uv:0.10.4 /uv /bin/
WORKDIR /yolov9
ADD https://github.com/WongKinYiu/yolov9.git .
RUN uv pip install --system -r requirements.txt
RUN uv pip install --system onnx==1.18.0 onnxruntime onnx-simplifier==0.4.* onnxscript
ARG MODEL_SIZE
ARG IMG_SIZE
ADD https://github.com/WongKinYiu/yolov9/releases/download/v0.1/yolov9-${MODEL_SIZE}-converted.pt yolov9-${MODEL_SIZE}.pt
RUN sed -i "s/ckpt = torch.load(attempt_download(w), map_location='cpu')/ckpt = torch.load(attempt_download(w), map_location='cpu', weights_only=False)/g" models/experimental.py
RUN python3 export.py --weights ./yolov9-${MODEL_SIZE}.pt --imgsz ${IMG_SIZE} --simplify --include onnx
FROM scratch
ARG MODEL_SIZE
ARG IMG_SIZE
COPY --from=build /yolov9/yolov9-${MODEL_SIZE}.onnx /yolov9-${MODEL_SIZE}-${IMG_SIZE}.onnx
EOF

Detectores Oficialmente Soportados

Detector Edge TPU​

Coral USB simple​

Múltiples Corals USB​

Coral nativo (Dev Board)​

Coral PCIE/M.2 simple​

Múltiples Corals PCIE/M.2​

Combinación de Corals​

Modelos compatibles con EdgeTPU​

Mobiledet​

YOLOv9​

Hailo-8​

Configuración​

YOLO​

SSD​

Modelos personalizados​

Detector OpenVINO​

Modelos compatibles con OpenVINO​

SSDLite MobileNet v2​

YOLOX​

YOLO-NAS​

YOLO (v3, v4, v7, v9)​

RF-DETR​

D-FINE​

Detector Apple Silicon​

Instalación​

Configuración​

Modelos compatibles con Apple Silicon​

YOLO (v3, v4, v7, v9)​

Detector GPU AMD/ROCm​

Instalación​

Configuración de Docker para acceso a la GPU​

Configuración de Docker para reemplazar la versión del chipset GPU​

Verificar si AMD/ROCm está funcionando y encontró tu GPU​

Determinar la versión del chipset de tu GPU AMD:​

Modelos compatibles con ROCm​

ONNX​

Modelos compatibles con ONNX​

YOLO-NAS​

YOLO (v3, v4, v7, v9)​

YOLOx​

RF-DETR​

D-FINE​

Detector CPU (no recomendado)​

Detector Deepstack / CodeProject.AI Server​

Instalación​

Detectores con soporte de la comunidad

MemryX MX3​

Configuración​

MemryX MX3 PCIe simple​

Múltiples módulos PCIe MemryX MX3​

Modelos compatibles​

YOLO-NAS​

Configuración​

YOLOv9​

Configuración​

YOLOX​

Configuración​

SSDLite MobileNet v2​

Configuración​

Usar un modelo personalizado​

Detector NVidia TensorRT​

Generar modelos​

Parámetros de configuración​

Synaptics​

Configuración​

SSD Mobilenet​

Plataforma Rockchip​

Requisitos previos​

Modelos compatibles con RockChip​

YOLO-NAS​

YOLO (v9)​

YOLOx​

Convertir tu propio modelo onnx al formato rknn​

DeGirum​

Configuración​

Inferencia con servidor AI​

Inferencia local​

Inferencia en la nube del AI Hub​

Modelos

Detector Edge TPU

Coral USB simple

Múltiples Corals USB

Coral nativo (Dev Board)

Coral PCIE/M.2 simple

Múltiples Corals PCIE/M.2

Combinación de Corals

Modelos compatibles con EdgeTPU

Mobiledet

YOLOv9

Hailo-8

Configuración

YOLO

SSD

Modelos personalizados

Detector OpenVINO

Modelos compatibles con OpenVINO

SSDLite MobileNet v2

YOLOX

YOLO-NAS

YOLO (v3, v4, v7, v9)

RF-DETR

D-FINE

Detector Apple Silicon

Instalación

Configuración

Modelos compatibles con Apple Silicon

YOLO (v3, v4, v7, v9)

Detector GPU AMD/ROCm

Instalación

Configuración de Docker para acceso a la GPU

Configuración de Docker para reemplazar la versión del chipset GPU

Verificar si AMD/ROCm está funcionando y encontró tu GPU

Determinar la versión del chipset de tu GPU AMD:

Modelos compatibles con ROCm

ONNX

Modelos compatibles con ONNX

YOLO-NAS

YOLO (v3, v4, v7, v9)

YOLOx

RF-DETR

D-FINE

Detector CPU (no recomendado)

Detector Deepstack / CodeProject.AI Server

Instalación

MemryX MX3

Configuración

MemryX MX3 PCIe simple

Múltiples módulos PCIe MemryX MX3

Modelos compatibles

YOLO-NAS

Configuración

YOLOv9

Configuración

YOLOX

Configuración

SSDLite MobileNet v2

Configuración

Usar un modelo personalizado

Detector NVidia TensorRT

Generar modelos

Parámetros de configuración

Synaptics

Configuración

SSD Mobilenet

Plataforma Rockchip

Requisitos previos

Modelos compatibles con RockChip

YOLO-NAS

YOLO (v9)

YOLOx

Convertir tu propio modelo onnx al formato rknn

DeGirum

Configuración

Inferencia con servidor AI

Inferencia local

Inferencia en la nube del AI Hub

Descarga de modelos

Descarga del modelo D-FINE

Descarga del modelo RF-DETR