Especialização · Sistemas para robôs

Software para robôs: a camada que decide o movimento, o módulo de visão e o de audição. Hoje temos verificação offline e simulação — não temos nada que comande um motor real.

Escrevemos cinemática, verificação de trajetória e simulação física reprodutível, com gates que bloqueiam quando a prova falta. Para visão temos um protótipo com câmara fixa, não em robô. Para áudio em robô não temos nada construído, e a página diz isso em vez de tomar provas emprestadas da telefonia. Não trabalhamos com ROS.

Fale sobre um projeto

Oferta, com condiçõesExecutei hoje tudo o que pode ser executado. A camada de controlo existe e é séria, mas está offline: um módulo próprio de cinemática para um braço com seis eixos, que resolveu 8.400 de 8.400 pontos de trajetória, e um validador de física em MuJoCo 3.10.0 com 34 testes aprovados, mais 14 testes na parte de visualização. Ambos declaram na própria fonte que não têm transporte para hardware e não podem comandar um robot real. À vista temos um protótipo próprio — deteção e seguimento de pessoas numa câmara IP fixa — com um único commit e o diretório de testes vazio. No áudio no robot temos zero: tudo o que está em disco é voz de call-center ou biblioteca telefónica de terceiros, e o único trabalho acústico próprio terminou com um resultado negativo, escrito na aplicação. ROS: zero instalado, zero escrito. A regra exige pelo menos duas implementações próprias para „fizemos”; em controlo tenho-as, mas nenhuma toca no hardware, e as outras duas camadas do serviço estão abaixo do limiar. Portanto: oferta com condições, com os limites desenhados.

O software de um robô tem três camadas que falham de forma diferente: o que vê e ouve, o que decide e o que envia para os motores. Nas duas primeiras temos trabalhos próprios com testes em execução. Na terceira — a ponte para o hardware — não temos nada, e isso é a fronteira do serviço, não um detalhe de implementação. Dois dos nossos códigos dizem-no no próprio cabeçalho, em inglês, exatamente para não poderem ser lidos de forma errada: o módulo de cinemática não tem transporte para hardware e não pode comandar um robô real.

O que existe na parte de movimento é verificação antes do movimento. Um módulo próprio calcula a cinemática direta, o jacobiano e a cinemática inversa para um braço com seis eixos, com uma margem imposta face aos limites de cada eixo, e foi usado para verificar uma trajetória completa: 8.400 pontos pedidos, 8.400 resolvidos, com a velocidade máxima por eixo mantida abaixo de 8% do limite de catálogo. Em separado, um validador de física corre em MuJoCo 3.10.0 no processador, com passo de cálculo de um milissegundo, em seis cenários, cada um duas vezes, com a mesma semente — e as duas execuções dão impressões digitais idênticas. O determinismo não é uma afirmação, é uma comparação de somas de controlo.

Na vertente de visão, existe menos, e é honesto dizer quanto. Um protótipo próprio faz deteção e seguimento de pessoas em streams de câmara IP, com um pequeno detetor da família YOLO, um seguidor multiobjeto, estimativa de postura para cinco estados e controlo de rotação-inclinação-zoom da câmara. Tem um único commit e o diretório de testes vazio. E a diferença entre isto e a visão de um robot é real, não formal: a câmara de um robot move-se com ele, a cena está próxima, a exposição muda a cada passo e o orçamento de latência é outro, porque a imagem tem de chegar a uma decisão de movimento, não a um ecrã. Não temos câmara de profundidade, não temos calibração de câmara, não temos odometria visual.

Na vertente de áudio para robots não temos nada construído, e não vamos emprestar provas de outro lado. Temos trabalho real de voz para telefonia e para assistentes conversacionais, mas um microfone num robot tem outros problemas: o ruído próprio da máquina, ventiladores e servomotores que arrancam exatamente quando o robot se move, a direção de onde vem a voz, o eco na sala e a distância variável. O único trabalho acústico próprio que temos terminou com um resultado negativo, escrito na aplicação, e publicamo-lo como tal — porque um resultado negativo medido é mais útil do que uma promessa.

Qué incluye

El trabajo, por componentes

Verificamos a cinemática antes de mover alguma coisa

