Visão industrial: inspeção visual com IA e visão computacional para controle de qualidade

Os modelos few-shot modernos começam muitas vezes com algumas centenas de imagens; o sistema continua aprendendo em produção.

As câmeras industriais e a iluminação são selecionadas por aplicação. Entregamos o posto de trabalho completo já projetado.

As novas variantes são treinadas rapidamente a partir dos modelos existentes, o que é ideal para produção de alta variedade.

Num servidor bem dimensionado a inferência roda em milissegundos e raramente é a restrição, embora a latência tenha de ser orçamentada posto a posto quando várias câmeras compartilham a mesma GPU. O que decide a resposta é o resto do ciclo: a peça tem de estar parada e iluminada da mesma maneira no instante do trigger, e a decisão de rejeição tem de chegar antes de a peça atingir o ponto de desvio. Se o seu tempo de indexação não deixa margem para isso, a correção é mecânica e não um modelo mais rápido.

Sim, os retrofits são normais, mas o trabalho é sobretudo mecânico e elétrico, não de software. Precisa de um sinal de trigger do PLC ou de um sensor, de um atuador capaz de agir sobre uma rejeição e de uma passagem de cabo até o servidor de inferência. Treinar o modelo costuma ser a parte mais curta do projeto; fazer com que a peça se apresente à câmera sempre da mesma forma em cada ciclo é o que define o prazo.

Tudo o que a câmera não vê. Fissuras internas, porosidade abaixo da superfície, penetração de solda, torque e propriedades do material exigem outra modalidade de ensaio. Um modelo melhor não resolve isso. A visão também tem dificuldade quando o defeito não tem uma assinatura visual consistente, quando o intervalo aceitável é uma questão de gosto humano e não uma fronteira descritível, e quando as peças se apresentam em ângulos imprevisíveis. Defina quais modos de falha você realmente quer detectar antes de especificar o posto.

Uma vez em produção, alguém tem de confirmar ou corrigir as classificações que o sistema assinala como incertas, e é esse feedback que mantém os modelos atualizados. É uma carga recorrente, mas não ocupa um posto em tempo integral. O maior esforço fica mais cedo, nas primeiras semanas, coletando imagens representativas de peças boas e de cada classe de defeito que lhe interessa. Ninguém deve ficar com isso em cima de um turno completo sem tempo atribuído.

Engana-se em dois sentidos, e um se troca pelo outro através do limiar de decisão. Aperte-o e peças boas vão para refugo ou para reinspeção; alivie-o e há defeitos que escapam. Ambos têm de estar visíveis, por isso cada decisão é guardada com a respectiva imagem e as rejeições devem ser auditadas contra o julgamento humano num intervalo definido. Um posto cujas falsas rejeições nunca são revistas acaba sendo um posto que os operadores aprendem a ignorar.

A inferência roda no servidor de visão GPU on-premise, por isso o ciclo de decisão em tempo real nunca sai da fábrica. É isso que mantém a latência suficientemente baixa para uma rejeição inline. As imagens guardadas e as correções dos operadores usadas para retreinar são outra questão: se os modelos forem ajustados pela MSF sobre os seus dados, deixe definido em contrato se essas imagens permanecem nas suas instalações. O resto da plataforma pode ser instalado em SaaS, cloud privada ou on-premise.

É desviada da linha e depois decidida por quem tem essa responsabilidade: refugo, retrabalho ou concessão. O resultado em si segue para o MSF Quality, onde entra nas cartas de SPC e pode levantar automaticamente um registro de não conformidade. O que não é automático é a escalação quando uma classe de defeito começa a ter tendência, por isso combine o destino das peças e o caminho de escalação antes de montar a câmera.