THE CYBER-PHYSICAL CANOPY · DOUTORADO EM CIÊNCIAS AGRÁRIAS

Arquitetura Multimodal para Sistemas IoT com Tomada de Decisão Baseada em Inteligência Artificial Aplicada à Agricultura de Precisão

Análise de viabilidade técnica de uma arquitetura edge-first para decisão tática local em cenários de operação offline ou conectividade de baixa latência, com validação assíncrona via LLM no backend e comunicação MQTT pub/sub.

Farm-LightSeek Tiny-LiteNet AgroLLM + RAG DKPL Firewall YOLO Auditoria MQTT pub/sub

O PROBLEMA

O Gargalo da Nuvem em Ambientes Rurais

Sistemas IoT tradicionais dependem de upload contínuo de imagens HD. No campo brasileiro com conectividade 2G intermitente, isso é inviável — e o custo biológico é real.

☁ A Falsa Promessa

IoT tradicional: upload HD contínuo para a nuvem.
Uma imagem 4K ≈ 10–25 MB. Numa rede rural 2G (50–100kbps) leva minutos para subir.

Resultado: latência inaceitável, sistema paralisado quando sem rede — tolerância a falhas NULA.

🚁 A Solução Farm-LightSeek

Edge-first: inferência on-device em 16ms, sem internet.
Envia apenas metadados leves (~200 bytes) via MQTT.

Ferrugem-asiática avança 1–2 ha/hora. Cada segundo importa. O edge age antes de qualquer upload.

FLUXO COMPLETO

Loop Percepção–Decisão–Ação

🚁 Drone + RPi5

→

📷 Câmera HD

→

🧠 Tiny-LiteNet

→

🗺 Mapa Severidade

→

💊 Pulverização

⇢

📡 MQTT Broker

→

☁ AgroLLM

→

🛡 DKPL + YOLO

→

📊 Relatório

⚡

Princípio Central: Desacoplamento Total

O drone age sem esperar a nuvem. A nuvem pensa sem precisar do drone ativo. Metadados leves conectam os dois mundos via MQTT pub/sub — bilhetes de 200 bytes, não caminhões de dados.

MÓDULO 1

Edge First — Ação Tática Local

O drone opera como um nó de borda cognitivo autônomo. Captura, detecta, decide e age em 16ms — sem internet, sem servidor, sem esperar ninguém.

📷

Captura de Imagem HD · georreferenciada

Câmera conectada ao barramento CSI do RPi5. Captura contínua em voo.

↓

🧠

Tiny-LiteNet / CNN 16ms · 98,6%

1,2 MB · 1,48M params · TensorFlow Lite. Identifica praga, doença, planta daninha.

↓

📦

Geração de Metadados ~200 bytes

Classe, confiança, lat/lon, horário, versão modelo, hash SHA-256 da imagem.

↓

🛡

DKPG Local regras agronômicas

Constraints hard-coded: dose máxima, área de spray, tipo de ação permitida.

↓

🗺

Mapa de Severidade embarcado

Log de pontos: [Latitude, Longitude, Praga, Severidade]. Construído em voo.

↓

💊

Mapa de Prescrição taxa variável

Baixa severidade → não aplicar. Média → aplicar pouco. Alta → aplicar mais.

⚠ Abordagem Realista em Voo

Gerar um ortomosaico georreferenciado completo durante o voo exige processamento enorme. O drone não gera o "mapa visual" completo em tempo real — em vez disso, gera um Log de Pontos de Prescrição: a cada detecção da CNN, o sistema salva [Latitude, Longitude, Tipo de Praga, Severidade].

↓

🚿

Pulverização Localizada spot spraying

Sinal GPIO → Pixhawk → válvula. Aciona em milissegundos na coordenada exata.

↓

💾

Log Local SD/SSD

Imagem original + metadados armazenados. Enviados à nuvem quando conectar.

🗺 Mapa de Severidade (demo)

Representação de um talhão 8×8. Cada célula = ponto de detecção. Passe o mouse para ver a severidade.

■ Saudável ■ Baixa ■ Média ■ Alta

⚙ Hardware: RPi5 como Edge Node