Cinemática direta, jacobiano analítico construído a partir de produtos vetoriais, cinemática inversa numérica com quatro posições de arranque e uma margem imposta de 10° face ao limite de cada eixo, com convergência a 0,05 mm por posição. Com ela verificámos uma colocação em 1.331 posições de grelha e um trajeto completo de 8.400 pontos, todos resolvidos. Os resultados: velocidade máxima por eixo a 7,86% do limite de catálogo e margem mínima face aos limites de 19,9°. O relatório escreve por si a sua natureza: screening discreto offline, sem saída para hardware.

Corremos a física separadamente da imagem, e de forma reprodutível

O validador de física é um programa separado da parte visual, em MuJoCo 3.10.0, no processador, com passo de um milissegundo e amostragem a 20 milissegundos. Seis cenários, cada um executado duas vezes com a mesma semente, com impressões idênticas entre execuções. As tolerâncias estão declaradas no código, não subentendidas: deriva de energia abaixo de 1% relativo, penetração no solo abaixo de 3 cm, violação do limite articular abaixo de 0,03 radianos. O que se mede em queda livre é a aceleração do centro de massa, comparada com a gravidade configurada — 9,80665, 1,62 e 3,72076 metros por segundo ao quadrado.

Colocamos uma gate que bloqueia, não uma que apenas etiqueta

O registo de ações exige que cada movimento declare a sua proveniência, e todas as 15 ações registadas estão marcadas como cinemáticas, zero validadas — porque nenhum controlador nelas é conduzido por um simulador de corpos rígidos com limites de atuador e validação de contacto. Sobre isso, uma gate de libertação lê o ficheiro de prova e falha se uma constante chave não estiver calibrada em hardware. Hoje falha: uma única constante de paragem articular, de 5 milissegundos, é declarada no código como parâmetro provisório, não valor medido — e isso basta para que a verificação completa termine com erro. É uma regra escrita por nós contra nós.

Lemos a descrição do robot com parser próprio, e dizemos o que deixa de fora

Para a apresentação e inspeção dos modelos escrevemos o nosso próprio analisador de formato MJCF: corpos, articulações do tipo dobradiça, livre, deslizante e esférica, geometrias, materiais e carregamento das malhas, com cache de geometria. Deixa intencionalmente de fora as geometrias de colisão, porque é um analisador visual, não um de contacto — escrito em código, não descoberto depois. Os modelos usados são os oficiais, com 29 graus de liberdade para o humanoide e 12 para o quadrúpede.

Não confundimos os valores comandados com os medidos

Os ângulos que aparecem no ecrã são os comandados pelo controlador, publicados numa única direção para a interface. Não contêm ruído de encoder, estado medido, binário, velocidade ou temperatura — escrito explicitamente na auditoria técnica do projeto. Essa distinção parece pequena até alguém tomar um gráfico bonito por telemetria de robot; por isso a escrevemos no código, na auditoria e aqui.

Visão: deteção e seguimento de pessoas, em câmara fixa

Um protótipo próprio que recebe streams de câmara IP, deteta pessoas com um modelo pequeno da família YOLO, segue-as entre frames com um seguidor multiobjeto a um limiar de confiança de 0,5, estima a postura em cinco estados — desconhecido, sentado, em pé, a andar, inclinado — e pode rodar a câmara através do protocolo standard de controlo. Corre forçosamente no processador, por causa de uma incompatibilidade assinalada no código. O seu estado real: um único commit e o diretório de testes vazio. É um protótipo, não um módulo de produção, e nunca esteve num robot.

Áudio no robot: dizemos o que falta, em vez de emprestar da telefonia

Não temos detetor de palavra de ativação, não temos detetor de voz executado localmente, não temos formação de feixe, não temos estimativa de direção e não temos código de cancelamento de eco escrito por nós. O que temos na área da voz é para chamadas telefónicas e para assistentes conversacionais: a interrupção do falante faz-se quer pelo detetor do serviço do fornecedor, quer pela pressão de uma tecla no menu telefónico, e o cancelamento de eco vem das bibliotecas do browser ou de uma pilha terceira de telefonia. São coisas reais, mas resolvem outro problema do que um microfone montado numa máquina que se move e faz o seu próprio ruído.

