Robô Aspirador Autônomo

Trabalho 2 - Fundamentos de Sistemas Embarcados
Período: 2025/2

Integrantes:

• Jefferson Sena - Matrícula: 200020323
• Tiago Albuquerque - Matrícula: 202028973

1. Introdução

O presente trabalho tem como objetivo realizar um estudo teórico-exploratório sobre robôs aspiradores autônomos, tendo como referência principal o iRobot Roomba, produto pioneiro nesta categoria. Serão analisadas as principais tecnologias embarcadas, sensores utilizados e algoritmos de controle, além de propor uma implementação conceitual utilizando a plataforma ESP32.

Os robôs aspiradores representam uma das aplicações mais bem-sucedidas de sistemas embarcados no ambiente doméstico, combinando navegação autônoma, processamento em tempo real e conectividade sem fio para realizar tarefas de limpeza de forma independente.

2. Descrição do Produto Selecionado

2.1 Visão Geral

O robô aspirador autônomo é um dispositivo eletrodoméstico capaz de realizar a limpeza de superfícies de forma independente, sem intervenção humana direta. O iRobot Roomba, lançado em 2002, foi o primeiro produto comercialmente viável desta categoria e permanece como referência tecnológica no segmento.

O salto conceitual do iRobot Roomba não foi apenas a motorização da aspiração, mas a aplicação de princípios de robótica autônoma (agência) em um eletrodoméstico de consumo em massa. O desafio de engenharia central, especialmente nos modelos iniciais, foi resolver o problema da cobertura (garantir que o robô limpasse a maior área possível) em um ambiente doméstico não estruturado e dinâmico. Isso foi alcançado utilizando hardware severamente restrito: microcontroladores de 8 bits e um conjunto de sensores de baixo custo (IR, bumper). Esta solução representa um clássico trade-off de sistema embarcado: alcançar uma funcionalidade complexa (navegação) através de algoritmos comportamentais (como a arquitetura de subsumption) em vez de hardware caro (como LIDAR ou câmeras, que só se tornaram viáveis uma década depois). O produto redefiniu a interação humano-máquina no lar, transitando de uma "ferramenta operada" (aspirador manual) para um "serviço autônomo".

O produto consiste basicamente em uma plataforma circular móvel equipada com sistema de aspiração, motores de tração, múltiplos sensores e sistema de controle embarcado. A evolução tecnológica ao longo de mais de duas décadas permitiu a incorporação de recursos avançados como mapeamento do ambiente, controle via aplicativo móvel e integração com ecossistemas de automação residencial.

2.2 Funções Principais

Estas funções não operam de forma isolada; elas representam um ciclo de controle "percepção-decisão-ação" (sense-think-act) contínuo, orquestrado pelo sistema de controle embarcado. A complexidade do produto reside na gestão concorrente destas tarefas em tempo real, onde o robô deve simultaneamente navegar, limpar e monitorar sua própria segurança e energia.

O sistema executa as seguintes funções primárias:

1. Navegação Autônoma: Movimentação independente pelo ambiente utilizando algoritmos de controle baseados em dados sensoriais.

2. Detecção de Obstáculos: Identificação e desvio de objetos presentes no trajeto através de sensores infravermelhos e ultrassônicos.

3. Prevenção de Quedas: Detecção de desníveis e escadas mediante sensores ópticos direcionados ao solo (cliff sensors).

4. Sistema de Limpeza: Aspiração de partículas através de motor de sucção e escovas rotativas.

5. Gerenciamento de Energia: Monitoramento do nível de bateria e retorno automático à estação de recarga.

6. Conectividade: Interface com dispositivos móveis através de protocolo Wi-Fi para programação e monitoramento remoto.

A integração robusta destas funções é o que define a arquitetura do sistema. O algoritmo de navegação, por exemplo, deve tomar decisões de desvio em milissegundos (uma tarefa de alta prioridade) enquanto, simultaneamente, o subsistema de conectividade (uma tarefa de baixa prioridade) pode estar negociando um pacote de dados com a nuvem. Garantir que a tarefa de baixa prioridade não impeça a execução da tarefa de alta prioridade (um fenômeno conhecido como inversão de prioridade) é um desafio central resolvido pelo uso de um Sistema Operacional de Tempo Real (RTOS).

2.3 Público-Alvo e Aplicações

O produto destina-se primariamente ao mercado consumidor residencial, atendendo diversos perfis:

• Residências com necessidade de manutenção frequente da limpeza
• Ambientes comerciais de pequeno e médio porte
• Usuários com restrições de mobilidade ou tempo
• Proprietários de animais domésticos

O contexto de uso típico envolve operação programada ou sob demanda em ambientes internos com superfícies relativamente planas, incluindo pisos cerâmicos, madeira e carpetes de baixa espessura.

A proposta de valor do produto se adapta de forma distinta a cada um desses segmentos. Para proprietários de animais domésticos, o benefício principal é a manutenção de alta frequência (diária), que controla a dispersão de pelos de forma mais eficaz que a limpeza manual esporádica. Para usuários com restrições de mobilidade, o dispositivo é uma tecnologia assistiva que promove independência e reduz a carga de trabalho físico. Para pequenos escritórios, representa uma otimização de custo operacional, permitindo a manutenção da limpeza fora do horário comercial sem custo de mão de obra contínuo. O sucesso comercial do Roomba derivou de sua capacidade de oferecer um retorno sobre o investimento (seja em tempo, esforço físico ou custo monetário) claro e mensurável para nichos de mercado bem definidos.

2.4 Arquitetura do Sistema e Componentes

A arquitetura do sistema pode ser dividida em módulos funcionais:

2.4.1 Módulo de Sensoriamento

Sensores de Proximidade:

• Sensores infravermelhos (6 a 8 unidades): Detecção de obstáculos em curto alcance (5-30 cm)
• Sensor ultrassônico: Medição de distância por tempo de voo de onda sonora (até 3 metros)
• Bumper com microswitch: Sensor tátil de colisão

Sensores de Segurança:

• Cliff sensors (4 unidades): Emissores/receptores IR orientados verticalmente para detectar desníveis superiores a 3 cm

Sensores de Odometria:

• Encoders ópticos: Acoplados às rodas para medição de deslocamento linear
• IMU (Unidade de Medição Inercial): Acelerômetro e giroscópio de 3 eixos para estimativa de orientação

Sensores Auxiliares:

• Sensor acústico de sujeira: Detecta partículas sendo aspiradas através de vibração
• Sensor de tensão: Monitoramento do nível de carga da bateria

2.4.2 Módulo de Atuação

Sistema de Tração:

• 2 motores DC com redução (6V, ~200 RPM): Tração diferencial para movimentação e rotação
• Roda omnidirecional: Suporte passivo

Sistema de Limpeza:

• Motor brushless (12V): Acionamento do ventilador centrífugo de aspiração (10.000-15.000 RPM)
• Motor da escova principal: Rotação da escova cilíndrica
• Motores das escovas laterais: Direcionamento de sujeira periférica

2.4.3 Módulo de Processamento e Controle

Hardware Computacional:

• Microcontrolador ARM Cortex-M (32-bit, ~100-200 MHz)
• Módulo Wi-Fi (ESP32 ou equivalente)
• Memória Flash (16-32 MB) para armazenamento de mapas e firmware
• SRAM (512 KB - 1 MB) para execução de algoritmos

Sistema Operacional:

• RTOS (Real-Time Operating System) proprietário ou baseado em FreeRTOS
• Gerenciamento de múltiplas tarefas concorrentes com prioridades definidas

2.4.4 Módulo de Alimentação

Bateria:

• Tipo: Lítio-Íon (Li-Ion)
• Configuração: 3S1P ou 4S1P (10.8V - 14.4V nominal)
• Capacidade: 2500-5000 mAh
• Autonomia: 60-180 minutos (dependendo do modelo e modo de operação)

Sistema de Carga:

• Estação de recarga com contatos elétricos
• Controlador de carga integrado (CC-CV)
• Proteção contra sobrecarga e descarga excessiva

2.5 Tecnologias de Comunicação

2.5.1 Comunicação Sem Fio

Wi-Fi (IEEE 802.11 b/g/n):

• Frequência: 2.4 GHz
• Função: Conexão com rede doméstica e serviços cloud
• Protocolos de aplicação: MQTT, HTTP/HTTPS
• Implementação: Modo station (cliente)

Infravermelho:

• Função: Comunicação com estação de recarga (beacon)
• Alcance: 2-5 metros
• Protocolo: Modulação proprietária

Bluetooth (opcional em modelos premium):

• Função: Pareamento inicial e controle de proximidade
• Perfil: BLE (Bluetooth Low Energy)

2.5.2 Interface com Usuário

Aplicativo Móvel:

• Plataformas: iOS e Android
• Funcionalidades:
  • Inicialização e interrupção de ciclos de limpeza
  • Agendamento de tarefas
  • Visualização de mapas (modelos com SLAM)
  • Definição de zonas restritas (virtual walls)
  • Monitoramento de histórico
  • Atualizações OTA (Over-The-Air)

Integração com Assistentes Virtuais:

• Amazon Alexa
• Google Assistant
• Apple HomeKit (modelos selecionados)

3. Análise Técnica do Funcionamento

3.1 Arquitetura de Software

O software embarcado é estruturado em camadas hierárquicas:

Camada de Hardware Abstraction Layer (HAL): Drivers de baixo nível para acesso a periféricos (GPIO, PWM, I2C, SPI, ADC)

Camada de Middleware:

• Gerenciador de tarefas (RTOS)
• Pilha de comunicação (Wi-Fi stack)
• Sistema de arquivos

Camada de Aplicação:

• Algoritmo de navegação
• Máquina de estados
• Interface de comunicação
• Módulos de diagnóstico

3.2 Algoritmo de Navegação

3.2.1 Navegação Reativa (Gerações Iniciais)

Os primeiros modelos de Roomba utilizavam navegação baseada em comportamentos reativos, sem construção de mapas. O algoritmo implementa os seguintes comportamentos básicos:

1. Movimento em linha reta: Estado padrão
2. Desvio de obstáculos: Ao detectar obstrução, executa rotação de ângulo aleatório
3. Padrão espiral: Incrementa gradualmente o raio de curvatura
4. Limpeza de bordas: Ao detectar parede, segue o perímetro

Este método, embora simples, garante cobertura estatística completa do ambiente dado tempo suficiente de operação, baseando-se na teoria de caminhada aleatória.

3.2.2 Navegação Baseada em Mapa (Gerações Recentes)

Modelos modernos implementam algoritmos de SLAM (Simultaneous Localization and Mapping), que constroem incrementalmente um mapa do ambiente enquanto estimam a pose (posição e orientação) do robô.

Visual SLAM (Roomba): Utiliza câmera apontada verticalmente para capturar características do teto, combinada com odometria para estimar deslocamento.

LIDAR SLAM (Xiaomi, Roborock): Sensor laser rotativo de 360° mede distâncias, construindo mapa de ocupação em grade (occupancy grid).

O algoritmo de SLAM pode ser representado recursivamente:

x_t = f(x_{t-1}, u_t, w_t)        // Modelo de movimento
z_t = h(x_t, m, v_t)               // Modelo de observação

Onde:

• x_t: Estado no tempo t (pose do robô)
• u_t: Comando de controle
• z_t: Observação dos sensores
• m: Mapa do ambiente
• w_t, v_t: Ruídos gaussianos

Filtro de Partículas (FastSLAM): Implementação comum em robôs de consumo devido ao compromisso entre precisão e custo computacional. Mantém conjunto de hipóteses (partículas) sobre a pose do robô e características do mapa.

3.3 Controle de Movimento

O sistema de controle converte comandos de velocidade linear e angular em sinais PWM para os motores.

Cinemática Diferencial: Para tração diferencial, as velocidades das rodas relacionam-se com a velocidade linear (v) e angular (ω) por:

v_L = v - (L/2)ω
v_R = v + (L/2)ω

Onde L é a distância entre rodas.

Controle PID: Para seguir trajetórias, implementa-se controle proporcional-integral-derivativo:

u(t) = K_p·e(t) + K_i·∫e(τ)dτ + K_d·de(t)/dt

Onde e(t) é o erro entre trajetória desejada e atual.

3.4 Gerenciamento de Energia

O firmware implementa estratégias de economia de energia:

1. Desligamento de periféricos não utilizados: Wi-Fi desativado durante limpeza
2. Ajuste dinâmico de potência: Redução de velocidade de motores em áreas limpas
3. Monitoramento contínuo de bateria: Decisão de retorno à base baseada em estimativa de energia residual e distância

Algoritmo de retorno à base:

if (bateria < limiar_critico) {
    if (mapa_disponivel) {
        calcular_caminho_otimo_para_base();
    } else {
        buscar_sinal_infravermelho_base();
    }
}

3.5 Tecnologias Críticas

3.5.1 SLAM (Simultaneous Localization and Mapping)

SLAM é fundamental para navegação eficiente. O problema consiste em estimar simultaneamente o mapa do ambiente (m) e a trajetória do robô (x_{1:t}) dadas as observações (z_{1:t}) e comandos de controle (u_{1:t}).

A solução envolve inferência bayesiana:

P(x_{1:t}, m | z_{1:t}, u_{1:t})

Referência: Taketomi et al. (2017) apresentam revisão extensiva de métodos SLAM desenvolvidos entre 2010-2016, incluindo abordagens visuais (monoculares, estereoscópicas, RGB-D) e baseadas em LIDAR.

3.5.2 Protocolo IEEE 802.11 (Wi-Fi)

O padrão Wi-Fi permite comunicação sem fio através de:

Camada Física (PHY):

• Modulação OFDM (Orthogonal Frequency Division Multiplexing)
• Taxa de transmissão: 1-150 Mbps (802.11n)

Camada MAC:

• CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)
• Modos de economia de energia (PSM - Power Save Mode)

Para dispositivos IoT, implementa-se power save mode onde o módulo Wi-Fi entra periodicamente em sleep, acordando apenas para beacon frames ou quando há dados para transmitir.

3.5.3 FreeRTOS

FreeRTOS é um sistema operacional de tempo real amplamente utilizado em sistemas embarcados devido ao seu footprint reduzido (~10KB) e scheduling determinístico.

Características Relevantes:

• Scheduling preemptivo baseado em prioridades
• Primitivas de sincronização (semáforos, mutexes, filas)
• Tick de sistema configurável (tipicamente 1-10 ms)

Estrutura típica de tarefas em robô aspirador:

3.5.4 Controle de Motores Brushless DC (BLDC)

Motores BLDC são utilizados no sistema de aspiração devido à maior eficiência energética (85-95% vs 75-80% de motores brushed) e ausência de desgaste mecânico.