CNN (Tiny-LiteNet) · 16ms · 570MB RAM

↓ libera RAM

Gemma 4 E2B · ~10-20s · 2,5GB RAM

↓ envia metadados, descarrega

MQTT publish · payload ~200B

Estratégia sequencial: nunca simultâneos. Pico RAM: ~4GB < 8GB disponíveis. 4,7W consumo.

📴 Estratégia em Baixa Latência ou Imagens > 25 MB por Disparo Multiespectral

O edge opera indefinidamente sem rede. Quando conectar:

① Payload (~200B) enviado imediatamente via MQTT QoS 1
② Imagens HD enviadas quando houver banda
③ UUID + hash SHA-256 associam imagem ao payload
④ YOLO faz auditoria visual assíncrona na nuvem

COMPARATIVO

IoT Legado vs. Farm-LightSeek

Dimensão	☁ IoT Tradicional	🚁 Farm-LightSeek
Latência de Decisão	Segundos a Minutos	< 16 milissegundos
Dependência de Banda	Crítica — Upload HD	Baixa — Metadados textuais
Tolerância a Falhas	Nula — Offline = Sem Sistema	Alta — Edge autônomo offline
Foco da IA	Visão Genérica	Fusão Multimodal + Raciocínio

NOTA TÉCNICA

Análise Crítica do Hardware e dos Modelos

⚙️

1. O Gargalo do Hardware: Raspberry Pi

O Raspberry Pi (mesmo o modelo 5) não é a placa ideal para processamento de IA pesada em um drone em voo.

⚠ Problema

Consome muita energia, esquenta e a GPU não é otimizada para inferência de redes neurais em tempo real.

✓ Solução Recomendada

Substituir por uma placa Edge AI dedicada: NVIDIA Jetson Orin Nano ou Jetson Nano — feitas para rodar CNNs (YOLO) é necessário apenas se quisermos rodar o Gemma 4 E2B localmente — caso contrário, o RPi5 é a escolha mais eficiente para o Tiny-LiteNet.

🧠

2. O Papel da CNN — Tiny-LiteNet

A CNN é o "olho e cérebro rápido" do sistema. Roda em tempo real (30+ FPS) analisando o feed da câmera. Funciona perfeitamente sem internet.

FUNÇÃO

30+ FPS analisando feed da câmera em tempo real

AÇÃO

Identifica pragas, doenças, plantas daninhas e falhas no plantio

OFFLINE

Gera bounding box e aciona próximo passo sem internet

💬

3. O Papel do Gemma (LLM/VLM) — A Maior Armadilha

Rodar o Gemma (mesmo a versão 2B quantizada) em um RPi é lento — pode levar vários segundos para gerar uma resposta.

✗ O que NÃO deve fazer

Controlar o drone ou tomar decisões táticas em milissegundos. A latência é alta demais para voo em tempo real.

✓ O que PODE fazer (Offline)

Atuar como "agrônomo de bordo" para pós-processamento após o pouso. Ex: "Foram detectados 45 focos de ferrugem no talhão 3, recomenda-se aplicação de fungicida X."

📌 Estratégia correta: CNN detecta a praga em 16ms → aciona pulverização. Gemma é acionado em segundo plano ou após pouso para gerar relatório contextualizado com os dados coletados.

MÓDULO 2

AgroLLM — Motor Cognitivo na Nuvem

Enquanto o edge age por reflexo em 16ms, o backend audita, contextualiza e garante conformidade biológica e legal. Pipeline de 6 etapas com YOLO assíncrono.

1

Ingestão de Dados

Broker MQTT recebe o payload do drone: metadados com image_id, GPS, timestamp, versão do modelo, hash SHA-256, detecções. Pergunta do produtor via dashboard.

2

FAISS RAG — Recuperação Vetorial

Busca em corpus agrícola indexado: literatura peer-reviewed, livros de agronomia, dados climáticos regionais, regulamentos MAPA. Recupera contexto relevante para a detecção.

3

DKPL — Firewall Agronômico

Domain Knowledge Processing Layer. Verifica regras causais e limiares biológicos. Se LLM sugeriu 400kg/ha nitrogênio → DKPL bloqueia → limite é 300kg/ha → regenerar proposta. Proteção contra alucinações.