ROS: não temos, e não fingimos que temos

Não está instalado em nenhuma das nossas máquinas e nunca escrevemos um nó, um ficheiro de lançamento ou um pacote próprio. O único pacote com sistema de construção específico de ROS no disco é a descrição pública de um robô industrial, descarregada como ficheiro de modelo e usada exatamente assim, não compilada. Se o seu projeto pressupõe ROS 2 como dado adquirido, é uma informação que deve ter antes da primeira reunião, não depois.

O que aceitamos e o que não aceitamos

Aceitamos: verificação cinemática e de trajetória antes de uma compra, simulação com tolerâncias declaradas, um módulo de perceção medido nos seus dados, e uma ponte para hardware feita em conjunto com o integrador responsável pela segurança. Não aceitamos: escrevermos nós a camada que pára um robô em caso de emergência, prometer um módulo de áudio no robô sem uma medição prévia do ruído próprio da sua máquina, nem dizer que a nossa experiência de voz ao telefone cobre a audição de um robô.

Qué aspecto tiene

El recorrido, paso a paso.

Definimos a tarefa e os limites físicos, depois verificamos se cabem

O que o robô tem de alcançar, em que volume, com que velocidade e que carga. Depois a verificação: cobertura do volume, margem face aos limites de cada eixo, velocidade e aceleração no trajeto, colisões na geometria real como screening. Entregamos o relatório com as suas limitações escritas. Esta etapa tem uma boa relação entre custo e prejuízo evitado, porque é feita antes de uma compra.

Simulamos com tolerâncias declaradas e com determinismo verificado

Cenários, semente fixa, execuções repetidas, comparação de fingerprints, tolerâncias escritas no código. Entregamos também a lista de coisas que a simulação NÃO demonstra — connosco, por exemplo, um validator que confirma a queda livre e a manutenção da posição num plano de teste não confirma a marcha, o contacto complexo ou a dinâmica do atuador, e escreve isso por si.

Construímos a perceção com os seus dados, não com um conjunto público

Um detector que funciona em imagens da internet não diz nada sobre a sua nave. A etapa significa captura do ambiente real, um conjunto de avaliação próprio, uma medida de referência e só depois a escolha do modelo e do local onde é executado. Entregamos os números de referência e o método com que os pode reproduzir, mesmo quando são fracos.

A ponte para hardware — a etapa que nunca fizemos

Escrevemo-la por último e escrevemo-la com condições, porque é a única da lista em que não temos experiência própria. É feita em conjunto com o integrador ou com o fabricante do robô, e as funções de paragem de emergência, limitação e segurança continuam sob a responsabilidade de quem responde pela máquina. O que podemos levar até lá é a camada de decisão, verificada, com a sua interface documentada.

A cadeia de um robot, da esquerda para a direita, com o estado real de cada elo. Visão: protótipo em câmara fixa, um único commit, sem testes. Audição: vazio — nada construído para um microfone numa máquina em movimento. Decisão e cinemática: verificado, com 8.400 pontos resolvidos e com um gate que bloqueia quando uma constante não está calibrada. A última seta, a que vai para os motores, está interrompida: nenhum código nosso tem transporte para o hardware. O desenho foi feito para se ver onde o serviço pára, não para parecer completo.

Os dados

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

