TCC Eletrônica Automotiva: veículo de teste com Jetson — arquitetura, HMI e stack de sensores

TCC Eletrônica Automotiva: veículo de teste com Jetson — arquitetura, HMI e stack de sensores

O repositório FATEC_TCC_2022, de Wilson Queiroz de Oliveira e Miguel Balbastro Gomes, é o artefato público de um TCC de Eletrônica Automotiva centrado em um veículo de teste instrumentado com Jetson Nano. Há monografia (PDF/DOCX), apresentação, diagramas elétricos, código para Jetson e Arduino Nano, exemplos de programação e imagens de HMI — inclusive foto do veículo e painéis de controle manual, sensores, detecção de cor e trilha de traffic sign.

Este artigo não resume nem inventa resultados numéricos da monografia. O foco é o que o engenheiro de automação e o projetista de robô móvel precisam ler na arquitetura: como o stack foi fatiado, que papéis cada circuito cumpre, como a HMI organiza teleop e telemetria, e como isso conversa com a linha editorial de sensores em veículos autônomos / AGV do site.

O problema de projeto que o TCC encara

Montar um veículo de teste acadêmico não é “colocar uma câmera no carrinho”. É decidir:

• Quem é o cérebro de alto nível (percepção, HMI, log)?
• Quem é o cérebro de tempo mais duro / I/O (PWM, segurança local)?
• Quais sensores fecham o estado mínimo (atitude, tensão/corrente analógica, posição global, visão)?
• Como um humano assume o controle (teleop) sem desmontar o software a cada ensaio?

A resposta do repositório é um sistema heterogêneo: Jetson Nano no centro da stack Linux/Python; Arduino Nano em pasta dedicada; barramentos I²C para PWM expander, ADC e IMU; UART para GPS; interface de controle via DualShock/PS4 (pyPS4Controller, ds4drv); display OLED para feedback local.

Por que heterogeneidade em vez de “tudo no Jetson”

Concentrar PWM, ADC, teleop e visão num único processo Python no Linux é tentador e frágil. Sob carga de OpenCV, um stall de GC ou um deadlock de thread deixa duty cycle indefinido. Separar papéis — orquestração no Jetson, I/O auxiliar no Arduino — é a mesma lógica de painel industrial: CLP (ou safety) não compartilha CPU com a IHM de engenharia. O TCC materializa essa intuição em escala acadêmica.

Mapa do repositório (o que abrir primeiro)

A existência paralela de programing_examples com conda/PyTorch/PyQt6 mostra uma prática saudável: separar o ambiente de estudo de visão do runtime de bordo. Em veículo, dependências pesadas demais no mesmo Python do serviço de teleop aumentam fragilidade.

Ordem de leitura recomendada para quem vai clonar

1. Foto do veículo e HMIs em images/ — calibra expectativa do que é protótipo vs produto.
2. electric_diagram/ — sem isso, o código é ficção.
3. README de dependências e UART — o chão operacional.
4. code_for_jetson_nano/ e code_for_arduino_nano/ — papéis.
5. Monografia — só aqui busque métricas de ensaio; este artigo não as inventa.

Stack de hardware: papéis, não lista de compras

Jetson Nano (orquestrador)

Roda a stack de percepção e interface. Dependências do README incluem Jetson.GPIO, Jupyter, PCA9685-driver, pyPS4Controller/ds4drv, pyserial, ADS1115, mpu6050-raspberrypi, Blinka, luma.oled, Pillow, etc. Base de SO: JetPack 4.6 ou Ubuntu 20.04 (imagem Qengineering citada). Isso alinha o TCC ao repositório jetson_nano de bancada — mesmo DNA de plataforma.

PCA9685 (PWM / atuadores)

Expansor I²C clássico para múltiplos canais PWM — direção típica: servos e ESCs/motores em plataforma móvel. Decisão de projeto: não saturar GPIO nativo com muitos PWMs gerados por software; concentrar timing de pulso no ASIC do PCA9685 e falar I²C a partir do Jetson. Em veículo de teste, isso simplifica cabeamento e reduz jitter de software no Linux.

ADS1115 (ADC de precisão)

Entrada analógica de 16 bits (I²C) para grandezas que o Nano não mede bem nativamente: divisores de tensão de bateria, sensores analógicos de corrente, potenciômetros de calibração. Em eletrônica automotiva de bancada, “saber a tensão do pack” é tão vital quanto a câmera — brown-out explica “bug de software fantasma”.

MPU6050 (IMU)

Acelerômetro + giroscópio I²C para atitude e dinâmicas de curto prazo. No stack AV/AGV, IMU é o complementary clássico de odometria e GNSS. No veículo de teste, mesmo sem fusão kalman publicada neste artigo, a presença do sensor sinaliza intenção de estado dinâmico, não só visão reativa.

OLED (luma.oled)

HMI local de baixo consumo: status, modo (manual/auto), falhas de sensor. Complementa a HMI gráfica nas imagens do repo (painéis maiores) com feedback no chassi quando não há monitor HDMI.

GPS UART (/dev/ttyTHS1)