4

YOLO — Auditoria Visual Assíncrona ★ NOVO

Quando a imagem HD chega à nuvem (delayed transmission), YOLO reanalisa visualmente. Compara com predição do Tiny-LiteNet feita no edge. Confirma · Revisa · ou aponta divergência. Stack: Python · ultralytics · OpenCV.

5

Entrega — Relatório 100% Validado

Relatório técnico seguro enviado ao dashboard do produtor via WebSocket. Rastreável, auditável pelo MAPA, com recomendação estratégica contextualizada no histórico da fazenda.

ALICERCES CIENTÍFICOS

4 Papers Validados

1

Nyakuri et al. (2025) — Tiny-LiteNet

Scientific Reports (Nature) · DOI: 10.1038/s41598-025-06452-5

98,6% acurácia 16ms RPi5 1,2MB

"Prova que o hardware proposto é viável para detecção offline."

2

Samuel et al. (2025) — AgroLLM

Pittsburgh State Univ. + Oxford Brookes University

93% precisão MRR 0,93 RAG+FAISS

"RAG especializado supera LLM genérico em 93% das perguntas agronômicas."

3

Jiang et al. (2025) — Farm-LightSeek

Wuhan Univ. of Technology + Swinburne · arXiv:2506.03168

85,9% VQA ~1B params 3 estágios destilação

"Edge-cloud com MLLM destilado é estado da arte em 2025."

4

Kuska et al. (2024) — AI for Crop Production

Computers & Electronics in Agriculture, 221, 108924 · Germany

4 casos de uso Regras biológicas Regras MAPA

"Justifica nossa DKPL — literatura exige guardrails simbólicos no LLM agrícola."

★ Contribuição Original desta Proposta

Integração do Gemma 4 E2B no edge para raciocínio tático dinâmico · Camada DKPL como firewall agronômico · Acoplamento físico RPi5-drone no contexto brasileiro · Auditoria visual assíncrona (YOLO) com UUID + hash SHA-256.

MÓDULO 5

Alicerces Científicos e Limitações

4 papers peer-reviewed que fundamentam a proposta, a contribuição original e os aspectos de segurança não cobertos pela arquitetura atual.

ALICERCES CIENTÍFICOS

4 Papers Validados

1

Nyakuri et al. (2025) — Tiny-LiteNet

Scientific Reports (Nature) · DOI: 10.1038/s41598-025-06452-5

98,6% acurácia 16ms RPi5 1,2MB

"Prova que o hardware proposto é viável para detecção offline."

2

Samuel et al. (2025) — AgroLLM

Pittsburgh State Univ. + Oxford Brookes University

93% precisão MRR 0,93 RAG+FAISS

"RAG especializado supera LLM genérico em 93% das perguntas agronômicas."

3

Jiang et al. (2025) — Farm-LightSeek

Wuhan Univ. of Technology + Swinburne · arXiv:2506.03168

85,9% VQA ~1B params 3 estágios destilação

"Edge-cloud com MLLM destilado é estado da arte em 2025."

4

Kuska et al. (2024) — AI for Crop Production

Computers & Electronics in Agriculture, 221, 108924 · Germany

4 casos de uso Regras biológicas Regras MAPA

"Justifica nossa DKPL — literatura exige guardrails simbólicos no LLM agrícola."

★ Contribuição Original desta Proposta

Integração do Gemma 4 E2B no edge para raciocínio tático dinâmico · Camada DKPL como firewall agronômico · Acoplamento físico RPi5-drone no contexto brasileiro · Auditoria visual assíncrona (YOLO) com UUID + hash SHA-256.

NOTA TÉCNICA

Limitações Identificadas

🔐

Aspectos de Segurança não cobertos pela arquitetura atual

A arquitetura não menciona aspectos de segurança, como autenticação e autorização no backend. Pontos que demandam atenção em implementação real:

