Jetson Nano na bancada: SBC de percepção, GPIO e ponte para robôs móveis

Jetson Nano na bancada: SBC de percepção, GPIO e ponte para robôs móveis

Há uma geração de engenheiros que trata “visão computacional” como algo que só vive em GPU de rack, e “GPIO” como algo que só vive em Arduino. O Jetson Nano quebra essa falsa dicotomia: é um SBC com GPU Maxwell de 128 núcleos CUDA, CPU ARM Cortex-A57 quad-core, 4 GB LPDDR4, Ethernet gigabit, USB 3.0, HDMI e header de 40 pinos — ou seja, o mesmo tipo de conector mental do Raspberry Pi, com capacidade de acelerar redes e kernels CUDA no próprio chassi.

O repositório jetson_nano documenta a bancada real: pastas c_code, python_code, cyber_nano, pi_pico, andrej_karpathy, eduardo_mendes e docs com foto da placa. Este texto é um estudo de papel do hardware no sistema — percepção + I/O — e de como essa bancada alimenta a linha de robôs móveis / protótipo Jetson 4x4 da Wilson Tecnologia, sem transformar o README curto em artigo clone.

O que a placa é (e o que não é)

É: um computador embarcado orientado a IA e visão, com stack JetPack (CUDA, cuDNN, TensorRT, multimedia) quando a imagem é a oficial NVIDIA, ou uma base Ubuntu 20.04 comunitária (o README aponta a imagem Qengineering Ubuntu 20) quando se prioriza pacotes e fluxo de desktop mais familiar.

Não é: um CLP, um safety controller, nem um substituto drop-in de ECU automotiva. Alimentação, EMI, faixa térmica, watchdog e certificação pedem envelope de produto. Na bancada e no protótipo acadêmico/industrial leve, porém, o Nano é excelente para fechar o loop percepção → decisão → comando de atuador com latência e potência acessíveis.

A foto em docs existe por um motivo editorial: hardware de verdade, com dissipador, cabos e bagunça de bancada. Conteúdo técnico que vende confiança mostra a placa suja de uso, não só o render de marketing.

Limites honestos de envelope

Quem vende o Nano como “ECU de produção” mente. Quem o usa como cérebro de percepção em veículo de teste acerta o papel.

Organização do repositório: mapa de intenções

A estrutura de pastas conta a história melhor que um parágrafo de marketing:

Essa separação importa em time: misturar notebook de curso, driver de PCA9685 e experimento de rede no mesmo diretório root vira dívida em seis meses. O Nano convida ao caos porque “tudo roda na mesma caixa”; o repo mostra a disciplina mínima de fatiar por intenção.

Por que fatiar C e Python no mesmo alvo

Em bancada mista, a tentação é “tudo em Python porque importa rápido”. O problema aparece quando:

• O loop de visão compete com GC e threads do interpretador no mesmo processo que gera PWM.
• Um notebook Jupyter deixa kernels zumbis comendo RAM nos 4 GB.
• O experimento de curso sobrescreve dependências do runtime de teleop.

A regra prática que o mapa de pastas sugere: prototipar em python_code, endurecer gargalos em c_code, isolar estudo em pastas nomeadas, empurrar tempo duro para pi_pico. Não é dogma de linguagem; é higiene de envelope de memória e de falha.

SO, JetPack e a escolha Ubuntu 20

O README fixa Ubuntu 20.04 via imagem Qengineering como base prática. Em Jetson, a decisão de SO não é cosmética:

• JetPack oficial alinha CUDA/TensorRT/multimedia com a release NVIDIA — melhor para demos de inferência e exemplos oficiais.
• Imagem Ubuntu 20 comunitária facilita pacotes apt, fluxos de desktop e experimentos mistos (visão + GPIO + Jupyter) quando a prioridade é bancada de desenvolvimento, não certificação de stack.

Em projeto, documente qual imagem, qual L4T/JetPack e qual power mode. Dois Nanos “iguais” com clocks e nvpmodel diferentes mentem na comparação de FPS. Daí a dependência explícita de jtop (jetson-stats): sem telemetria de CPU/GPU/RAM/temp/power, “otimizei a rede” vira anecdota.

Fluxo típico de bancada (como no README): atualizar sistema, instalar jetson-stats, reboot, e só então medir. Synergy aparece como detalhe humano — compartilhar teclado/mouse com o desktop de desenvolvimento — lembrete de que SBC de visão muitas vezes opera headless ou com monitor compartilhado.

Tabela de decisão: JetPack oficial vs imagem comunitária

Não existe escolha “certa” universal. Existe escolha declarada no README do projeto derivado.

Percepção: onde o Nano ganha o argumento

Para visão embarcada, o Nano compete no espaço “preciso de GPU CUDA + CSI/USB camera + Linux sem carregar um PC industrial de 500 W”. Casos típicos de bancada e protótipo:

• Detecção de cor / segmentação simples para linha ou objeto (como no ecossistema do TCC com HMI).
• Classificação ou detecção leve com modelos otimizados (TensorRT quando o stack permite).
• Pré-processamento CUDA alinhado ao estudo c_cuda (shared memory, streams) quando o gargalo é pipeline, não só “chamar a rede”.

A decisão de projeto não é “Nano vs cloud”. É onde roda a latência crítica. Em AGV/AMR e robô móvel indoor, perder o link Wi-Fi não pode cegar o veículo; percepção local com fallback é arquitetura, não preferência estética.

Pipeline ponta a ponta (o que medir de verdade)

