Fundamentos de eletrônica de robôs: roteiro de aprendizagem
Você pode alimentar um robô que permanece ligado sob carga, colocar vários sensores em um barramento I²C e escrever um laço que os leia sem bloquear.
A maioria dos problemas de robô que parecem problemas de software não é. A placa reinicia e a culpa vai para o código; um sensor retorna dados sem sentido e a culpa vai para a biblioteca; o robô ignora o sensor de contato e a culpa vai para a lógica. Em cada caso, a falha está em uma camada inferior, na parte do sistema sobre a qual ninguém escreveu um tutorial porque parecia básica demais para precisar de um.
Esta trilha é essa camada. Ela cobre alimentação — por que a tensão de uma bateria desaba quando os motores começam e o que fazer a respeito; o barramento I²C — o que realmente fazem os dois fios compartilhados por todos os sensores — e a temporização — por que um laço que para para esperar resulta em um robô incapaz de reagir.
Nada disso é difícil. Tudo isso é pressuposto por todas as outras trilhas deste site.
Antes de começar
Você precisa de um microcontrolador que já consiga gravar e da disposição para colocar um multímetro nos terminais de uma bateria. Não precisa de teoria de controle nem de matemática além de soma e uma divisão. Se já construiu qualquer coisa, como um LED piscando, está pronto.
O que você será capaz de fazer
- Distinguir um reinício de uma falha em menos de um minuto e saber qual deles está ocorrendo antes de abrir qualquer código.
- Somar o consumo de corrente de um robô e escolher um pacote de bateria com base no resultado, não no que veio no kit.
- Explicar por que uma bateria de 9 V com a maior tensão da prateleira dá o pior resultado sob carga e prever o quanto qualquer pacote vai cair.
- Conectar vários sensores a um barramento I²C, encontrá-los com um scanner e resolver uma colisão de endereços de três maneiras diferentes.
- Escrever um laço que lê sensores, aciona motores e informa o status em três ritmos diferentes sem nunca bloquear — e fazer a comparação do estouro corretamente.
- Medir o pior tempo possível do seu próprio laço em vez de pressupô-lo.
Onde as pessoas costumam travar
Tratar “não reiniciou” como prova de que a alimentação está correta. O detector de subtensão de um Arduino é configurado em 2,7 V, mas um ATmega328P de 16 MHz precisa de cerca de 3,8 V para funcionar dentro da velocidade nominal. Nessa faixa, o chip opera fora das especificações e nada o impede, e é onde vivem as falhas mais estranhas de um robô — variáveis corrompidas, um servo que salta, um sensor que retorna dados plausíveis sem sentido.
Adicionar um capacitor e esperar que ele elimine o reinício. A conta diz o contrário: um capacitor de 1000 µF que tivesse de conduzir uma surta de 2 A durante 10 ms perderia 20 V. Ele reduz a ondulação de chaveamento e os picos de comutação, o que vale a pena, mas somente uma bateria com menor resistência interna consegue conduzir o surto.
Empilhar placas de extensão em um barramento. Quase toda placa vem com seus próprios resistores de pull-up, e eles entram em paralelo. Três placas já deixam o sistema no limite, e a quarta leva o barramento abaixo da corrente que qualquer dispositivo consegue drenar — assim, três sensores funcionam e o quarto derruba todos, sem nada realmente quebrado.
Ler um endereço de 8 bits do datasheet. O datasheet de uma MPU-6050 informa 0xD0; a biblioteca
do Arduino espera 0x68, os mesmos bits deslocados uma posição à direita. Este é o erro de I²C mais
comum e parece exatamente uma placa morta.
Escrever now >= last + interval. A forma parece mais natural que a subtração, mas falha no
estouro de 49,7 dias e faz o laço disparar continuamente, em vez de esperar. Sempre subtraia.
Culpar a lógica do laço por um laço bloqueado. As interrupções continuam durante delay(), então
uma contagem do encoder permanece perfeitamente correta enquanto o robô deixa de reagir — o que faz o
sintoma parecer um bug de decisão, não de temporização.
O que você precisa
| Item | Por que esta trilha precisa dele | Custo aprox. |
|---|---|---|
| Um microcontrolador que você possa gravar | Todas as medições aqui são feitas em uma placa em funcionamento, não no papel | Arduino Uno, clone de ~$8 |
| Um multímetro | O instrumento sem o qual esta trilha não pode ser feita — cada afirmação é uma medição que você mesmo verifica | ~$15 |
| Um pacote de bateria sob carga | Um pacote medido sem nada conectado não informa nada; você precisa de um que alimente algum dispositivo | Suporte 4×AA ou Li-ion 2S |
| Duas placas de extensão I²C | Uma placa nunca revela o problema de pull-up. Duas começam a revelá-lo | MPU-6050 + qualquer outra, ~$5 |
| Um ou dois motores | A carga que faz o trilho cair — a falha que esta trilha existe para explicar | Qualquer motorredutor de CC |
Não é preciso um osciloscópio. Todas as medições desta trilha são de corrente contínua e um multímetro barato consegue fazê-las.
Por que a trilha segue esta ordem
A ordem não é arbitrária — cada nó elimina uma forma de o próximo poder enganar você.
A temporização vem antes de tudo o que é medido. Um laço bloqueado torna suspeita qualquer outra medição, porque você não consegue mais dizer quando a leitura foi feita. Depois que o laço não bloqueia, você pode confiar em um carimbo de tempo, e só então a medição vale ser registrada.
A alimentação vem antes da entrada analógica. analogRead no Arduino é ratiométrico: informa a
entrada como uma fração de sua referência, e a referência padrão é o mesmo trilho de 5 V que os
motores derrubam. Meça uma bateria por um divisor em um trilho que cai e a leitura aumenta quando
a bateria diminui. Medir uma tensão de forma confiável é impossível até saber o que o trilho está
fazendo, portanto o nó de alimentação precisa vir primeiro.
O I²C vem depois da alimentação, mas é independente da entrada analógica. O barramento é um subsistema separado e falha por um mecanismo próprio — pela conta dos resistores de pull-up e por colisões de endereços, não pela queda da tensão de alimentação. Ele está ligado diretamente ao nó da placa, e é por isso que a árvore se ramifica ali.
O laboratório vem por último. O simulador de sensores permite adicionar ruído, viés e falhas a um sinal limpo de propósito. Isso só é instrutivo depois que você viu seu próprio equipamento produzi-los sem querer e sabe a causa de cada um.
Pontos de verificação: como saber que uma etapa foi dominada
Cada item abaixo é um teste de bancada, não um questionário. Se você não consegue produzir o número, a etapa não terminou.
| Etapa | Verificação | Como é um resultado aprovado |
|---|---|---|
| Temporização não bloqueante | Exiba a duração máxima do seu laço durante 10 segundos | Um número em microssegundos que você mediu, não um que supôs — e que não aumenta quando um sensor é desconectado |
| Bateria sob carga | Meça a tensão do pacote com os motores desligados e depois com o motor em travamento | Você pode informar a queda de tensão e dividi-la pela corrente para obter a resistência interna do pacote |
| Orçamento de potência | Some no papel o consumo de cada dispositivo e depois meça o total | Papel e multímetro concordam em cerca de 20%; se não, você encontrou um dispositivo consumindo mais do que o datasheet informa |
| Entrada analógica | Leia a mesma bateria pelo divisor com os motores desligados e em funcionamento | A leitura não muda quando os motores começam — se mudar, sua referência está se movendo |
| Barramento I²C | Execute um scanner do barramento adicionando uma placa por vez | Todos os endereços aparecem, e você pode informar a resistência total de pull-up no barramento |
| Colisão de endereços | Conecte o pino AD0 da MPU-6050 em nível alto | O scanner informa 0x69 em vez de 0x68 — e você pode explicar por que o datasheet informa 0xD0 |
Onde esta trilha termina
Este roteiro termina deliberadamente no ponto em que a eletrônica deixa de enganar você. Ele não cobre drivers de motor, malhas de controle nem qualquer coisa que decida para onde um robô deve ir — esses são os temas das trilhas de controle de motores e controle PID, e ambas pressupõem tudo o que foi visto aqui.
Ela também para antes de três assuntos que vale conhecer. Não cobre reguladores comutados, que obtêm 5 V a partir de um pacote de 12 V sem queimar a diferença como calor em um regulador linear. Não cobre deslocamento de nível entre dispositivos de 5 V e 3,3 V, necessário na primeira vez que você conectar um ESP32 e um sensor de 5 V ao mesmo barramento. E não cobre layout de PCB ou soldagem — tudo aqui é feito em protoboard, o que é adequado para aprender e também uma fonte de falhas intermitentes quando o robô começa a se mover.
Roteiro de aprendizagem
O caminho
Siga os nós em ordem — cada um desbloqueia o próximo depois que você o conclui. Seu progresso fica salvo neste dispositivo.
0 / 9 concluídos
Dúvidas comuns
Perguntas frequentes
Que conhecimento de eletrônica preciso antes de construir um robô?
Três coisas, nenhuma avançada. Você precisa dimensionar uma fonte de alimentação pela corrente que o robô realmente consome, para que ele não reinicie quando os motores começarem. Precisa entender o barramento I²C o suficiente para conectar vários sensores a dois fios compartilhados sem que interfiram uns nos outros. E precisa escrever uma malha de controle que nunca para para esperar, para que o robô possa reagir enquanto faz outra coisa. Tudo o mais — teoria de controle, navegação, cinemática — é construído sobre essas três.
Por que meu Arduino reinicia quando os motores começam?
A resistência interna da bateria transforma a corrente de entrada dos motores em uma queda de tensão, e todo o trilho despenca junto. Um motor que consome uma surta de 2 A por um pacote com 0,5 Ω de resistência interna derruba o trilho em 1 V antes de qualquer corrente chegar ao regulador. Se essa queda levar a placa abaixo do limiar de queda de tensão, ela reinicia por queda de tensão. A solução é uma bateria com menor resistência interna e uma fonte separada para os motores, não um capacitor maior — um capacitor de 1000 µF que tivesse de conduzir 2 A durante 10 ms perderia 20 V e não conseguiria sustentar um surto desse tamanho.
Quantos sensores I²C posso conectar a um Arduino?
O espaço de endereços permite 112 dispositivos, mas o limite elétrico chega muito antes. Quase toda placa de extensão traz seus próprios resistores de pull-up, normalmente de 4,7 kΩ, e empilhá-los coloca os resistores em paralelo. Quatro placas resultam em cerca de 1,2 kΩ, o que, a 5 V, exige mais de 4 mA de corrente de drenagem, acima dos 3 mA que um dispositivo I²C deve suportar. Três placas normalmente funcionam, e a quarta derruba todo o barramento. Remova os pull-ups de todas, exceto uma, e você poderá avançar muito mais.
delay() é realmente tão ruim no código de um robô?
Para um robô, sim. Enquanto o processador fica pausado por delay(), ele não lê sensores nem toma decisões — um robô em delay(500) fica cego por meio segundo, o que, a 0,3 m/s, representa 15 cm de deslocamento. O que dificulta o diagnóstico é que as interrupções continuam funcionando, então as contagens do encoder permanecem perfeitamente corretas. O sintoma parece lógica de decisão quebrada, não temporização bloqueada. Substitua-o pelo padrão millis() e subtraia, em vez de somar, ao comparar; caso contrário, a comparação falha no estouro de 49,7 dias.
Preciso de um osciloscópio para fazer esta trilha?
Não. Um multímetro basta para tudo aqui — medir a tensão de uma bateria sob carga, verificar a saída de um divisor e confirmar que um trilho não caiu. Um osciloscópio torna subtensões e problemas de I²C muito mais fáceis de visualizar; se você tiver um, deve usá-lo, mas todas as medições solicitadas aqui são de corrente contínua que um multímetro de £10 consegue fazer.
Quanto tempo leva este roteiro?
Cerca de duas horas de leitura nos quatro tutoriais e, na prática, uma ou duas noites na bancada para fazer as medições. As medições são o essencial — os números que esta trilha ensina a confiar são a queda da sua própria bateria, a resistência total de pull-up do seu próprio barramento e o pior tempo do seu próprio laço, e nenhum deles pode ser consultado em uma tabela.