① Autenticação dos publishers MQTT (drones) junto ao broker
② Autorização por tópico — cada RPi deve publicar apenas no seu tópico
③ TLS/SSL na comunicação MQTT (porta 8883) e WebSocket (wss://)
④ Controle de acesso ao backend FastAPI (JWT / OAuth2)
⑤ Integridade do payload — o hash SHA-256 já presente é um primeiro passo, mas não substitui assinatura criptográfica

MÓDULO 3

Arquitetura Física: Edge + Broker + Cloud

Servidor centralizado com broker MQTT como middleware pub/sub. Cada RPi autônomo no campo publica eventos. O servidor único processa tudo. Dashboard = cliente WebSocket.

📡 Fluxo Pub/Sub via Broker MQTT

🚁

RPi #1

Campo Norte

publish

🚁

RPi #2

Campo Sul

publish

🚁

RPi #3

Estufa

publish

MQTT pub →

🖥

Broker MQTT

Mosquitto/EMQX

porta 1883

agro/perception/#

→ subscribe

☁

Cloud Backend

Servidor Único

RAG Engine · FAISS DKPL Firewall PostgreSQL

WebSocket →

📱

App Móvel

Agrônomo

💻

Dashboard

Pesquisador

👨‍🌾

Portal

Fazendeiro

ESTILOS ARQUITETÔNICOS

Arquitetura Híbrida em 4 Padrões

1. Event-Driven (EDA)

Edge detecta praga → PUBLICA evento no broker MQTT. Cloud NÃO fica perguntando "tem novidade?". Cloud INSCREVE no broker → recebe quando acontece. Comunicação assíncrona e desacoplada.

2. Layered Architecture

Sistema dividido em camadas hierárquicas:
Edge → Broker → Cloud → Dashboard
Fluxo unidirecional. Cada camada com responsabilidade clara.

3. Pipeline Architecture

Dados fluem por estágios sequenciais de transformação:
Câmera → CNN → DKPG → Mapa → Ação

4. Guardrails Pattern

Defesa em profundidade em 2 níveis:
Edge: constraints hard-coded no hardware
Cloud: DKPL valida e YOLO audita visualmente

STACKS TECNOLÓGICAS

Componentes por Camada

🚁 Edge Stack (RPi5)

Runtime

Python 3.11+

Visão

OpenCV · Tiny-LiteNet · TF Lite

LLM Local

Gemma 4 E2B · Ollama

Guardrails

Pydantic · regras custom

Comunicação

Paho MQTT (cliente)

☁ Backend Stack (Linux)

IA Orquestração

LangChain · LangGraph

RAG

FAISS vector DB

API

FastAPI · Pydantic

Broker

Mosquitto / EMQX

Persistência

PostgreSQL · Redis

Dashboard

Plotly Dash (real-time)

📡

STACK DE PROTOCOLOS — se perguntado sobre comunicação

Aplicação IoT
drone / dashboard

→

MQTT
tópico · broker · QoS

→

TCP
conexão · ordem · ACK

→

IP / Rede

TCP É responsável por ordenar os segmentos e garantir a entrega dos bytes. Se um segmento se perder, o TCP solicita retransmissão automaticamente. Para o Motor Cognitivo, é vital que os metadados cheguem na ordem correta — o AgroLLM cruza o timestamp com os dados históricos no FAISS RAG.

MQTT Fica acima do TCP e controla a lógica de mensagem: tópico, publicação, assinatura, broker e nível de garantia (QoS). Organiza a inteligência por tópicos — agro/perception/detected.

⚠ Ponto crítico: QoS 0 no MQTT NÃO significa UDP — mesmo com QoS 0 o MQTT continua usando TCP. A diferença é que no nível MQTT não há confirmação da mensagem. O TCP ainda confirma os bytes por baixo, de forma transparente.

MÓDULO 4

MQTT · QoS · Janela In-Flight

Wi-Fi → TCP → MQTT · várias mensagens em voo · 1 PUBACK por packetId · Fundamentação: HiveMQ MQTT Essentials · EMQX Docs · EMQ QoS Guide

📡 Stack de Protocolos

Aplicação IoT

↑↓

MQTT
pub/sub · QoS · broker

↑↓

TCP
conexão · ordem · ACK

↑↓

IP / Rede

Ponto crítico: QoS 0 no MQTT NÃO significa UDP. Mesmo com QoS 0, o MQTT usa TCP. A diferença é que no nível MQTT não há confirmação da mensagem.

⚡ Animação: QoS · In-Flight Window · Retransmissão

Antes de qualquer MQTT, o TCP estabelece a conexão com handshake de 3 vias. O Wi-Fi é a camada física que transporta o TCP até o broker.

🚁

Drone/RPi5

① SYN → "quero conectar"

← SYN-ACK "aceito"

② ACK "confirmado"

③ MQTT CONNECT (TCP pronto)

🖥

Broker MQTT

TCP garante a entrega dos bytes e a ordem dos segmentos. MQTT trabalha em cima disso — controla a lógica de mensagem.

at most once sem ACK MQTT

Drone envia e esquece. 0 confirmações MQTT. TCP ainda confirma os bytes (invisível ao MQTT). Se a conexão cair, mensagens no buffer são perdidas — MQTT não retransmite.

🚁

PUBLISH #temp (sem packetId)

PUBLISH #umid (sem packetId)

sem PUBACK · broker não responde · drone não sabe se chegou

🖥

at least once janela in-flight Receive Maximum (MQTT v5)

O drone envia 3 mensagens SEM esperar ACK — em paralelo, dentro da janela in-flight. Cada uma tem seu próprio packetId. O broker confirma cada uma individualmente com PUBACK(id). Janela padrão: até 65.535 mensagens simultâneas.

🚁

in-flight
window=3

→ PUBLISH id=1 · temp=28.4°C

→ PUBLISH id=2 · umid=67% (sem esperar ACK do id=1)

→ PUBLISH id=3 · pres=1013hPa

← PUBACK id=1 ✓

← PUBACK id=2 ✓

← PUBACK id=3 ✓

📌 in-flight window: drone envia sem esperar · cada PUBACK libera 1 slot · janela padrão = 65.535

🖥

armazena
envia PUBACK

Dois cenários de falha no QoS 1 — o drone retransmite automaticamente com flag DUP=true.

Cenário A — PUBLISH se perde

PUBLISH id=4 →

✗ perdido na rede

⏳ timeout sem PUBACK

PUBLISH id=4 DUP=true →

← PUBACK id=4 ✓

Broker recebe apenas 1x — sem duplicata no subscriber.

Cenário B — PUBACK se perde

PUBLISH id=5 → ✓ chegou

← PUBACK id=5 ✗ perdido

⏳ drone retransmite

PUBLISH id=5 DUP=true ⚠

← PUBACK id=5 ✓

⚠ Broker recebe 2x → duplicata. Solução: UUID no payload para idempotência.

Solução para duplicatas no Farm-LightSeek

Cada payload inclui UUID único da missão. Subscriber descarta se já processou.
Ex: {"id":"missao-2026-06-setor-norte-001","temp":28.4,"ts":1717500000,"hash":"sha256..."}

QoS 0

0 ACK

Msgs MQTT: 1

Confirma: nunca

Overhead: mínimo

Uso: sensores alta freq.

mais usado IoT

QoS 1

PUBACK

Msgs MQTT: 2

Confirma: ao menos 1x

In-flight: sim, janela

Uso: drones, dashboards

QoS 2

4 trocas

Msgs MQTT: 4

Confirma: exatamente 1x

Overhead: maior

Uso: saúde, indústria crítica

WebSocket — ACK pelo TCP

WS não tem ACK próprio de mensagem. TCP confirma automaticamente cada segmento recebido. WS Ping/Pong = keep-alive da conexão, não confirmação de mensagem.

No Farm-LightSeek: MQTT QoS 1 no trecho drone→broker · WebSocket no trecho broker→dashboard.

Fundamentos

HiveMQ MQTT Essentials Part 6 · EMQX QoS Guide · Cedalo MQTT QoS Guide · AWS IoT Core Docs · OASIS MQTT 5.0 Spec

"No MQTT, as mensagens trafegam sobre TCP. Por isso, a ordenação dos segmentos e a confiabilidade básica ficam a cargo do TCP. O MQTT controla a entrega no nível da aplicação, usando tópicos, broker e níveis de QoS."