Protótipo de segurança anti-esmagamento em plataforma tesoura (ToF + ESP32)

Oi — quem escreve aqui é o criador deste site da Acesso Equipamentos. Além de cuidar da locação de plataformas no dia a dia, eu também prototipo coisas de segurança no tempo livre. Este post é sobre um projeto meu: um sistema anti-esmagamento para plataforma tesoura. Não é produto certificado. É protótipo — Blender + ESP32 + sensores — para entender o problema de verdade: geometria. Onde apontar o sensor, o que o campo de visão enxerga, e como cobrir o volume do cesto sem confundir parede, teto ou o próprio operador.

O problema que eu queria resolver

Na elevação, o risco clássico é o cesto (ou o operador) se aproximar demais de um teto, uma viga ou uma estrutura acima. Muita gente pensa “é só medir distância”. Na prática, um sensor 1D só devolve um número — e esse número pode ser parede ao lado, sol no FoV, ou ferramenta dentro do cesto. Minha premissa desde o começo: a montagem eletrônica é viável. O que define se o sistema funciona no campo é onde o feixe olha e como você interpreta o hit. Por isso os sensores ficam no topo do guarda-corpo, apontando para cima. Operador e ferramentas dentro do cesto ficam, em regra, abaixo do plano de emissão — isso reduz (não elimina) falso positivo por ocupação do cesto.

Máquina de referência e cobertura do cesto

Usei as dimensões oficiais da Skyjack SJIII 3226 no Blender. O MVP cobre o volume total do cesto — fixo + ponta — com três ToF VL53L1X (~27° de FoV):

• Ponta_A no deck fixo (traseira)

• Meio no deck fixo

• Ponta_B na extensão (roll-out) — anda com o deck, com cabo em folga

Essa última decisão parece detalhe, mas não é: se a ponta abre e o sensor fica para trás, você perde a cobertura exatamente onde o operador costuma trabalhar.

Como eu “penso” o obstáculo (sem trilateração clássica)

Trilateração clássica assume três sensores vendo o mesmo ponto. Com teto plano, cada ToF vê um ponto diferente do mesmo plano. Com parede lateral, muitas vezes só um FoV “raspa” a fachada. Então o firmware faz outra coisa:

• Calcula o ponto de impacto a partir da pose do sensor e da distância

• Pergunta se esse ponto está no envelope (prisma) acima do cesto

• Classifica teto × parede × fora de escopo

• Só então aplica faixas de severidade

Em português claro: parede ao lado não deve travar a subida. Teto fechando com a elevação, sim — e o bloqueio só quando a colisão está iminente.

Faixas pensadas para o operador conseguir trabalhar

A máquina não pode travar na altura normal de serviço. O operador de ~1,80 m precisa alcançar o que está acima. Por isso as faixas (fonte da verdade no firmware) são:

• Livre: distância > 2,50 m

• Amarelo: ≤ 2,50 m — atenção, ainda sobe

• Vermelho: ≤ 1,20 m — aperto + buzzer, ainda sobe

• Bloqueio: ≤ 0,60 m — colisão iminente, trava a subida

Bloqueio só no extremo. Antes disso, aviso. Histerese de liberação em 0,75 m para não ficar “piscando” o relé.

Ultrassônico × ToF — por que o MVP vai de VL53L1X

No Blender eu modelei os dois: lóbulo ultrassônico mais “largo” versus cone óptico do ToF (~27°). O ToF encaixa melhor no volume do cesto e spamma menos o entorno. Ultrassônico ficou como referência visual / comparativo.

O hardware do SafeAlert MVP

Do lado eletrônico, o arranjo é bem direto:

• ESP32-S3 como cérebro

• TCA9548A (mux I2C) porque os três VL53L1X compartilham endereço

• LEDs de estado, buzzer e relé a contatos secos para simular o bloqueio de subida

Orçamento-alvo de hardware na casa dos R$ 300–400. Caixa IP65 perto do painel do cesto; sensores no rail com cabo Cat; Ponta_B com laço de folga ≥ ~0,9 m na extensão.

O que ainda é desafio de campo

Alguns limites eu já documentei de propósito, para não romantizar o protótipo:

• Sol direto em ~940 nm mata alcance do VL53L1X — capuz/sombra ajudam mais que “só filtro”

• Chuva e poeira na janela óptica viram leitura fantasma ou falha muda

• Protoboard aberta = bancada; campo pede housing e cover glass

• Isso não é função de segurança certificada (EN 280 / ISO 13849 / SIL-PL ficam no roadmap de produto)

Regra de projeto: leitura inválida ou ambient saturado → tratar como ameaça / bloquear, nunca como “livre”.

Por que isso aparece no blog da Acesso

Porque vivemos de plataforma elevatória. Quanto mais a gente entende geometria de risco, envelope do cesto e limites reais de sensor, melhor conversamos com cliente, operador e técnico de segurança — mesmo quando a solução do dia a dia ainda é frota bem mantida, NR e treinamento. Se quiser explorar o modelo 3D, o firmware e o README completo, o repositório está aberto no GitHub: Ver o projeto no GitHub E se precisar locar plataforma para obra (com ou sem conversa sobre segurança embarcada), o caminho comercial continua aqui:

Solicitar orçamento de plataformas