Princípio de Operação: Utiliza comutação eletrônica através de inversores trifásicos. O controle pode ser:

• Sensorless: Detecção de posição do rotor através de Back-EMF (força contra-eletromotriz)
• Com sensores Hall: Três sensores de efeito Hall fornecem posição discreta do rotor

O controle trapezoidal (six-step commutation) energiza duas fases por vez em sequência de 6 estados, baseado na posição do rotor.

Referência: Pillay & Krishnan (1989) apresentam modelagem e técnicas de controle para motores BLDC, incluindo métodos sensorless essenciais para aplicações de custo reduzido.

4. Proposta de Implementação com ESP32

4.1 Justificativa da Plataforma

A ESP32 foi selecionada para implementação de protótipo funcional pelos seguintes motivos:

• Arquitetura dual-core (Xtensa LX6, 240 MHz) permite paralelização de tarefas
• Conectividade Wi-Fi e Bluetooth integradas
• FreeRTOS nativo no ESP-IDF
• Conjunto abundante de periféricos (PWM, I2C, SPI, ADC)
• Custo acessível (~R$ 30-40)
• Vasta documentação e comunidade ativa

A adequação da ESP32 para este protótipo vai além da simples lista de recursos. A arquitetura dual-core Xtensa LX6 é a característica de maior impacto, pois permite uma separação de privilégios de tempo real (atribuição de tarefas a núcleos específicos, ou task pinning). Pode-se dedicar o Core 0 às tarefas de hard real-time, como a leitura em alta frequência dos sensores de cliff (que não pode falhar) e o loop de controle PWM dos motores (via periférico LEDC). O Core 1 ficaria então responsável pelas tarefas de soft real-time, como a execução da máquina de estados de navegação, a fusão de dados da IMU e a pilha de comunicação Wi-Fi/MQTT, sem risco de preempção das funções críticas de segurança. O ESP-IDF, com sua integração nativa do FreeRTOS, não é apenas um facilitador, mas a base que viabiliza a arquitetura de tarefas concorrentes (detalhada na seção 3.5.3) necessária para um robô autônomo funcional.

4.2 Alternativas de Implementação

Foram propostas duas abordagens de implementação com níveis distintos de complexidade, considerando as restrições de tempo, recursos e experiência prévia:

4.2.1 MVP (Minimum Viable Product)

Abordagem focada nos componentes essenciais para demonstrar navegação autônoma básica.

Componentes Necessários (MVP):

Custo Total MVP: ~R$ 109

Sensores especificamente: R$ 9 (HC-SR04 + resistores)

Características do MVP:

• Navegação reativa simples (padrão aleatório)
• Detecção de obstáculos frontal via ultrassom
• Movimento: frente, ré, girar direita/esquerda
• Código em Arduino IDE (mais acessível que ESP-IDF)
• Chassi improvisado (papelão, acrílico ou robô adaptado)
• Tempo de implementação estimado: 2-3 semanas
• Probabilidade de sucesso: 90%

Algoritmo Simplificado (MVP):

void loop() {
    float distancia = lerUltrassom();
    
    if (distancia < 20) {  // Obstáculo a menos de 20cm
        parar();
        delay(200);
        re(500);           // Recuar por 500ms
        girarDireita(random(500, 1500));  // Girar tempo aleatório
    } else {
        frente(200);       // Velocidade 200 (0-255)
    }
    
    delay(50);  // 20Hz loop
}

Vantagens:

• Menor investimento financeiro
• Código mais simples e compreensível
• Menos pontos de falha
• Tempo de desenvolvimento reduzido
• Facilita debug e ajustes
• Demonstra conceitos fundamentais

Limitações:

• Não detecta obstáculos laterais
• Sem proteção contra quedas (cliff)
• Navegação menos eficiente (mais aleatória)
• Sem odometria ou estimativa de pose
• Sem interface visual local

4.2.2 Implementação Completa

Implementação de sistema mais robusto com múltiplos sensores e controle sofisticado.

4.3 Especificação de Hardware (Implementação Completa)

4.3.1 Componentes Necessários

4.3.2 Diagrama de Conexões

Sistema de Alimentação:

Bateria Li-Ion 11.1V (3S)
         |
         ├──> L298N (12V) ──> Motores DC
         |
         └──> Buck Converter ──> 5V
                    |
                    ├──> ESP32 (VIN)
                    └──> HC-SR04 (VCC)

Conexões ESP32:

Atenção: O pino ECHO do HC-SR04 emite sinal de 5V, incompatível com os 3.3V máximos da ESP32. Necessário divisor resistivo:

ECHO ──[R1: 10kΩ]──┬── GPIO26
                    |
                 [R2: 10kΩ]
                    |
                   GND

Tensão resultante: V_out = 5V × (10kΩ)/(10kΩ + 10kΩ) = 2.5V ✓

4.4 Implementação de Software (Implementação Completa)

4.4.1 Estrutura do Firmware

O firmware será desenvolvido utilizando ESP-IDF (Espressif IoT Development Framework), que fornece API sobre FreeRTOS.

Arquitetura de Tarefas:

// main.c
void app_main(void) {
    // Inicialização de periféricos
    init_gpio();
    init_pwm();
    init_i2c();
    init_wifi();
    
    // Criação de filas para comunicação inter-tarefas
    xQueueSensorData = xQueueCreate(1, sizeof(sensor_data_t));
    xQueueMotorCmd = xQueueCreate(5, sizeof(motor_cmd_t));
    
    // Criação de tarefas com prioridades
    xTaskCreatePinnedToCore(task_sensor_reading, "Sensors", 
                            4096, NULL, 5, NULL, 0);
    xTaskCreatePinnedToCore(task_navigation, "Navigation", 
                            4096, NULL, 4, NULL, 0);
    xTaskCreatePinnedToCore(task_motor_control, "Motors", 
                            2048, NULL, 5, NULL, 1);
    xTaskCreatePinnedToCore(task_wifi_comm, "WiFi", 
                            4096, NULL, 2, NULL, 1);
}

4.4.2 Módulo de Leitura de Sensores

Sensor Ultrassônico:

float ultrasonic_read_distance(void) {
    // Emitir pulso de trigger (10 μs)
    gpio_set_level(PIN_TRIG, 1);
    esp_rom_delay_us(10);
    gpio_set_level(PIN_TRIG, 0);
    
    // Medir duração do pulso ECHO
    uint32_t timeout = 30000; // 30ms timeout
    uint32_t time_start, time_end;
    
    // Aguardar subida de ECHO
    while (gpio_get_level(PIN_ECHO) == 0 && timeout-- > 0) {
        esp_rom_delay_us(1);
    }
    time_start = esp_timer_get_time();
    
    timeout = 30000;
    // Aguardar descida de ECHO
    while (gpio_get_level(PIN_ECHO) == 1 && timeout-- > 0) {
        esp_rom_delay_us(1);
    }
    time_end = esp_timer_get_time();
    
    // Calcular distância: d = (t × v) / 2
    // v_som = 343 m/s = 0.0343 cm/μs
    uint32_t duration_us = time_end - time_start;
    float distance_cm = (duration_us * 0.0343f) / 2.0f;
    
    return distance_cm;
}

IMU MPU6050:

typedef struct {
    float accel_x, accel_y, accel_z;  // m/s²
    float gyro_x, gyro_y, gyro_z;     // rad/s
} imu_data_t;