A câmara de um robô filma pessoas, e isso muda tudo: Um módulo de visão que deteta e acompanha pessoas produz dados pessoais no sentido próprio da palavra, mesmo que ninguém seja identificado pelo nome. As perguntas colocam-se antes da primeira linha de código: a imagem é guardada ou apenas o resultado, onde é processada, quem tem acesso às gravações, durante quanto tempo são mantidas, o que é mostrado às pessoas filmadas. O nosso protótipo foi construído como experiência técnica, não como sistema em funcionamento, e não o propomos como tal.
No dispositivo ou no servidor — uma decisão de latência, não de preferência: Se a imagem tiver de chegar a uma decisão de movimento, o caminho até um servidor e de volta entra diretamente no orçamento de reação. Se o resultado é apenas mostrado ou registado, o servidor é aceitável. A decisão é tomada a partir do orçamento de latência medido no seu caso, e é escrita. O nosso protótipo corre forçadamente no processador, o que é uma limitação real de velocidade, anotada no código.
As simulações são guardadas com semente e fingerprint: Um resultado de simulação sem a semente do gerador e sem a soma de controlo das entradas não é uma prova, é uma história. Os nossos relatórios de física incluem a semente, o número de execuções por cenário, a versão do motor e o estado de determinismo; os relatórios de cinemática incluem a impressão digital dos ficheiros de entrada. Assim, meses mais tarde, pode verificar-se se uma cifra citada ainda é válida.
Áudio significa gravar uma sala: Um microfone num robot ouve tudo o que acontece à volta, não apenas o comando que lhe é dado. A regra que aplicaríamos é que a gravação contínua não exista por defeito, mas apenas a janela necessária para a decisão, e que o que é guardado para melhoria seja uma escolha explícita, com prazo. Ainda não temos construído um sistema desse tipo, por isso é uma posição declarada, não uma prática demonstrada.
Os modelos e as descrições de robot têm as suas licenças: Os modelos de robot que usamos em simulação provêm de coleções públicas, sob licenças permissivas, e as descrições de robôs industriais são ficheiros públicos dos fabricantes. Não são nossos e não os reclamamos; num projeto seu, a licença de cada fonte externa é verificada antes de entrar no entregável.

Un caso

Uma medição acústica própria que terminou com «não», e por que a publicamos

A situação

Numa aplicação própria de macOS quisemos descobrir se o altifalante e o microfone de um dispositivo de consumo podem ser usados como um sonar simples — um sinal emitido, o seu eco medido, uma distância deduzida. A questão é exatamente a que surge também num robot: quanto pode descobrir sobre o espaço à volta usando hardware áudio que já tem, sem sensores adicionais.

Qué construimos

Construímos a cadeia completa, não um esboço: um sinal varrido de 12 milissegundos que sobe de 2 a 8 quilohertz, com janelamento, emitido a baixa amplitude; correlação cruzada entre o sinal emitido e o gravado; deteção da chegada direta com uma janela de guarda de 1,5 milissegundos, para que os lóbulos laterais da autocorrelação não sejam tomados por eco; procura do eco numa janela de até 60 milissegundos, com limiares separados de correlação e de ganho relativo; velocidade do som corrigida com a temperatura do ar. Quase 800 linhas de Swift, com deteção do trajeto áudio — se o transmissor e o recetor estão em dispositivos diferentes, a geometria é bistática e um único tempo de atraso define uma elipse, não um ponto.

Qué salió

A conclusão está escrita na aplicação, no ecrã que diz o que pode e o que não pode medir: no altifalante e microfone do mesmo computador podem detetar-se alterações grosseiras das reflexões após calibração, porque a latência é relativamente estável. Com auscultadores sem fios, porém, a redução ativa de ruído, a formação de feixe, o codec e a latência variável destroem a medição métrica precisa — por isso podem ser usados para a orientação da cabeça, não como sonar preciso. Escrevemos isto no produto, não numa nota interna.

Qué no dice el caso

O resultado é sobre hardware de consumo através de uma ligação sem fios, não sobre um robot com microfones montados e cablados. O que se transfere não é a conclusão, mas o método: mede-se o canal antes de prometer a função. Para um robot, a mesma investigação começaria pelo ruído próprio da máquina em movimento — e só o resultado dessa medição diria o que é possível.

Perguntas

Lo que nos pregunta la gente antes de llamar

Já colocaram o vosso software num robot físico?

Não. Nenhum código nosso comandou alguma vez um motor real, e dois dos nossos codebases declaram-no mesmo no cabeçalho do ficheiro, para não poderem ser lidos de forma errada. O que executámos foi simulação e verificação offline. Se isso é um problema para o seu projeto, é melhor sabê-lo desde a primeira frase do que descobri-lo na terceira reunião.

Então, concretamente, o que têm?

Três coisas, todas executáveis à sua frente. Um módulo de cinemática para um braço de seis eixos, que verificou um percurso de 8.400 pontos sem qualquer falha, com margem mínima de 19,9° face aos limites dos eixos. Um validador de física em MuJoCo 3.10.0, com 34 testes que passam e com determinismo comprovado por impressões digitais idênticas em execuções repetidas. E um demonstrador no browser com 14 testes, cuja porta de qualificação falha hoje deliberadamente. Mais um protótipo de visão, sobre o qual dizemos abertamente que tem um único commit e nenhum teste.

