Como treinar um YOLO11 para detectar defeitos na linha sem sistema caro

A maioria dos sistemas de inspeção visual que chega à fábrica vem com câmera, software e licença amarrados num pacote só, e o preço sobe junto com o número de linhas cobertas. Dá para seguir outro caminho: treinar o próprio modelo de visão computacional (o nome técnico para o software que aprende a reconhecer o que está numa imagem) com fotos das peças que já saem da sua linha, e rodar esse modelo numa câmera de borda, sem depender do fornecedor para cada ajuste de parâmetro.

O modelo que uso neste roteiro é o YOLO11, da Ultralytics, disponível desde 27 de setembro de 2024. Ele detecta objetos numa imagem e desenha uma caixa ao redor de cada um, o que serve tanto para contar peça na esteira quanto para marcar onde está o risco, a rebarba ou a falha de solda. A Ultralytics já lançou uma versão mais nova, a YOLO26, com inferência otimizada para borda, mas o YOLO11 segue como a opção mais madura e documentada, com dois anos de uso real em produção e uma comunidade grande por trás.

Qual tamanho de modelo cabe na câmera da sua linha

O YOLO11 vem em cinco tamanhos, do mais leve (n, de nano) ao mais pesado (x). Quanto maior o modelo, mais preciso ele tende a ser, mas também mais lento e mais pesado para rodar. Os números abaixo são do benchmark oficial da Ultralytics no dataset público COCO, com imagem de 640 pixels:

Esses números valem para 80 classes genéricas do COCO (pessoa, carro, cachorro), não para defeito de peça. Depois de treinar com as suas fotos, meça de novo no seu próprio hardware antes de confiar em qualquer tempo de resposta. Para um piloto, eu começaria pelo n ou pelo s: rodam em CPU comum ou numa placa de borda simples, e dá para medir se o ganho de precisão do m compensa o custo de uma placa com GPU, como uma Jetson.

Passo 1: organizar as fotos das suas próprias peças

O modelo não vem sabendo o que é defeito na sua peça. Isso se ensina com fotos reais da linha, marcadas à mão. O caminho:

1. Fotografe a peça em condições parecidas com as da câmera final (mesma distância, mesma luz, mesmo ângulo), incluindo peças boas e peças com cada tipo de defeito que você quer pegar.
2. Separe as imagens em duas pastas, uma de treino e outra de validação (algo como 80% e 20%).
3. Marque, em cada imagem, uma caixa ao redor de cada defeito e associe a um nome de classe (risco, rebarba, solda_falha e assim por diante). A Ultralytics Platform, da própria Ultralytics, tem uma ferramenta de anotação em nuvem para isso, se você não quiser montar a sua.
4. Crie um arquivo defeitos.yaml listando o caminho das pastas de treino e validação e o nome de cada classe.

Quanto mais variado o conjunto (peças de lote diferente, luz de turno diferente), mais o modelo generaliza. Um conjunto pequeno demais, feito num dia só, tende a aprender o cenário da foto, não o defeito.

Passo 2: instalar o ambiente e treinar

Com o dataset pronto, a instalação é simples:

pip install ultralytics

E o treino parte de um modelo já pré-treinado no COCO, que serve de ponto de partida (isso se chama transferência de aprendizado, e evita treinar do zero):

from ultralytics import YOLO

# carrega os pesos pré-treinados como ponto de partida
model = YOLO("yolo11n.pt")

# treina com o dataset próprio, descrito em defeitos.yaml
results = model.train(data="defeitos.yaml", epochs=100, imgsz=640)

Depois do treino, vale rodar a validação (model.val()) para ver a métrica em cima das imagens que o modelo não viu no treino, separadas por classe de defeito. Se uma classe específica vem com precisão muito baixa, normalmente é sinal de poucas fotos daquele defeito no dataset, não de limite do modelo.

Passo 3: exportar para a câmera de borda

O modelo treinado fica em PyTorch, que não é o formato mais leve para rodar numa câmera industrial ou numa placa de borda. A exportação resolve isso:

from ultralytics import YOLO

model = YOLO("runs/detect/train/weights/best.pt")
model.export(format="onnx")

O formato ONNX roda em praticamente qualquer hardware de borda. Se a placa tiver GPU NVIDIA, como uma Jetson, exportar para TensorRT costuma dar o menor tempo de resposta, no mesmo princípio dos números de T4 da tabela acima. O ideal é testar os dois formatos no equipamento real da linha antes de decidir qual vai para produção.

Onde está o custo de verdade

O YOLO11 é distribuído sob licença AGPL-3.0, que é aberta e gratuita, mas exige que, se você distribuir um produto baseado nele, o código também fique aberto. Para uma linha interna isso raramente é problema, mas se você for embarcar o modelo num produto fechado que vende para terceiros, a Ultralytics oferece licença Enterprise, paga, exatamente para esse caso. Vale checar qual dos dois cenários é o seu antes de colocar em produção.

Fora a licença, o custo real está em cinco itens concretos: a câmera industrial compatível com a velocidade da linha, a placa de borda (uma CPU comum serve para os modelos n e s, uma GPU entra para m, l e x), a integração com o sistema que hoje rejeita a peça (geralmente um CLP), e a pessoa que vai rotular fotos novas e revalidar o modelo de tempos em tempos, porque lote novo de material às vezes muda a aparência do defeito.

Nenhum desses itens tem preço padrão nos documentos da Ultralytics, então o certo é cotar com o fornecedor de câmera e de placa pela sua demanda real, não por tabela genérica.

Segurança: o que muda quando o detector decide sozinho

Se o modelo só mostra um alerta na tela para o analista decidir, o risco é baixo: é uma ferramenta de apoio, como uma lupa digital. Mas se o resultado dele aciona automaticamente o descarte da peça ou interrompe a esteira perto de onde tem gente trabalhando, isso entra no escopo da NR-12, a norma regulamentadora de segurança em máquinas e equipamentos. Nesse segundo caso, o acionamento automático precisa passar por análise de risco formal e, dependendo da máquina envolvida, por dispositivo físico adicional (como cortina de luz ou parada de emergência), não só pelo software de visão.

Meu conselho é começar sempre pelo modo de alerta, com o analista confirmando o descarte, e só migrar para acionamento automático depois que a precisão do modelo estiver validada com volume suficiente de peças e com o setor de segurança do trabalho no projeto desde o início.

Como testar num piloto antes de expandir

Escolha uma linha só e um turno fixo para o piloto. Separe um lote de peças já classificadas por um inspetor humano, que o modelo nunca viu, e compare a decisão do modelo com a do inspetor, defeito por defeito. Acompanhe três números: quantos defeitos reais o modelo pegou (sensibilidade), quantas peças boas ele marcou como defeituosas por engano (falso positivo) e o tempo de resposta por peça na placa de borda real, não no benchmark da tabela.

Se o modelo errar muito numa classe específica, normalmente dá para corrigir com mais fotos daquele defeito e um novo treino, sem mexer em nada do resto do pipeline. Só depois que esses três números estiverem estáveis por um período definido, de uma semana a um mês de produção, faz sentido pensar em levar o mesmo modelo para a linha seguinte.

Fonte: Ultralytics Docs — YOLO11