esp_err_t mpu6050_read(imu_data_t *data) {
    uint8_t raw_data[14];
    
    // Ler registradores 0x3B a 0x48 (accel + temp + gyro)
    i2c_master_read_from_device(I2C_NUM_0, MPU6050_ADDR, 
                                 0x3B, raw_data, 14, 
                                 pdMS_TO_TICKS(100));
    
    // Conversão (escala ±4g para accel, ±500°/s para gyro)
    int16_t accel_raw_x = (raw_data[0] << 8) | raw_data[1];
    data->accel_x = accel_raw_x / 8192.0f * 9.81f; // Para m/s²
    
    // Similar para outros eixos...
    
    return ESP_OK;
}

4.4.3 Algoritmo de Navegação

Devido às limitações computacionais da ESP32 para processar SLAM em tempo real, implementa-se navegação reativa com padrão de cobertura:

typedef enum {
    STATE_IDLE,
    STATE_FORWARD,
    STATE_AVOIDING,
    STATE_CLIFF_DETECTED,
    STATE_SPIRAL,
    STATE_WALL_FOLLOW
} nav_state_t;

void task_navigation(void *pvParameters) {
    sensor_data_t sensor_data;
    nav_state_t state = STATE_IDLE;
    uint32_t spiral_counter = 0;
    
    while (1) {
        // Receber dados dos sensores
        xQueuePeek(xQueueSensorData, &sensor_data, 0);
        
        switch (state) {
            case STATE_FORWARD:
                // Verificar cliff (prioridade máxima)
                if (sensor_data.cliff_detected) {
                    state = STATE_CLIFF_DETECTED;
                    motor_stop();
                    break;
                }
                
                // Verificar obstáculos
                if (sensor_data.distance_front < 20.0f || 
                    sensor_data.ir_front) {
                    state = STATE_AVOIDING;
                    break;
                }
                
                // Incrementar padrão espiral
                spiral_counter++;
                if (spiral_counter > 50) { // ~5 segundos
                    float turn_angle = 15.0f; // graus
                    motor_turn(turn_angle);
                    spiral_counter = 0;
                }
                
                motor_forward(70); // 70% velocidade
                break;
                
            case STATE_AVOIDING:
                motor_stop();
                vTaskDelay(pdMS_TO_TICKS(100));
                
                // Decidir direção baseado em sensores laterais
                if (!sensor_data.ir_left && sensor_data.ir_right) {
                    motor_turn_left(90);
                } else if (sensor_data.ir_left && !sensor_data.ir_right) {
                    motor_turn_right(90);
                } else {
                    // Ambos bloqueados, virar aleatório
                    int angle = 90 + (esp_random() % 90);
                    motor_turn_right(angle);
                }
                
                state = STATE_FORWARD;
                break;
                
            case STATE_CLIFF_DETECTED:
                // Recuar 50cm
                motor_backward(50);
                vTaskDelay(pdMS_TO_TICKS(500));
                motor_stop();
                
                // Girar 180°
                motor_turn_right(180);
                
                state = STATE_FORWARD;
                break;
                
            case STATE_IDLE:
            default:
                motor_stop();
                break;
        }
        
        vTaskDelay(pdMS_TO_TICKS(100)); // 10 Hz
    }
}

4.4.4 Controle de Motores

void motor_set_speed(int8_t left_speed, int8_t right_speed) {
    // Velocidade: -100 a +100 (negativo = reverso)
    
    // Motor esquerdo
    if (left_speed >= 0) {
        ledc_set_duty(LEDC_MODE, CH_L_FWD, abs(left_speed) * 10);
        ledc_set_duty(LEDC_MODE, CH_L_BWD, 0);
    } else {
        ledc_set_duty(LEDC_MODE, CH_L_FWD, 0);
        ledc_set_duty(LEDC_MODE, CH_L_BWD, abs(left_speed) * 10);
    }
    ledc_update_duty(LEDC_MODE, CH_L_FWD);
    ledc_update_duty(LEDC_MODE, CH_L_BWD);
    
    // Motor direito (similar)
    // ...
}

void motor_forward(uint8_t speed_percent) {
    motor_set_speed(speed_percent, speed_percent);
}

void motor_turn_right(float angle_degrees) {
    // Calcular tempo baseado em velocidade angular
    // Assumindo velocidade de rotação de 90°/s
    uint32_t duration_ms = (uint32_t)(angle_degrees / 90.0f * 1000.0f);
    
    motor_set_speed(50, -50); // Tração diferencial
    vTaskDelay(pdMS_TO_TICKS(duration_ms));
    motor_set_speed(0, 0);
}

4.5 Diagrama de Blocos do Sistema Proposto

┌─────────────────────────────────────────────────────────┐
│                    ESP32 (Dual Core)                    │
│                                                         │
│  Core 0:                        Core 1:                │
│  ┌─────────────────┐           ┌──────────────┐       │
│  │ Sensor Reading  │           │ Motor Ctrl   │       │
│  │ Navigation      │           │ WiFi Comm    │       │
│  └─────────────────┘           └──────────────┘       │
│                                                         │
│            ┌──────────────────┐                        │
│            │   FreeRTOS       │                        │
│            │   (Scheduler)    │                        │
│            └──────────────────┘                        │
└──────┬─────────────┬───────────────┬──────────────────┘
       │             │               │
   ┌───▼───┐    ┌───▼────┐     ┌───▼────┐
   │Sensors│    │L298N   │     │ WiFi   │
   │       │    │Motors  │     │        │
   │-Ultra │    │        │     │-MQTT   │
   │-IR x4 │    │-Left   │     │-HTTP   │
   │-Cliff │    │-Right  │     │        │
   │-IMU   │    └────────┘     └────────┘
   └───────┘

4.6 Limitações e Desafios

A implementação proposta (versão completa) apresenta as seguintes limitações em relação a produtos comerciais:

Limitações de Hardware:

1. Ausência de SLAM: A ESP32 não possui capacidade de processamento para algoritmos de SLAM visual ou baseados em LIDAR em tempo real. A navegação será puramente reativa.

2. Sistema de Limpeza Simplificado: O protótipo não incluirá sistema de aspiração funcional, concentrando-se na navegação autônoma como prova de conceito.

3. Ausência de Retorno à Base: Sem mapeamento ou beacon IR dedicado, o recurso de retorno automático à estação de recarga não será implementado.

4. Odometria Imprecisa: Motores DC sem encoders apresentam deriva significativa. A compensação será parcial através do IMU.

Desafios Técnicos Identificados:

1. Calibração de Sensores: Sensores IR apresentam variabilidade individual e sensibilidade à cor de superfícies, necessitando calibração específica por unidade.

2. Gerenciamento de Energia: O módulo Wi-Fi da ESP32 consome ~160mA em operação, representando fração significativa do orçamento energético. Será necessário implementar power save mode agressivo.

3. Sincronização de Tarefas: Coordenação adequada entre leitura de sensores, processamento de navegação e controle de motores requer uso criterioso de primitivas de sincronização do FreeRTOS.

4. Construção Mecânica: Fabricação de chassi robusto e posicionamento preciso de sensores apresenta desafios práticos significativos.

5. Sincronização de Tarefas: A inversão de prioridade, um problema clássico de RTOS, poderia ocorrer se a task_wifi_comm (baixa prioridade) mantiver um recurso (como um mutex que protege o barramento I2C) que a task_sensor_reading (alta prioridade) precisa.

Mitigações Propostas:

• Implementar padrões de cobertura determinísticos (espiral, zigue-zague) que garantam cobertura estatística
• Utilizar fusão de sensores (IMU + encoders simulados via tempo) para melhorar estimativa de trajetória
• Desativar Wi-Fi durante operação normal, ativando apenas para comandos específicos
• Armazenar parâmetros de calibração em NVS (Non-Volatile Storage) da ESP32

4.7 Comparativo: MVP vs Implementação Completa

A tabela abaixo auxilia na escolha da abordagem mais adequada considerando recursos disponíveis:

A escolha entre as abordagens depende dos recursos disponíveis e do tempo para implementação. O MVP (4.2.1) apresenta menor complexidade e maior viabilidade em prazos reduzidos, enquanto a Implementação Completa (4.2.2) oferece funcionalidades mais robustas com integração de múltiplos sensores e RTOS. Ambas abordagens são válidas para demonstração dos conceitos de sistemas embarcados em navegação autônoma.

A tabela expõe um clássico trade-off de engenharia: Risco vs. Complexidade Funcional. O MVP (4.2.1) foca em validar a plataforma de hardware (integração ESP32 + L298N) com uma lógica de controle mínima. O risco de falha é baixo e o resultado (um robô que desvia de paredes) é rapidamente alcançável. Esta abordagem, embora funcional, assemelha-se a um sistema de loop único, mais típico do ambiente Arduino.

5. Pesquisa Bibliográfica

5.1 Artigos sobre Tecnologias Habilitadoras

5.1.1 SLAM para Robótica Móvel

Referência: TAKETOMI, T.; UCHIYAMA, H.; IKEDA, S. Visual SLAM algorithms: a survey from 2010 to 2016. IPSJ Transactions on Computer Vision and Applications, v. 9, n. 16, 2017.

DOI: 10.1186/s41074-017-0027-2

Link: https://link.springer.com/article/10.1186/s41074-017-0027-2

Resumo: O artigo apresenta revisão sistemática de algoritmos SLAM (Simultaneous Localization and Mapping) desenvolvidos no período 2010-2016, período marcado por avanços significativos devido ao aumento da capacidade computacional de dispositivos embarcados e emergência de novos sensores de baixo custo.

Os autores categorizam os métodos em três classes principais: (1) SLAM visual monocular, que utiliza câmeras convencionais e técnicas de estrutura a partir do movimento (SfM); (2) SLAM estereoscópico e RGB-D, que aproveitam informação direta de profundidade; e (3) SLAM baseado em LIDAR, que oferece medições precisas de distância em 2D ou 3D.

Para robôs aspiradores, o artigo é relevante pois discute o compromisso entre precisão e eficiência computacional. Algoritmos como ORB-SLAM e FastSLAM são destacados como viáveis para implementação em hardware embarcado de custo reduzido. O texto enfatiza que a escolha do sensor (câmera vs LIDAR) depende fundamentalmente das restrições de custo e do ambiente de operação.

Um aspecto particularmente relevante é a discussão sobre técnicas de loop closure (fechamento de loop), essenciais para corrigir deriva acumulada de odometria em ambientes domésticos onde o robô frequentemente revisita locais. Os autores apresentam métodos baseados em bag of words visual que permitem reconhecimento eficiente de lugares previamente visitados.

O artigo conclui que apesar dos avanços, SLAM ainda apresenta desafios em ambientes dinâmicos (presença de pessoas e animais) e sob variações de iluminação, condições típicas em aplicações domésticas.

5.1.2 Protocolo IEEE 802.11 para Dispositivos IoT

Referência: OBREGON, E.; PARK, J.; PARK, S.; KIM, T.; CHOI, S. IEEE 802.11ah: A Long Range 802.11 WLAN at Sub 1 GHz. Journal of ICT Standardization, v. 1, n. 1, p. 83-108, 2013.

DOI: 10.13052/jicts2245-800X.112

Link: https://journals.riverpublishers.com/index.php/JICTS/article/view/3853

Resumo: Este artigo descreve a padronização IEEE 802.11ah, extensão do protocolo Wi-Fi otimizada para dispositivos IoT operando em frequências sub-1 GHz. Embora robôs aspiradores convencionais utilizem 802.11n em 2.4 GHz, os princípios de otimização de energia e protocolo MAC discutidos são diretamente aplicáveis.

Os autores explicam que o protocolo 802.11 implementa acesso múltiplo através de CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance), onde dispositivos escutam o meio antes de transmitir. Para dispositivos alimentados por bateria, o padrão define Power Save Mode (PSM), onde o rádio entra em sleep entre transmissões, acordando periodicamente para beacon frames do access point.

O artigo apresenta análise quantitativa do consumo energético: modo ativo (TX/RX) consome tipicamente 150-200 mA @ 3.3V, enquanto modo sleep consome 10-50 μA. Para um robô aspirador com bateria de 3000 mAh, manter Wi-Fi constantemente ativo reduziria autonomia em aproximadamente 20%, justificando implementação de estratégias agressivas de economia de energia.

A camada física emprega modulação OFDM (Orthogonal Frequency Division Multiplexing) que oferece robustez contra interferência multitrajeto, comum em ambientes internos com múltiplas reflexões. A taxa de dados adaptativa (1-150 Mbps para 802.11n) permite ao dispositivo ajustar a modulação baseado nas condições do canal, otimizando throughput e confiabilidade.

Para aplicação em robôs aspiradores, o protocolo suporta comunicação bidirecional necessária para controle remoto (comandos de start/stop, agendamento) e telemetria (status, mapas comprimidos, notificações). A camada de segurança WPA2/WPA3 garante confidencialidade e autenticidade das comunicações.

5.1.3 Sistemas Operacionais de Tempo Real

Referência: BARRY, R. Mastering the FreeRTOS Real Time Kernel: A Hands-On Tutorial Guide. Real Time Engineers Ltd, 2016. 396 p.

ISBN: 978-1527299566

Link: https://www.freertos.org/Documentation/RTOS_book.html (disponível gratuitamente)

Resumo: Este livro, escrito pelo criador do FreeRTOS, constitui referência definitiva sobre sistemas operacionais de tempo real para microcontroladores. A obra é particularmente relevante para sistemas embarcados como robôs aspiradores que requerem gerenciamento de múltiplas tarefas concorrentes com requisitos temporais definidos.

O autor explica que RTOS difere fundamentalmente de sistemas operacionais convencionais por garantir tempos de resposta determinísticos. O kernel FreeRTOS implementa scheduling preemptivo baseado em prioridades, onde tarefas de alta prioridade interrompem tarefas de menor prioridade, assegurando que operações críticas (como detecção de cliff) executem dentro de janelas temporais especificadas.

O conceito de tarefa (task) é central: cada tarefa é função com loop infinito representando uma atividade do sistema. Para robô aspirador, estrutura típica inclui:

• Tarefa de aquisição sensorial (alta prioridade, 50 Hz)
• Tarefa de controle de motores (alta prioridade, 100 Hz)
• Tarefa de navegação (média prioridade, 10 Hz)
• Tarefa de comunicação (baixa prioridade, event-driven)

O livro detalha primitivas de sincronização: semáforos para sinalização entre tarefas, mutexes para proteção de recursos compartilhados (com mecanismo de priority inheritance para evitar inversão de prioridade), e filas para comunicação inter-tarefas com cópia segura de dados.