Trabalham com ROS?

Não. Não está instalado connosco, não escrevemos nenhum nó, nenhum ficheiro de lançamento e nenhum pacote. O único pacote do tipo ROS nos nossos discos é a descrição pública de um robot industrial, descarregada como ficheiro de modelo para os cálculos de cinemática — usada como dados, não construída. Se a sua equipa já trabalha em ROS 2 e isso é um requisito, nós começamos do zero aí, e isso tem de ser contabilizado.

Podem fazer o módulo de visão para o nosso robot?

Com uma etapa de medição antes, não com base no protótipo que temos. O que se transfere dele é a forma de trabalhar — detector, rastreador entre frames, limiar de confiança, onde corre o cálculo. O que não se transfere é a situação: a câmara num robot move-se, o sujeito está perto, a luz muda a cada passo, e o resultado tem de chegar a uma decisão de movimento, não a um ecrã. Além disso, não temos câmara de profundidade, calibração de câmara nem odometria visual em nenhum projeto próprio. A primeira etapa seria captura no seu ambiente e uma medição de referência.

Tem agentes vocais. Não é a mesma coisa que ouvir um robô?

Não, e não queremos que pareça que é. Ao telefone, o canal é conhecido e estreito, o interlocutor está colado ao microfone, e a interrupção do interlocutor é resolvida pelo serviço do fornecedor ou por uma tecla premida. Num robô, o microfone está numa máquina que faz o seu próprio ruído exatamente quando se move, a voz vem de uma direção que muda, a sala produz eco e a distância varia. São problemas de acústica, não de conversa. Poderíamos começar por uma medição do ruído próprio do seu robô — mas seria um trabalho novo, não uma extensão do de telefonia.

Por que publicam uma qualification gate que falha?

Porque a alternativa é ela passar sem significar nada. A nossa gate lê um ficheiro de prova e verifica se uma constante crítica — o tempo de paragem no fim de curso da articulação — foi calibrada no hardware. Não foi: é um valor provisório de 5 milissegundos, colocado para haver uma simulação estável. Enquanto é provisório, a verificação completa dá erro, e todas as ações permanecem marcadas como cinemáticas. O dia em que passar vai significar algo exatamente porque hoje não passa.

O que é que as vossas simulações não demonstram?

Mais do que demonstram, e está escrito nos relatórios. O validador de física confirma a queda livre e a manutenção de posição num plano de teste — não a marcha, não o contacto complexo, não a dinâmica do atuador, não os sensores sintéticos. O screening de trajetória confirma a cinemática e a geometria — não o material, não as mangueiras flexíveis, não os atrasos de processo, não as rampas de arranque-paragem do controlador. E o movimento no browser é uma pré-visualização, não um resultado de simulação.

Precisamos de certificação de segurança. Fazem-na?

Não. A arquitetura de segurança podemos projetá-la — circuito separado do controlo de movimento, controlador de segurança independente, safe torque off, travões com feedback, estados de falha que entram em segurança; isso também fizemos num projeto próprio de máquina. Mas a avaliação de conformidade e a responsabilidade pela máquina colocada no mercado continuam a ser do fabricante ou do integrador. Não assumimos esse papel e não assinamos por ninguém.

Por que é que está escrito «oferta» nesta página?

Porque o serviço tem três camadas e nenhuma ultrapassa por completo o limiar que definimos. No controlo temos dois trabalhos próprios com testes que passam, mas nenhum chega ao hardware. Na visão temos um protótipo com um commit e sem testes. No áudio para robôs temos zero. Poderíamos ter escrito uma página que soa a experiência, usando palavras como «perceção» e «controlo» sem números. Resistiria até à primeira pergunta de um engenheiro.

Em que se baseiam as afirmações acima (17 fontes)

`vision.megapromoting.com` não é um sistema de visãohttps://vision.megapromoting.com · 2026-09-06

16 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.

Como trabalhamos Todos os serviços

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar