Uma fila, uma caixa-preta, um arquivo histórico, uma transmissão em camadas — e, na segunda rodada, buracos remendados com física, sensores casados com certificado e frotas somadas sem ver o dado. As peças de infraestrutura de sempre, reconstruídas sobre um compressor que promete (e prova) o erro máximo. Escrito para quem não é da área.
Todo sensor fala demais. Um robô, um navio, um medidor de luz — todos produzem milhares de números por segundo, e guardar ou transmitir tudo custa caro. Comprimir é a saída óbvia, mas há um dilema: os compressores sem perdas (tipo zip) devolvem o dado exato, só que em dado de sensor a taxa de compressão sofre — o ruído de medição não comprime; já os compressores com perdas encolhem muito mais, mas o dado que sai não é o que entrou, e ninguém te diz quanto ele mudou.
Nossa peça central (o TUBE) fica no meio do caminho, com uma promessa diferente: comprime com um erro máximo garantido e declarado. É como dizer "esta balança pode errar no máximo 2 gramas, e isso está escrito no certificado". Qualquer pessoa pode verificar a promessa depois, com matemática, sem confiar em quem gravou. Os quatro sistemas novos pegam essa promessa e a transformam em peças de infraestrutura que todo mundo usa — fila, caixa-preta, arquivo histórico, transmissão — mas com o certificado embutido.
Imagine que o robô manda dados por uma internet ruim. Quando a conexão aperta, uma fila comum só tem duas saídas: descartar dados novos ou descartar dados velhos. Nos dois casos, buracos — trechos em que ninguém nunca saberá o que aconteceu.
O SLUICE tem uma terceira saída: quando o cano aperta, ele diminui a nitidez em vez de jogar fora — e anota na etiqueta de cada pacote quão borrado ele está. Medimos isso com dados reais de robô: numa conexão com menos da metade da banda necessária, a fila comum perdeu 59% dos dados para sempre; o SLUICE entregou 100%, mais borrado nos momentos de aperto, com o grau de borrão declarado e comprovável. Quando a conexão melhora, a nitidez volta sozinha.
O problema. Aviões têm caixa-preta; carros modernos têm um gravador de evento; robôs e máquinas industriais precisam do equivalente. Mas memória é finita. A solução universal é o "gravador de loop", igual câmera veicular (dashcam): quando o cartão enche, apaga-se o mais antigo. O defeito é óbvio: o que foi apagado sumiu para sempre. Se o problema começou 10 minutos antes do acidente, essa história já morreu.
A ideia. Pense num álbum de fotos com espaço fixo. O álbum comum, quando enche, rasga as fotos antigas. O COFFER, em vez de rasgar, troca a foto antiga por uma versão de menor resolução — que ocupa menos espaço — e libera lugar para as novas. O passado não desaparece: ele desbota, gradualmente, e o rótulo de cada foto diz exatamente o quanto. O recente fica nítido; o antigo fica embaçado mas presente; e nada é mentira, porque o grau de embaçamento é certificado e verificável. Medimos com dados reais de um sensor de movimento: num espaço onde o gravador de loop guardava 106 segundos de história (e havia queimado 22 para sempre), o COFFER guardou a gravação inteira — o recente em alta definição, o resto em definição reduzida e declarada.
Refinamento 1: a zona intocável. Descobrimos um defeito na primeira versão: sob aperto contínuo, ela embaçava até o que tinha acabado de chegar — e numa investigação de acidente, o momento do acidente é justamente o fim da gravação. Criamos então uma zona protegida: os últimos X segundos nunca desbotam, aconteça o que acontecer. Medido: proteger os últimos 10 segundos custou só 8 segundos de história antiga — quase de graça. E aprendemos um limite interessante: proteger demais é pior que proteger na medida — a zona grande demais não cabe no espaço e o sistema avisa (nunca falha em silêncio: ele registra formalmente "não consegui cumprir a proteção aqui").
Refinamento 2: o marcador de incidente. A zona protegida só cuida do fim da gravação. Mas e um susto que aconteceu no meio da viagem? Dois minutos depois, ele já saiu da zona e desbotou. A solução: o próprio compressor funciona como detector de sustos — momentos agitados custam mais bytes para comprimir, então um pico no custo de compressão é um alarme de graça, sem hardware novo. Quando dispara, o sistema "pina" aquela janela (incluindo os segundos anteriores ao susto, que ainda estão nítidos no álbum): fotos pinadas nunca desbotam, onde quer que estejam no passado. O teste decisivo: um solavanco real aos 8 segundos de uma gravação de 2 minutos. Ao final, com memória apertada, todas as políticas comuns tinham perdido ou embaçado completamente aquele trecho — a versão com marcador entregou os 15 segundos do incidente em nitidez máxima, dois minutos depois, gastando só 12% do espaço com proteções.
Refinamento 3: calibrar o alarme (a parte mais honesta). O alarme simples era como um detector de fumaça mal regulado: sensível demais dispara com torrada (num dos sensores, chegou a "proteger" 84% de tudo — o que é o mesmo que não proteger nada); insensível demais não dispara nunca. Duas correções medidas: o limiar passou a se auto-calibrar pelo comportamento típico de cada sensor, e ganhou um orçamento de proteção (no máximo ~15% do álbum pode estar pinado — só os sustos mais fortes ganham a vaga). E a melhor versão usa votação entre sensores: o solavanco de verdade aparece no giroscópio E no acelerômetro ao mesmo tempo; o falso alarme aparece só em um. Com 6 sensores votando e 24 KB de memória total — menos que esta página — o incidente do meio da gravação saiu nítido em todos os 6. Há também um botão de alarme externo (tipo o sinal do airbag do carro), que fura qualquer regra.
Por que isso importa. Regulamentos de gravadores de acidente (nos EUA, por exemplo) já especificam a precisão exigida de cada sinal gravado. O COFFER é, até onde sabemos, o único desenho em que a resposta do gravador vem com certificado matemático de fidelidade por trecho — inclusive do trecho desbotado.
Todo sistema de monitoramento guarda histórico do jeito "camadas de sedimento": a semana atual em detalhe, o mês em médias de 5 minutos, o ano em médias de hora. O problema: a média esconde os extremos. Se você perguntar "qual foi o pico de consumo em março?", o arquivo responde com convicção — e errado, porque o pico foi diluído na média. Medimos essa mentira com um ano de dados reais de energia: num caso, o arquivo tradicional errou o pico em 2,42 kWh respondendo com cara de exato; nosso sistema teria respondido "está entre tal e tal valor", com uma janela de incerteza 300× menor que aquele erro — e em 3.000 perguntas de teste, a resposta verdadeira esteve dentro da janela prometida 3.000 vezes.
O STRATA também envelhece os dados (detalhe recente, resumo antigo), mas cada camada carrega seu certificado, e toda resposta vem com a margem declarada. De quebra, resolvemos os problemas de engenharia de gravar isso em disco de verdade: sobrevive a queda de energia no meio da escrita e não desperdiça o disco reescrevendo (o custo de escrita caiu de ~150× para ~4×).
A quarta ideia: transmitir em camadas, como TV por assinatura — o painel de controle recebe a versão econômica, a auditoria recebe a versão completa. Elegante no papel. Construímos, medimos... e a alternativa mais simples (transmitir duas versões separadas) ganhou em todas as métricas. Escrevemos isso na primeira linha da documentação e congelamos o projeto.
Vale destacar para quem é de fora: esse é o método funcionando, não falhando. Cada ideia aqui vira um protótipo pequeno com números; o que os números aprovam avança (o COFFER avançou 4 vezes), o que eles reprovam é enterrado com lápide explicativa — barato, rápido e sem apego. O WEIR custou horas, não meses, e deixou dois legados: confirmou por caminho independente a tese do SLUICE ("borrar certificado é melhor que perder"), e documentou o beco para ninguém entrar nele de novo.
CAULK — o buraco com garantia (e o detetive acidental). Mesmo com fila e caixa-preta, buracos acontecem: um corte de energia, um descarte alheio. A pergunta: dá para preencher o buraco com garantia? A resposta veio da física: um motor não teleporta — se a engenharia assina a velocidade máxima da junta (está no datasheet), o trecho perdido entre dois pontos conhecidos tem uma faixa provável de onde o valor esteve. Medimos e fomos honestos duas vezes: para buracos longos em sinais rápidos, a faixa fica larga demais para servir — reprovado com número, como manda o método. Mas apareceram dois ouros que ninguém planejou: reamostrar com garantia (guardar 1 de cada 4 amostras e responder as outras com faixa provada) e — a surpresa da rodada — o detetive de emendas: quando a física assinada diz "impossível", é porque o dado tem um teleporte. Rodamos num dataset público de treino de robôs: as 39 violações encontradas eram exatamente as 39 emendas de gravação do dataset, com zero alarmes falsos em 360 controles. Auditoria de proveniência de dados de treino, de graça.
SPLICE — casar dois sensores sem chutar. Todo robô precisa juntar leituras de sensores diferentes ("o que a câmera via quando a roda travou?"). O jeito universal é casar pelos relógios — assumindo que eles batem. Medimos num barramento real de carro: o método padrão casa errado 43,8% dos pares, em silêncio. O SPLICE trata cada carimbo de tempo como uma faixa de incerteza e classifica cada casamento: certo, ambíguo (e diz quais são os candidatos) ou impossível — e provamos que o par verdadeiro nunca fica de fora (254.633 de 254.633 nos testes). Da medição saiu uma régua simples de comprar relógio: a classe de sincronização sustenta fusão certificada até uma taxa ≈ 1/(4× a incerteza) — relógio de internet comum só casa sensores lentos; sensor rápido exige sincronização fina. E uma surpresa: no barramento do carro, o gargalo nem era o relógio — as mensagens chegam tão embaralhadas que 4 em cada 5 casamentos são intrinsecamente ambíguos; onde o SPLICE diz "ambíguo", o método padrão sempre esteve chutando.
TRESTLE — a frota inteira sem puxar o dado. 200 medidores de energia, um ano de dados, e a pergunta "quanto a frota consumiu em março?". Em vez de subir tudo para a nuvem, cada medidor sobe só um resumo certificado minúsculo (menos de 1 byte por amostra — 12× menos que o dado cru) e a nuvem responde com a faixa garantida de conter a verdade: 2.000/2.000 nas perguntas de teste. O dado cru nunca sai da borda — privacidade de brinde. E este projeto rendeu a lição mais fina da rodada: o primeiro número feio (faixa larga quando a janela pedida cortava um bloco no meio) não se consertou com mais dados, e sim mudando o contrato da resposta — em vez de responder "±107% da janela que você pediu", responder "o total exato de uma janela deslocada em até 5 h, com o deslocamento declarado". Para fechamento de contas, a resposta exata e declarada vale mais que a resposta larga na pergunta original. Custou 15 linhas de código.
TUBE2D — imagens com garantia por pixel. O compressor nasceu para séries de números (1D). Expandimos para imagens — mapas de profundidade de câmera, matrizes de sensores — com a mesma promessa: cada pixel a no máximo ε do real, provado. Entramos esperando perder do especialista da área (declaramos isso por escrito antes) e vencemos nos quatro casos testados — inclusive em vídeo de profundidade, onde cedemos ao concorrente a vantagem do tempo e ganhamos assim mesmo (1,24–1,33×). E a consulta que importa para a garra do robô já funciona: "esta região esteve toda dentro de ±5 mm?" respondida sem descomprimir, com certificado.
As duas reprovações honestas valem tanto quanto as vitórias. Primeira: no dado de fibra óptica (canais×tempo), o 2D perde do nosso próprio 1D — mais dimensão não é grátis. Segunda: a predição temporal em vídeo de profundidade rendeu nada (1,001×) — e a causa medida é bonita: o sensor Kinect "pisca" entre quadros 6–9× mais que a tolerância; nem câmera parada salva, porque o piscar não para. A lição da rodada: o eixo que paga é o que o sensor correlaciona, não o que a intuição espera — só medindo se descobre.
PILE — o 3D que prova ausência. Nuvens de pontos (LiDAR, o "radar de laser" de robôs e carros autônomos) comprimidas com erro máximo por coordenada — e o produto de verdade: a prova de ausência. "Nenhum obstáculo dentro da zona de segurança" deixa de ser uma consulta de boa-fé e vira um veredito com garantia: VAZIA-PROVADA, OCUPADA-PROVADA ou INDECIDÍVEL — e em 1.800 consultas de teste contra dados reais de LiDAR, zero falsos negativos. É a evidência que os padrões de segurança de robôs e veículos autônomos pedem, assinável.
Em tamanho, empatamos com o especialista da área (Draco, do Google) — e no dado denso fino, ganhamos (0,65 vs 0,79 byte/ponto). E o dial de precisão se comporta como deve: com ε adequado, quase tudo é decidido; com ε grosso demais, o sistema declara que não pode afirmar em vez de errar. Os próprios testes de invariante pegaram dois bugs reais antes de qualquer commit — inclusive um que aprovaria zona "ocupada" falsa por um detalhe de geometria. Sem a exigência dos 100%, teriam passado.
De onde vêm os números. Tudo nesta página foi medido em dados reais (IMU de robô a 203 Hz, juntas de braço robótico, barramento CAN de carro, um ano de consumo elétrico de Londres, vídeo de profundidade Kinect/TUM, LiDAR KITTI) e está commitado com as medições em MEDIDO.md nos repositórios sluice, coffer, strata, weir, caulk, splice, trestle, tube2d e pile — vinte e três incrementos, cada afirmação com o experimento que a sustenta, incluindo as que deram errado.