O README documenta sudo chmod 666 /dev/ttyTHS1 — detalhe operacional que todo mundo esquece até o ensaio em campo. GNSS no veículo de teste ancora trajetos e valida deriva; a escolha UART na UART hardware do Jetson (THS) evita adaptadores USB frágeis em vibração.

Controle PS4 + Arduino Nano

Teleop com controle de jogo é pragmático em protótipo: ergonomia boa, latência aceitável em lab, libs Python maduras. O Arduino Nano no repo reforça o padrão SBC + MCU: funções que não devem morrer com um travamento do userspace Linux (ou que falam com periféricos específicos) migram para o 8-bit/AVR.

Tabela de decisão: quem fala com quem

Essa tabela é o coração arquitetural. Componentes isolados são commodities; o fatiamento é o projeto.

HMI: três planos visíveis nas imagens

As capturas referenciadas no README — controle manual, dados de sensores, color detection — descrevem uma HMI de ensaio, não um cluster automotivo final:

1. Plano de comando: modo manual, eixos do controle, enables de motor.
2. Plano de telemetria: IMU, analógicos, GPS, estados I²C — o operador vê se o hardware “está vivo” antes de culpar o algoritmo.
3. Plano de percepção: saída de visão (cor, e a trilha traffic_sign citada) para validar o pipeline óptico sob iluminação real.

Essa separação é ouro em campo: misturar botão de emergência visual com heatmap de rede na mesma tela confunde o piloto de teste. Em produto industrial, o equivalente é HMI de operação vs HMI de engenharia.

Armadilhas de HMI de ensaio

Diagramas elétricos: a verdade que o código não conta

A pasta electric_diagram é onde se decide se o sistema é reproduzível. Pontos de checagem típicos em revisão de projeto (aplicáveis a qualquer clone sério do TCC):

• Estrela de terra entre Jetson, PCA9685, ADS1115, motors drivers e fonte.
• Alimentação lógica 3,3/5 V vs potência de tração — nunca compartilhar de qualquer jeito sem projeto.
• Pull-ups I²C, comprimento de barramento, endereços sem colisão.
• Blindagem/roteamento UART GPS longe de ESC chopper.
• Fusíveis e E-stop no caminho de potência.

Sem diagrama, o repositório vira coleção de scripts. Com diagrama, vira plataforma de teste.

Checklist de comissionamento (lab → primeiro rolamento)

1. Fonte lógica estável; medir rail sob carga de CPU/GPU (jtop ajudando).
2. Pack / tração com fusível; E-stop corta potência, não só “para o Python”.
3. Scan I²C: PCA9685, ADS1115, MPU6050 presentes nos endereços esperados.
4. GPS: permissão UART correta; NMEA chegando antes de culpar o parsing.
5. Teleop: modo manual validado com rodas no ar antes do chão.
6. Visão: iluminação do ensaio real, não só webcam de mesa.
7. Só então cruzar com procedimentos da monografia para métricas — sem inventar números aqui.

Ligação com a editorial de sensores AV

O site Wilson já discute stack de sensores em veículos autônomos (câmera, LiDAR, radar, ultrassom, IMU/GNSS, odometria). O TCC se encaixa como implementação didática de um subconjunto:

Não há pretensão de ASIL nem de fusão completa no discurso deste artigo. Há pretensão de honestidade arquitetural: um estudante (e um time de P&D) consegue montar um loop fechado teleop+sensores+visão em Jetson e documentar. Isso é o embrião de AGV/AMR e do protótipo 4x4 — não o produto final.

Ponte com jetson_nano e c_cuda

Juntos formam a trilha: medir no desktop → instrumentar o SBC → fechar o loop no chassi.

Troubleshooting típico (sintoma → onde olhar)

A ordem importa: energia e cabeamento mentem mais que modelo de ML em protótipo móvel.

O que deliberadamente não fazer com este material

• Não citar “precisão X%” ou “alcançou Y km/h” sem abrir a monografia e transcrever com contexto de ensaio.
• Não tratar dependências pip de 2022 como pin eterno — ao reproduzir, congele versões e teste em JetPack/imagem conhecidos.
• Não copiar chmod 666 em produção — no README é atalho de lab; em produto use udev rules e usuário no grupo dialout.
• Não omitir diagrama elétrico num clone “só de software” — sem terra e rail, o stack é teatro.
• Não vender o TCC como frota ASIL ou how-to de SaaS de autonomia — é veículo de teste acadêmico documentado.

Conclusão

O FATEC_TCC_2022 vale, para a Wilson Tecnologia, como estudo de arquitetura de veículo de teste: Jetson como orquestrador de percepção e HMI; I²C para PWM, ADC e IMU; UART para GPS; teleop PS4; Arduino como parceiro de I/O; diagramas e monografia como âncora formal. É a ponte narrativa entre a bancada jetson_nano, o estudo CUDA de memória, e a linha de sensores para veículos autônomos — sempre com o pé no chão: resultados quantitativos ficam na monografia; aqui fica a decisão de como o sistema foi fatiado.