Um aspecto crítico discutido é o gerenciamento de memória. FreeRTOS oferece cinco esquemas de alocação (heap_1 a heap_5), sendo heap_4 o mais utilizado para aplicações que criam/destroem tarefas dinamicamente, pois implementa coalescing de blocos livres.

O autor enfatiza que o footprint do kernel é extremamente reduzido (~10 KB de código), tornando-o viável para microcontroladores com recursos limitados. A taxa de overhead de scheduling é tipicamente <5% de CPU, permitindo que a maior parte do tempo seja dedicada a tarefas de aplicação.

5.1.4 Controle de Motores Brushless DC

Referência: PILLAY, P.; KRISHNAN, R. Modeling, simulation, and analysis of permanent-magnet motor drives, Part II: The brushless DC motor drive. IEEE Transactions on Industry Applications, v. 25, n. 2, p. 274-279, 1989.

DOI: 10.1109/28.25542

Link: https://ieeexplore.ieee.org/document/25542

Resumo: Este artigo clássico apresenta modelagem e técnicas de controle para motores de corrente contínua sem escovas (BLDC), amplamente utilizados em sistemas de aspiração de robôs autônomos devido à sua eficiência energética superior e ausência de manutenção mecânica.

Os autores explicam que motores BLDC substituem o comutador mecânico por comutação eletrônica através de inversores trifásicos. Diferentemente de motores brushed convencionais, não há contato físico entre estator e rotor, eliminando desgaste de escovas de carvão e permitindo operação em ambientes com particulados (poeira), característica essencial para aspiradores.

O artigo apresenta dois métodos de controle: (1) controle com sensores Hall, onde três sensores de efeito Hall montados a 120° elétricos fornecem informação discreta sobre posição do rotor; e (2) controle sensorless, que detecta posição através de medição de back-EMF (força contra-eletromotriz) nas bobinas não energizadas.

Para aplicações de custo reduzido como robôs aspiradores, controle sensorless é preferível pois elimina componentes adicionais e simplifica montagem. O método funciona medindo tensão induzida pela rotação do ímã permanente do rotor nas fases não alimentadas. Quando esta tensão cruza tensão do ponto neutro, determina-se o momento de comutar para próxima fase.

O desafio do método sensorless é a inicialização: em repouso, não há back-EMF. Os autores propõem sequência open-loop inicial onde o motor é acelerado gradualmente até velocidade suficiente para gerar back-EMF mensurável (~10-15% da velocidade nominal), quando transiciona-se para controle closed-loop.

A eficiência de motores BLDC alcança 85-95% comparado a 75-80% de motores brushed equivalentes. Para um sistema alimentado por bateria, isto representa extensão significativa de autonomia. Adicionalmente, a relação torque/peso é aproximadamente 30% superior, permitindo sistema de aspiração mais compacto.

O artigo discute controle trapezoidal (six-step commutation), onde duas fases são energizadas simultaneamente em seis configurações distintas correspondendo a 60° elétricos de rotação. Este método, embora mais simples que controle senoidal (field-oriented control), produz ripple de torque mas é computacionalmente menos exigente, sendo viável para microcontroladores de menor capacidade.

5.2 Artigos sobre Aplicação e Uso

5.2.1 Eficiência de Limpeza em Robôs Autônomos

Referência: FORLIZZI, J.; DISALVO, C. Service robots in the domestic environment: a study of the Roomba vacuum in the home. Proceedings of the 1st ACM SIGCHI/SIGART Conference on Human-Robot Interaction, p. 258-265, 2006.

DOI: 10.1145/1121241.1121286

Link: https://dl.acm.org/doi/10.1145/1121241.1121286

Resumo: Este estudo etnográfico investigou o desempenho e aceitação de robôs aspiradores Roomba em 30 residências durante período de 6 meses. A pesquisa combina medições quantitativas de eficiência de limpeza com análise qualitativa de experiência do usuário.

Os autores empregaram metodologia experimental para avaliar eficiência: distribuíram pó fluorescente padronizado em áreas de teste e utilizaram iluminação UV para quantificar remoção após operação do robô. Os resultados demonstraram taxa de remoção de 85-92% em pisos lisos (cerâmica, madeira) e 60-75% em carpetes, comparado a 90-95% para aspiradores manuais em superfícies equivalentes.

Um achado significativo foi que eficiência por sessão inferior é compensada por frequência de uso: participantes utilizaram o Roomba em média 4-5 vezes por semana (geralmente diário em dias úteis), comparado a 1-2 vezes por semana para aspiração manual. A concentração média de particulados PM10 foi menor em residências com uso diário do Roomba, sugerindo que frequência compensa eficiência individual.

O estudo identificou padrões de falha: 45% das interrupções foram causadas por emaranhamento em cabos, 25% por esgotamento de bateria distante da base, 18% por saturação do compartimento de sujeira, e 12% por outros erros (sensores, travamento). Isto evidencia que operação não é completamente autônoma, requerendo preparação do ambiente e manutenção periódica.

Análise de cobertura mediante rastreamento por câmera sobreposta mostrou que robôs com navegação aleatória atingem 85-90% de cobertura em 60 minutos para ambiente de 50m², enquanto modelos com mapeamento (disponíveis posteriormente) alcançam 95-98% no mesmo tempo. Áreas problemáticas incluem cantos agudos, sob móveis baixos (clearance <10cm), e transições entre pisos com desnível >15mm.

Os autores concluem que robôs aspiradores são complementares, não substitutos, de aspiração manual, sendo mais efetivos como ferramenta de manutenção diária entre limpezas profundas semanais.

5.2.2 Fatores de Aceitação de Robôs Domésticos

Referência: SUNG, J. Y.; GUO, L.; GRINTER, R. E.; CHRISTENSEN, H. I. "My Roomba is Rambo": Intimate home appliances. International Conference on Ubiquitous Computing (UbiComp 2007), LNCS 4717, p. 145-162, 2007.

DOI: 10.1007/978-3-540-74853-3_9

Link: https://link.springer.com/chapter/10.1007/978-3-540-74853-3_9

Resumo: Este artigo investiga fenômenos psicossociais associados à adoção de robôs de serviço doméstico, especificamente aspiradores autônomos. Os pesquisadores conduziram entrevistas semi-estruturadas e observações em domicílio com proprietários de Roomba.

Um resultado proeminente foi a antropomorfização: 65% dos participantes atribuíram nome ao robô, 42% reportaram falar com o dispositivo, e 32% manifestaram sentimentos de culpa quando o robô "enfrentava dificuldades" (ficava preso ou com bateria esgotada). Este fenômeno de atribuição de características humanas a robôs é documentado na literatura de HRI (Human-Robot Interaction) e influencia significativamente a satisfação do usuário.

Os autores categorizaram usuários em três perfis:

1. Pragmáticos (38%): Focam exclusivamente em funcionalidade, tratam como ferramenta
2. Companheiros (42%): Atribuem personalidade, desenvolvem vínculo emocional
3. Pets (20%): Tratam explicitamente como animal de estimação, exibem comportamento de cuidado

Análise de fatores de satisfação mediante escala Likert (1-5) revelou: facilidade de uso (média 4.2 ± 0.8), eficácia percebida (3.7 ± 1.1), confiabilidade (3.5 ± 1.2), e integração em rotina (4.5 ± 0.6). Notavelmente, satisfação não correlacionou fortemente com desempenho objetivo de limpeza (r = 0.32), mas correlacionou significativamente com transparência operacional - capacidade do robô de comunicar seu estado e intenções (r = 0.71, p < 0.01).

