7.16. Conclusão

Este capítulo percorreu as partes do ml que uma aplicação OpenMV utiliza quando um passo de inferência faz parte do pipeline:

  • Conceitos – o que é uma rede neuronal em termos aritméticos (uma pilha de operadores treináveis que mapeia um tensor para outro tensor), o que a aprendizagem automática alterou em comparação com o processamento clássico de imagem (o algoritmo de resumo escrito por humanos desapareceu, substituído por pesos aprendidos a partir de dados etiquetados), e a demonstração inicial que executa um detetor de faces em poucas linhas de Python.

  • O módulo ml – o objeto ml.Model e as suas propriedades para inspecionar tensores de entrada e saída, os caminhos de ficheiros de modelo que aceita, e onde esses ficheiros residem: uma partição ROMFS só de leitura para execução diretamente a partir da flash, ou qualquer outro sistema de ficheiros MicroPython quando o modelo pode ser copiado para RAM no momento do carregamento.

  • O pipeline de inferência – as três etapas que predict() executa em sequência (pré-processamento, despacho do motor, pós-processamento), o handle de Normalization na primeira etapa, o handle do pós-processador na terceira etapa, e a aritmética de quantização que associa os tensores inteiros executados pela câmara aos valores reais contra os quais a rede foi treinada.

  • Motores de inferência – TFLM (o interpretador de operadores utilizado pela maioria das câmaras), CMSIS-NN (a biblioteca de kernels SIMD subjacente nos Cortex-M), e as NPUs (a Ethos-U55 da Arm na AE3 emparelhada com o compilador offline Vela, e a Neural-ART da ST na N6 emparelhada com STAI e STEdgeAI). O motor é fixo pela câmara; o script não o escolhe.

  • Descodificação da saída – os pós-processadores que transformam tensores de saída brutos em caixas delimitadoras, pontos-chave ou listas por classe, a classe NMS que consolida candidatos sobrepostos, o guia YOLOv8 que mostra como manter a descodificação rápida ao aplicar limiares antes de desquantizar, e o protocolo para escrever um descodificador personalizado quando o catálogo não abrange um modelo.

7.16.1. O que está agora ao alcance

Três coisas para as quais o capítulo prepara:

  • Carregar um modelo treinado e executá-lo. Tudo em /rom/ funciona sem preparação adicional; qualquer ficheiro .tflite compatível fornecido externamente funciona após a ferramenta offline para a câmara alvo (Vela para a AE3, STEdgeAI para a N6) ter produzido o layout correto.

  • Descodificar qualquer tensor de saída. Quando a arquitetura está no catálogo, escolher o pós-processador correto é mecânico: YoloV8 para um modelo YOLOv8, BlazeFace para BlazeFace, e assim por diante. Quando não está, o protocolo writing-your-own define o contrato e o guia YOLOv8 é a referência mais clara de onde copiar.

  • Raciocinar sobre desempenho. Um modelo que executa a 30 FPS numa NPU pode executar a 3 FPS num Cortex-M7; o rácio depende de quanto da rede a câmara consegue descarregar da CPU. A quantização, o posicionamento em ROMFS, a compilação para NPU e a cobertura de operadores do motor alvo são as quatro alavancas, e o capítulo abordou cada uma delas.

7.16.2. Treinar o seu próprio modelo

Este capítulo partiu de um ficheiro .tflite já treinado. Produzir um para uma tarefa personalizada – um novo conjunto de classes de objectos ou um classificador construído com um propósito específico – não implica montar manualmente um pipeline de treino: dois serviços alojados cobrem todo o ciclo, desde a recolha e rotulagem dos dados, passando pelo treino, até à exportação de um modelo que a câmara consegue carregar.

  • Edge Impulse – uma plataforma embedded-ML de ponta a ponta; capture dados da câmara, rotule-os, treine o modelo e exporte um ficheiro .tflite quantizado pronto para o motor de inferência do OpenMV.

  • Roboflow – gestão de conjuntos de dados e anotação com treino alojado, orientada para a detecção de objectos; exporte um modelo YOLOv8 que o pós-processador YoloV8 descodifica directamente.

7.16.3. O módulo ML compõe com o resto da câmara

Uma inferência raramente é executada de forma isolada. O módulo de imagem captura e pré-processa o fotograma, o módulo ml executa a rede, e ulab.numpy realiza qualquer trabalho numérico que nenhum dos dois lados tem incorporado. Um script de deteção típico combina os três: captura com csi, ajuste opcional do fotograma com image, execução de predict(), pós-processamento do resultado com o módulo adequado de ml.postprocessing, e recurso a ulab.numpy para qualquer cálculo personalizado que a aplicação queira sobre as caixas devolvidas pelo pós-processador. Os três módulos partilham o mesmo modelo de memória; as fronteiras entre eles são de cópia zero sempre que possível.