FPS da rede isolada mente. No veículo de teste e no 4x4, o ciclo relevante é:

1. Captura (CSI/USB) e conversão de cor.
2. Pré-processamento (resize, ROI, filtro).
3. Inferência ou algoritmo clássico.
4. Pós-processamento e decisão.
5. Comando (I²C PWM, UART, GPIO) e log.

Se o estágio 1+2 já come metade do budget de 33 ms (30 fps), shared memory no estágio 2 importa mais que trocar modelo no estágio 3. Essa é a ponte direta com streams e overlap do c_cuda: esconder latência de movimento de dados, não só “acelerar a matmul”.

GPIO e o SBC como cérebro de robô

O header de 40 pinos + Jetson.GPIO (visto com força no repositório do TCC) posiciona o Nano como cérebro com mãos. PWM via PCA9685, ADC via ADS1115, IMU I²C, UART de GPS: o padrão é o mesmo de Raspberry, com a diferença de que a mesma placa que lê MPU6050 pode rodar OpenCV acelerado.

A pasta pi_pico no repo é o complemento inteligente: Linux no Nano para percepção e orquestração; MCU (RP2040) para bit-banging, tempos duros ou isolamento de falha. Em robótica móvel industrial, esse padrão “SBC + MCU de I/O” é regra, não exceção — o Pico (ou um Arduino Nano, como no TCC) vira o “CLPzinho” de bordo enquanto o Jetson pensa.

Armadilhas de GPIO na bancada Jetson

GPIO no Nano é poderosa e perigosa: a mesma flexibilidade que monta o protótipo em uma tarde monta um modo de falha silencioso se o Linux congelar com o duty cycle travado.

Ponte para robôs móveis industriais e o 4x4 Wilson

O salto de bancada → produto passa por perguntas que o kit sozinho não responde — e que o site deve ensinar a fazer:

1. Alimentação: buck estável, brown-out, ignição automotiva vs fonte de lab. Nano em protoboard mentiroso some no primeiro motor de tração.
2. Termal: enclosure fechado em veículo 4x4 mata clock; jtop mostra; projeto mecânico resolve.
3. Rede: Ethernet para LiDAR/câmeras industriais; Wi-Fi só para telemetria quando possível.
4. Segurança funcional: o Nano não é ASIL; seja conservador — E-stop hardware, watchdog externo, MCU que corta PWM se o heartbeat do Jetson morrer.
5. Software: serviços systemd, logging, versão de modelo, calibração de câmera versionada — o que separa demo de frota de um.

O protótipo Jetson 4x4 na linha Wilson é a materialização dessa ponte: plataforma móvel onde percepção embarcada, teleop (ex.: controle tipo PS4 no TCC) e stack de sensores coexistem. O repositório jetson_nano é o caderno de bancada dessa família; o FATEC_TCC_2022 é o veículo de teste que amarra diagramas, HMI e monografia.

Decisão: Nano sozinho vs Nano + MCU

A pasta pi_pico no repo aponta a segunda linha — a mais comum em P&D de AMR leve.

Troubleshooting de bancada (sem inventar milagre)

Antes de culpar o modelo de visão:

1. jtop aberto: temperatura, power mode, throttling. FPS que cai depois de 3 minutos costuma ser termal, não “bug do OpenCV”.
2. Memória: 4 GB somem rápido com desktop + browser + Jupyter + rede. Feche o que não é pipeline.
3. Câmera: USB2 em hub barato vs CSI; resolução e exposição mudam o budget de tempo mais que a flag -O3.
4. GPIO permissions / grupo: sintoma “funcionou no reboot com sudo e quebrou no service”.
5. Imagem de SO: misturar tutorial JetPack 4.6 com pacote de imagem comunitária sem anotar versões.

Se o pipeline “às vezes” falha sob motor ligado, olhe alimentação e terra antes de refatorar a rede neural.

Decisões práticas para quem monta a bancada hoje

• Instale jtop antes de qualquer benchmark de visão; anote power mode e temperatura junto do FPS.
• Separe código de curso/estudo (andrej_karpathy, etc.) de código de plataforma (c_code / python_code de produto).
• Trate pi_pico (ou outro MCU) como colega de arquitetura, não como brinquedo paralelo.
• Escolha imagem de SO com critério JetPack vs apt — e pin os hashes/versões no README do projeto derivado.
• Meça o pipeline ponta a ponta (captura → pré → inferência → comando), não só a rede isolada — lição irmã dos streams em CUDA.

O que deliberadamente não fazer

• Não publicar FPS sem resolução, power mode, temperatura e se a medição foi pipeline completo ou só inferência.
• Não tratar o Nano como safety controller nem como drop-in de ECU ASIL.
• Não misturar trilhas de curso com runtime de veículo no mesmo venv/serviço.
• Não alimentar lógica e tração no mesmo nó “porque ligou na protoboard”.
• Não transformar este estudo em how-to de SaaS, cloud labeling ou aluguel de GPU — o tema é SBC de bancada e ponte para robô móvel.

Conclusão

Jetson Nano na bancada da Wilson não é “mini-PC NVIDIA para tutorial”. É o elo entre visão acelerada e GPIO de robô, com repositório que mistura C, Python, MCU auxiliar e trilhas de estudo no mesmo alvo físico. Quem entende essa placa como SBC de percepção — e não só como stick de inferência — está pronto para discutir AGV/AMR, protótipo 4x4 e a editorial de sensores em veículos autônomos com o pé no chão de oficina.