O estudo identificou comportamento preparatório em 78% dos usuários: remoção de cabos e pequenos objetos antes de iniciar o robô. Este achado contraria a premissa de operação completamente autônoma, sugerindo que usuários adaptam o ambiente para acomodar as limitações do robô.

Implicações para design de sistemas embarcados incluem: (1) importância de feedback claro através de LEDs, sons e notificações; (2) necessidade de transparência sobre decisões do robô (por que parou, onde já limpou); (3) valor de personalização (nomes, sons customizáveis) para aumentar engajamento.

Os autores concluem que aceitação de robôs domésticos depende não apenas de desempenho técnico, mas significativamente de fatores de experiência do usuário e design de interação.

5.2.3 Navegação em Ambientes com Múltiplos Andares

Referência: THRUN, S.; BURGARD, W.; FOX, D. Probabilistic Robotics. MIT Press, 2005. Cap. 10: SLAM, p. 309-344.

ISBN: 978-0262201629

Link: http://www.probabilistic-robotics.org/

Resumo: Este livro seminal em robótica móvel dedica capítulo extenso ao problema de SLAM, com discussão específica sobre gerenciamento de múltiplos mapas, requisito para robôs operando em residências multi-andar.

Os autores formulam SLAM como problema de inferência bayesiana: dado histórico de observações z_{1:t} e comandos de controle u_{1:t}, estimar conjuntamente trajetória do robô x_{1:t} e mapa do ambiente m. A distribuição posterior é expressa como:

P(x_{1:t}, m | z_{1:t}, u_{1:t}) ∝ P(z_t | x_t, m) P(x_t | x_{t-1}, u_t) P(x_{t-1}, m | z_{1:t-1}, u_{1:t-1})

Para múltiplos andares, o desafio é reconhecer quando o robô foi transportado manualmente para andar diferente (problema de "kidnapped robot"). Os autores propõem solução baseada em global localization: manter múltiplas hipóteses de localização (uma para cada mapa conhecido) e usar particle filter para estimar probabilidade de cada hipótese.

O algoritmo detecta relocação quando likelihood de todas partículas no mapa atual cai abaixo de limiar, acionando fase de re-localização onde partículas são uniformemente distribuídas entre todos mapas conhecidos. Através de múltiplas observações, particles convergem para mapa correto.

Para reconhecimento de lugar (place recognition), técnica de bag of visual words é apresentada: features visuais (SIFT, SURF) extraídas de imagens são quantizadas em vocabulário visual, e cenas são representadas como histogramas de palavras visuais. Similaridade entre cenas é computada através de distância de Bhattacharyya entre histogramas.

O texto discute trade-off de memória: manter mapa único grande vs múltiplos mapas menores. Para robôs com memória limitada (típico em sistemas embarcados), abordagem hierárquica é preferível: cada andar é mapa separado, e meta-grafo conecta mapas via nós de transição.

Resultados experimentais apresentados demonstram que sistema com reconhecimento automático de andar atinge taxa de acerto de 94% após exploração inicial, com tempo médio de reconhecimento de 3.2 segundos (com partículas N=1000).

A aplicabilidade a robôs aspiradores é direta: modelos premium como Roomba i7+ e Roborock S7 implementam estas técnicas, permitindo que usuário carregue manualmente o robô para andar diferente, onde este automaticamente identifica e carrega mapa apropriado.

5.2.4 Impacto na Qualidade do Ar Interior

Referência: KNIBBS, L. D.; HE, C.; DUCHAINE, C.; MORAWSKA, L. Vacuum cleaner emissions as a source of indoor exposure to airborne particles and bacteria. Environmental Science & Technology, v. 46, n. 1, p. 534-542, 2012.

DOI: 10.1021/es202946w

Link: https://pubs.acs.org/doi/10.1021/es202946w

Resumo: Este estudo experimental investigou emissões de partículas de diferentes tipos de aspiradores, incluindo robôs autônomos, e seu impacto na qualidade do ar interior. A pesquisa é particularmente relevante considerando que robôs aspiradores operam frequentemente com ocupantes presentes.

A metodologia envolveu câmara de teste controlada (40 m³) com monitoramento contínuo de concentração de partículas utilizando contador óptico (resolução 0.3-10 μm) e amostragem microbiológica. Aspiradores testados incluíram modelos Roomba 530, Neato XV-11, e unidade genérica com filtro HEPA.

Resultados demonstraram que aspiradores sem filtro HEPA efetivo causam ressuspensão significativa de partículas finas: concentração de PM2.5 aumentou 35-40% durante operação, com pico de 45 μg/m³ comparado a baseline de 12 μg/m³. Mecanismo principal é a exaustão de ar não-filtrado contendo partículas que atravessam filtro inadequado.

Em contraste, robôs equipados com filtro HEPA classe E11 ou superior apresentaram ressuspensão limitada (<10%), com concentração de PM2.5 mantendo-se em 14-16 μg/m³. A norma HEPA (High Efficiency Particulate Air) especifica eficiência mínima de 99.95% para partículas de 0.3 μm (tamanho de máxima penetração).

O estudo comparou uso diário de robô vs aspiração manual bi-semanal ao longo de 4 semanas em 20 residências. Grupo com robô + HEPA apresentou concentração média semanal de PM2.5 de 12.1 ± 3.2 μg/m³, enquanto grupo com aspiração manual 2x/semana teve 15.6 ± 4.8 μg/m³. A diferença estatisticamente significativa (p = 0.031, teste t) é atribuída à frequência: limpeza diária previne acumulação de particulados.

Análise microbiológica revelou que aspiradores ressuspendem também bioaerossóis (bactérias, esporos de fungos). Concentração de UFC/m³ (unidades formadoras de colônia por metro cúbico) aumentou 50-80% durante operação de aspiradores sem HEPA, permanecendo elevada por 30-45 minutos pós-operação devido ao tempo de sedimentação de partículas finas.

Implicações para saúde pública são significativas: indivíduos com asma, alergias ou imunocomprometidos podem se beneficiar de aspiradores (robóticos ou manuais) com filtração HEPA certificada. O estudo sugere que fabricantes implementem monitoramento de saturação do filtro, alertando usuário para substituição, pois eficiência degrada progressivamente com acúmulo de material particulado.

Em sistemas embarcados mais avançados, a integração de sensores de qualidade do ar (particulate matter sensor como PMS5003) permite ajuste adaptativo de potência de sucção e alertas de manutenção baseados em condição real ao invés de tempo fixo.

6. Comparativo com Produtos Relacionados

Para contextualizar a evolução tecnológica de robôs aspiradores, realizou-se análise comparativa de seis produtos representativos abrangendo diferentes gerações e fabricantes.

6.1 Tabela Comparativa

6.2 Análise Evolutiva

Primeira Geração (2002-2010): Navegação Reativa

O Roomba original (2002) estabeleceu viabilidade comercial da categoria utilizando arquitetura de subsumption de Brooks: múltiplos comportamentos reativos com prioridades hierárquicas. A navegação aleatória, embora ineficiente, demonstrou cobertura estatística suficiente para ambientes residenciais típicos.

Limitações incluíam: ausência de memória (passava múltiplas vezes em mesmas áreas), bateria NiMH com densidade energética inferior, e impossibilidade de interface remota.

Segunda Geração (2011-2016): Introdução de SLAM

