COMUNICAÇÃO APLICADA UTILIZANDO MODBUS
Aluno: Rodrigo Sávio Gonçalves de Menezes Orientador: Wouter Caarls
Introdução
A equipe do laboratório de controle inteligente desenvolveu placas de circuitos elétricos para o controle e manutenção dos sistemas embarcados do robô móvel SoyBot que será utilizado em agricultura de precisão. O sistema desse robô consiste em um NUC que funciona como o “cérebro”, controlando o sistema como um todo, além de placas para power/switching que filtram e distribuem toda a energia e sinais de controle para atuadores e placas destinatárias, assim como placas para driver motor interface/sensors, que gerenciam os sinais lidos dos sensores e os sinais de controle enviados para os motores principais de ambos os lados esquerdo e direito do robô, que são utilizados para a sua locomoção.
Os algoritmos de inteligência artificial implementados nesse robô geram sinais de controle que devem ser comunicados a um sistema embarcado, e para que a comunicação seja mais robusta, a interface escolhida foi a RS-485.
O protocolo ideal é o MODBUS por ter várias características importantes para a comunicação desejada. Entre elas: Mestre-escravo, onde só o computador central (mestre) pode iniciar a comunicação, e assim, evitar colisão; Checksum, onde todos os pacotes possuem um CRC de 16 bits, que permite a detecção de erros de transmissão, e MODBUS-RTU, que usa uma codificação binária eficiente, fazendo com que o sistema possa alcançar uma frequência de controle alta mesmo com largura de banda baixa.
MODBUS foi desenvolvido para a comunicação entre PLCs, então trabalha sobre o conceito de registros digitais (bobinas) ou analógicos. Existem vários comandos para ler e escrever esses registros.
Objetivos
Desenvolver software embarcado para comunicar com PC através de MODBUS sobre RS-485. Desenvolver software em Linux para comunicar com controlador através de MODBUS sobre RS-485. Testar a robustez e desempenho da comunicação em condições adversas.
Metodologia
Utilizando o protocolo MODBUS no modo RTU a comunicação entre os microcontroladores ATMEGA328p (presentes nas placas de power/switching e driver motor
interface/sensors) e o computador central (NUC) é formada e gerenciada.
Os microcontroladores são tratados aqui como “Slaves” e o NUC como “Master”. As placas de power/switching da esquerda e direita têm endereços 4/5 e as placas driver 8/9.
O software dos microcontroladores foi implementado usando a biblioteca SimpleModbusSlaveV101 e o computador central usando libmodbus2. Em geral, os valores são definidos em termos de baixo nível: contas do ADC, pulsos do encoder, nível do PWM e etc. Para os valores que precisam de mais que 16 bits são usados registros sequenciais, sempre começando com os bits maiores.
1 Fonte: https://github.com/jecrespo/simple-modbus 2 Fonte: https://libmodbus.org/
O driver para a comunicação entre as placas eletrônicas e o PC embarcado implementa várias técnicas para aumentar a robustez e monitorar o funcionamento do sistema.
No baixo nível, o checksum (CRC) do protocolo MODBUS evita a interpretação errada de mensagens mal recebidas. Em vez de retransmitir mensagens não recebidas, o driver integra um sistema de supervisão, que continuamente verifica o estado das placas. Caso não esteja no estado desejado, a configuração é retransmitida.
Além de resolver problemas de transmissão, esse sistema lida com a recuperação do funcionamento depois de falta de conexão, falta de energia na placa e também da reinicialização do microcontrolador. No último caso ainda captura a trava do microcontrolador, pois integra um hardware watchdog que o reinicializa automaticamente quando o funcionamento é interrompido.
Em testes iniciais, com quatro placas a serem monitoradas, a supervisão acontece na frequência de 32 [Hz], que é suficiente para a retomada quase instantânea das atividades depois de uma falha.
Como as placas definem entradas e saídas genéricas, o driver foi implementado de uma forma genérica para interpretar os sinais dessas portas. Cada sinal define, no caso de sensores analógicos, o nome, desvio, inclinação e faixa de funcionamento; para sensores digitais, o nome e nível padrão; para atuadores, o nome e nível padrão e, para quaisquer outros dispositivos, o nome e nível padrão.
Durante o funcionamento do sistema, vários erros podem surgir. Desta forma, foi implementado um monitoramento do estado do sistema através de ros_diagnostics.
Os avisos que podem aparecer durante o monitoramento são: baixa frequência de supervisão, alta frequência de erros de comunicação, tensão está próxima a ultrapassar os limites, corrente está próxima a ultrapassar os limites, motor não habilitado, motor não mantém a velocidade desejada e dispositivo desligado.
Os erros detectados podem ser: placa não está respondendo, tensão ultrapassou os limites, corrente ultrapassou os limites, motor desligado devido ao sistema de segurança, motor indicou ALARM e sensor ultrapassou os limites.
Além de visualizar os erros, também fornece o estado geral do sistema (normal, aviso ou erro) para a máquina de estados, que então pode interromper a execução e/ou avisar o usuário.
Códigos no Arduíno
Pseudocódigo para a placa de power/switching Inicializar entradas e saídas
while true:
Ler tensões e correntes do ADC Escrever nos holding registers
Tratar comunicação MODBUS, se tiver
Ler estados desejados dos dispositivos dos holding registers Escrever saídas
O código para a placa de power/switching define os pinos e os holding registers necessários para a comunicação entre a mesma e o NUC e também define o BAUDRATE à 115200, valor esse que idealmente deveria ser maior mas por causa de limitações com a interface USB-RS485 disponível para os testes de bancada, foi mantido.
O código também possui uma função para ler o endereço do DIP switch da placa, calcular, e retornar o endereço slave da placa de power/switching que está se comunicando com o NUC naquele instante.
Na parte de setup, os pinmodes são definidos e cada pino e holding registers é inicializado. Além disso, é definido que o Watch Dog deve fazer automaticamente um RESET na placa depois de passados 250 [ms] sem encontrar uma determinada resposta, ou seja, se o programa der erro e parar de responder, isso acontecerá.
Na parte de loop, foram implantadas condições para monitorar o DIP switch e determinar se houve mudança no endereço do mesmo ou não, e se houver, mudar o endereço do slave sem precisar de RESET. Além disso, ocorre a leitura dos pinos e escrita dos valores nos holding registers determinados.
A função desse código é basicamente ler as tensões e correntes de todo o circuito do robô e o estado do relé do botão de emergência e mandar esses valores para o NUC que determina através dos mesmos o estado necessário para cada relé e retorna uma mensagem com esses estados para a placa.
Pseudocódigo para a placa de driver motor interface/sensors Inicializar entradas e saídas
Inicializar interrupt
while true:
Ler velocidade e posição atual Filtrar velocidade atual
Escrever nos holding registers
Tratar comunicação MODBUS, se tiver. Caso tenha, reinicializar timeout
Ler velocidade desejada dos holding registers Se timeout ultrapassado:
Definir velocidade desejada para 0 Escrever PWM e saída de direção
[interrupt]: atualizar velocidade e posição atual
O código para a placa de driver motor interface/sensors é parecido com o anterior, com as definições de pinos e os holding registers necessários para a comunicação entre a mesma e o NUC, BAUDRATE idêntico, função para determinar o endereço slave da placa através do
DIP switch e a mesma configuração para o Watch Dog que o código anterior.
O mesmo também possui uma função para contar os pulsos do encoder presente nos motores usados na locomoção do robô. O encoder manda 1500 pulsos por rotação da roda, sendo 30 pulsos por rotação do eixo e redução de 1:50. A função conta quanto tempo ocorre entre cada pulso e coloca esses valores em um filtro de 10 pulsos para filtrar a velocidade, ou seja, entre os pulsos 1 e 2, 10 microssegundos, 2 e 3, 11 microssegundos, assim por diante, criando um buffer cíclico de 10 leituras de tamanho.
Há também uma função que lê os valores desse buffer cíclico e calcula a média para determinar a velocidade das rodas. Nessa função, há uma condição para quando as rodas possuem uma velocidade muito baixa, por exemplo, quando ambas estão paradas. Nesse caso significa que não entram mais pulsos vindo do encoder das mesmas, e consequentemente, não entram mais valores no buffer, e se passarem 40 [ms] sem uma nova leitura de pulso, a função calculará a velocidade com base em todos os valores de tempo obtidos até o último pulso recebido, ou seja, o mesmo não terá 10 leituras de tamanho, será menor. Se essa condição não ocorrer, a função calcula a velocidade a cada 10 leituras.
Na parte de setup, os pinmodes são definidos e cada pino e holding registers é inicializado. Além disso, foi utilizado um PWM de 32 [kHz] ao invés do padrão de 400 [Hz] pois utilizando o segundo valor foi percebido a ocorrência de ripple na tela do osciloscópio.
Isso ocorre pois o filtro passa-baixas aplicado no pino de saída não conseguiu filtrar 400 [Hz], mas com 32 [kHz] o mesmo funciona e quase não acontece o efeito ripple.
Na parte de loop, também ocorre o monitoramento do DIP switch e do endereço do
slave, e a leitura dos pinos e escrita dos valores nos holding registers determinados. O driver
do motor possui uma saída para mensagens de emergência, que também é lida e registrada no
holding registers de alarmes. Cada registrador possui 16 bits, sendo 2 utilizados para
velocidade, ou seja, 32 bits e 4 utilizados para posição, ou seja, 64 bits pois como a leitura da segunda é constante e incrementada a cada ciclo sem ocorrer dump de memória, pode ocorrer
overflow. Há também uma condição de segurança que funciona da seguinte maneira: se a
placa receber alguma mensagem do NUC, é adicionado meio segundo ao timeout, mas, se não receber mensagem em meio segundo, o sistema para automaticamente, ou seja, se ultrapassar o timeout, o PWM sempre vai ser nulo. Há também a condição para escolha da orientação do robô, se ele andará pra frente ou em reverso, ou ainda, se a velocidade for zero, sendo que para o último caso, os pinos de orientação FWD, REV e também os motores são desligados e o robô freia através de atrito, ou seja, roda livre que perde velocidade ao mesmo tempo que o motor perde energia.
A função desse código é basicamente ler e contar os pulsos do encoder e o tempo entre cada um e mandar para o NUC a velocidade em PWM (entre 0 e 255), ou seja, tempo entre pulsos, e a posição em quantidade de pulsos. A ideia é fazer a comunicação entre master e
slave em baixo nível para poupar o microcontrolador de perda de eficiência com cálculos
pesados. A interpretação dos dados e cálculos de conversão de velocidade e posição para o SI é feita pelo NUC.
Resultados
Foi desenvolvido um Graphical User Interface (GUI) através de implementação dos códigos acima e códigos em ROS e C++ desenvolvidos pelo orientador do projeto. O mesmo possui 3 seções para mensagens do sistema que interagem com o usuário. A primeira parte, no
Error Device, exibe os erros, a segunda, no Warned Device, exibe os avisos e a terceira, no All Devices, exibe ambas as mensagens de erro e avisos. A seguir, capturas de tela do GUI
que é chamado de Robot Monitor.
Na figura 1, o sistema está no estado de warning pois há baixa tensão no sistema, como é visto nas mensagens de avisos.
Através de um duplo clique em cada mensagem, o GUI abre uma nova tela para detalhar o problema.
Foram realizados experimentos sobre as taxas de atualização e recuperação de erro. As placas de power/switching e driver motor interface/sensors foram conectadas a uma interface RS485-USB de 2 fios (baseado no CH340) e injetado ruído branco de vários níveis de amplitude entre os sinais A e B. O ruído foi gerado usando um HP 33120A, com um resistor de 220 [Ω] em série. O driver no computador manda valores de velocidade à placa
driver motor interface/sensors utilizando um seno de 1 [Hz] amostrado a 20 [Hz].
A taxa de atualização é o tempo entre ciclos de verificação de estado (um ciclo significa pedir o estado atual das duas placas e reenviar caso necessário). A mudança das velocidades são feitas em cima desses períodos (20 mensagens entram por segundo enviando um novo valor de velocidade).
Para medir o tempo de recuperação, é acionado o RESET das placas e contado o tempo até ambas recuperarem o estado atual.
Ampl Taxa Tempo de recuperação máximo
1VPP 61 [Hz] 126 [ms]
5VPP 58 [Hz] 154 [ms]
6VPP 25 [Hz] 958 [ms]
O tempo de recuperação é bem mais que 1/taxa, porque muitas vezes as mensagens pedindo ou corrigindo o estado não são recebidas corretamente.
Todas as medidas foram feitas através de um osciloscópio KEYSIGHT DSOX1102A/70 [MHz]. A seguir, as capturas de tela mostrando os timeouts devido à recepção incorreta da mensagem (CRC ou outro tipo de erro).
Figura 3. 20 [Hz] 5VPP 10pct error
Conclusões
O estudo sobre o protocolo MODBUS e a interface RS-485 permitiu uma maior compreensão sobre comunicação de sistemas elétricos e de controle.
Foi possível realizar a aplicação do método no projeto do Departamento sem muitas dificuldades.
O procedimento descrito no resumo deste projeto pode também ser implementado em qualquer sistema autônomo que envolva controle, tendo assim uma larga utilização nesta área por ser de fácil utilização e adaptação.
Referências
1 – Oliveira, A. (2019). Design and Development of an Autonomous Mobile Robot for Inspection of Soy and Cotton Crops. In: DeSE 2019 – Developments in eSystems Engineering, 2019, Kasan, Russia. DeSE 2019 – Developments in eSystems Engineering, 2019.
2 – MODBUS.org (2006), MODBUS over serial line specification and implementation guide