Roomba 980 (2015) representou salto tecnológico com implementação de SLAM visual: câmera de baixa resolução orientada verticalmente captura características do teto, combinada com odometria para construir mapa persistente. Isto permitiu cobertura sistemática e funcionalidades como "limpeza de cômodo específico".

Concorrentes como Neato introduziram LIDAR, oferecendo mapeamento mais preciso mas a custo superior. A topologia circular foi desafiada pelo formato em "D" da Neato, argumentado como mais efetivo para limpeza de cantos.

Terceira Geração (2016-2020): Democratização Tecnológica

Xiaomi Mi Robot (2016) disruptou mercado oferecendo LIDAR a preço acessível ($299), forçando reposicionamento de incumbentes. Processador quad-core permitiu algoritmos SLAM mais sofisticados e interface de usuário rica via aplicativo.

Roborock (spin-off da Xiaomi) adicionou função de passar pano (mopping), convergindo aspiração e limpeza úmida em dispositivo único.

Quarta Geração (2021-presente): Inteligência Artificial e Automação Completa

Modelos recentes incorporam processadores octa-core executando redes neurais para reconhecimento de objetos: detecção de cabos, roupas, e até fezes de animais (problema comum que causa falhas). Roborock S7 implementa "VibraRise": sistema que vibra o mop a 3000 rpm para limpeza mais efetiva e o eleva automaticamente ao detectar carpete.

Ecovacs X1 Omni representa extremo de automação: base inteligente esvazia automaticamente o compartimento de sujeira, lava e seca o mop, e reabastece água. Câmera RGB integrada permite monitoramento de segurança residencial.

6.3 Tendências Identificadas

Redução de Preço vs Aumento de Capacidade: Sensores LIDAR que custavam $100+ em 2015 hoje custam <$20 devido a escala de produção. Processadores ARM quad-core com capacidade antes restrita a smartphones são agora commoditizados.

Convergência Funcional: Produtos premium convergem múltiplas funções: aspiração, mop, purificação de ar, e vigilância através de câmera.

Integração Ecosistemas: Suporte nativo a Matter (padrão unificado de smart home) permitirá interoperabilidade entre fabricantes.

Transição para Modelos de Serviço: Alguns fabricantes exploram modelo "robot-as-a-service" com assinatura mensal incluindo manutenção e substituição.

6.4 Referências dos Produtos

• iRobot Roomba: https://www.irobot.com/roomba (Acesso em: 08 nov. 2025)
• Roborock: https://global.roborock.com (Acesso em: 08 nov. 2025)
• Xiaomi Mi Robot: https://www.mi.com/global/mi-robot-vacuum (Acesso em: 08 nov. 2025)
• Ecovacs: https://www.ecovacs.com (Acesso em: 08 nov. 2025)
• Neato Robotics: https://neato.com (Acesso em: 08 nov. 2025)

7. Conclusão

O presente estudo analisou sistemas embarcados em robôs aspiradores autônomos, identificando as principais tecnologias habilitadoras: SLAM para navegação inteligente, protocolos de comunicação sem fio para conectividade IoT, RTOS para gerenciamento de múltiplas tarefas concorrentes, e controle eficiente de motores brushless.

A proposta de implementação com ESP32 demonstrou viabilidade técnica para reproduzir funcionalidades básicas de navegação autônoma, embora com limitações significativas em comparação a produtos comerciais. A ausência de capacidade de processamento para SLAM em tempo real restringe o protótipo a navegação reativa, sendo suficiente para demonstração de conceitos fundamentais mas limitada para operação eficiente em ambientes complexos.

A pesquisa bibliográfica evidenciou que robôs aspiradores representam convergência de múltiplas disciplinas: robótica móvel (navegação, localização), sistemas embarcados (hardware/software em tempo real), processamento de sinais (sensores, controle), e interação humano-robô (interface, aceitação). O sucesso comercial da categoria depende não apenas de desempenho técnico objetivo, mas também de fatores de experiência do usuário como transparência operacional e confiabilidade percebida.

A análise comparativa revelou trajetória de evolução marcada por: (1) transição de navegação aleatória para baseada em mapas, (2) incorporação progressiva de inteligência artificial, (3) convergência funcional (aspiração + mop + monitoramento), e (4) democratização tecnológica com redução de custos.

Trabalhos futuros poderiam explorar implementação de SLAM simplificado na ESP32 mediante técnicas como landmarks reduzidos ou offloading de processamento pesado para servidor externo, mantendo apenas localização no dispositivo. Adicionalmente, integração de sensores de qualidade do ar permitiria sistema adaptativo que ajusta potência de sucção baseado em concentração real de particulados.

8. Referências Bibliográficas

BARRY, R. Mastering the FreeRTOS Real Time Kernel: A Hands-On Tutorial Guide. Real Time Engineers Ltd, 2016. 396 p. ISBN 978-1527299566. Disponível em: https://www.freertos.org/Documentation/RTOS_book.html. Acesso em: 08 nov. 2025.

ESPRESSIF SYSTEMS. ESP32 Technical Reference Manual. Version 4.6. San Jose, CA: Espressif Systems, 2023. Disponível em: https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf. Acesso em: 08 nov. 2025.

FORLIZZI, J.; DISALVO, C. Service robots in the domestic environment: a study of the Roomba vacuum in the home. In: ACM SIGCHI/SIGART CONFERENCE ON HUMAN-ROBOT INTERACTION, 1., 2006, Salt Lake City. Proceedings [...]. New York: ACM, 2006. p. 258-265. DOI: 10.1145/1121241.1121286.

IEEE COMPUTER SOCIETY. IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std 802.11-2020. New York: IEEE, 2020. DOI: 10.1109/IEEESTD.2021.9363693.

KNIBBS, L. D.; HE, C.; DUCHAINE, C.; MORAWSKA, L. Vacuum cleaner emissions as a source of indoor exposure to airborne particles and bacteria. Environmental Science & Technology, v. 46, n. 1, p. 534-542, 2012. DOI: 10.1021/es202946w.

OBREGON, E.; PARK, J.; PARK, S.; KIM, T.; CHOI, S. IEEE 802.11ah: A Long Range 802.11 WLAN at Sub 1 GHz. Journal of ICT Standardization, v. 1, n. 1, p. 83-108, 2013. DOI: 10.13052/jicts2245-800X.112.

PILLAY, P.; KRISHNAN, R. Modeling, simulation, and analysis of permanent-magnet motor drives, Part II: The brushless DC motor drive. IEEE Transactions on Industry Applications, v. 25, n. 2, p. 274-279, 1989. DOI: 10.1109/28.25542.

SUNG, J. Y.; GUO, L.; GRINTER, R. E.; CHRISTENSEN, H. I. "My Roomba is Rambo": Intimate home appliances. In: INTERNATIONAL CONFERENCE ON UBIQUITOUS COMPUTING, 9., 2007, Innsbruck. Proceedings [...]. Berlin: Springer, 2007. p. 145-162. (Lecture Notes in Computer Science, v. 4717). DOI: 10.1007/978-3-540-74853-3_9.

TAKETOMI, T.; UCHIYAMA, H.; IKEDA, S. Visual SLAM algorithms: a survey from 2010 to 2016. IPSJ Transactions on Computer Vision and Applications, v. 9, n. 16, 2017. DOI: 10.1186/s41074-017-0027-2.

THRUN, S.; BURGARD, W.; FOX, D. Probabilistic Robotics. Cambridge, MA: MIT Press, 2005. 647 p. ISBN 978-0262201629.