Tempo real não significa apenas rapidez
No controlo de um robô, dizer que uma tarefa é de tempo real não significa apenas que é executada rapidamente. Significa que o resultado tem de estar disponível dentro de um prazo relevante para a aplicação. Se uma tarefa de controlo tiver de ler sensores, calcular uma resposta e atualizar atuadores antes de determinado limite, importam tanto o tempo de execução como a sua variabilidade e a possibilidade de falhar o prazo. Uma média baixa não basta para demonstrar um comportamento previsível.
Esta distinção é importante porque uma tarefa pode ser rápida na maioria das execuções e, ainda assim, demorar demasiado noutras. A média descreve o comportamento habitual, mas, por si só, não mostra o que acontece nos casos mais lentos nem com que frequência ocorrem. Para avaliar o requisito temporal, é necessário observar a resposta em relação ao prazo a cumprir, em vez de apenas comparar velocidades médias. A questão é saber se a tarefa termina a tempo nas condições avaliadas, não se costuma ser rápida.
O requisito concreto varia consoante a função. Uma interface de supervisão pode tolerar atrasos inaceitáveis num ciclo de controlo. A aquisição de dados, o processamento e a comunicação com atuadores também podem ter prazos diferentes. Por isso, antes de escolher uma arquitetura, convém definir que tarefa deve responder, qual o seu prazo, com que frequência se repete e quais as consequências de uma resposta tardia. Sem estes requisitos, «tempo real» corre o risco de se tornar um rótulo impreciso, em vez de um critério verificável. Defini-los separadamente também evita tratar como equivalentes etapas com funções e necessidades temporais distintas.
O que o ROS 2 oferece à execução
A documentação do ROS 2 aborda a programação em tempo real como uma questão com requisitos e dificuldades de implementação, não como uma propriedade obtida automaticamente por se utilizar o framework. Assim, é útil distinguir as ferramentas que o ROS 2 oferece da demonstração de que uma aplicação específica cumpre os seus prazos. A documentação técnica pode orientar a configuração e a análise, mas não substitui a definição dos requisitos do robô nem os testes da implementação escolhida.
Em particular, a presença de mecanismos de configuração não deve ser entendida como garantia de que um resultado chegará dentro de um prazo de ponta a ponta. Um percurso de dados pode incluir comunicação, escalonamento, processamento e resposta dos atuadores; o tempo observado depende do percurso avaliado e das condições em que é executado. A interpretação correta é condicional: cada mecanismo deve ser avaliado numa configuração específica e em conjunto com o restante da aplicação.
Ao avaliar uma configuração, convém descrever os componentes que participam no percurso relevante e o limite temporal que está a ser verificado. Esta descrição ajuda a interpretar as medições e evita atribuir o resultado a uma única opção de configuração. A documentação consultada trata a programação em tempo real como uma questão de implementação; não estabelece uma garantia global aplicável a todos os robôs. Uma avaliação útil deixa, portanto, claro o âmbito de cada medição e conclusão.
Executores, callbacks e escalonamento
Os executores fazem parte da arquitetura de execução do ROS 2. A investigação académica sobre o escalonamento de cadeias de processamento num executor multithread do ROS 2 analisa o escalonamento e o tempo de resposta no contexto da cadeia, e não apenas através da medição da velocidade de um nó isolado. Isto reforça a necessidade de avaliar a organização do trabalho e as dependências entre tarefas para a configuração que se pretende utilizar.
Na prática, avaliar um executor implica analisar como o trabalho é organizado, não apenas quanto tempo uma função demora a executar-se quando não existem outras tarefas. O tratamento de callbacks faz parte do percurso entre uma entrada e uma resposta; por isso, as decisões de distribuição e execução têm de ser consideradas em conjunto com o restante percurso. O número de threads, por si só, também não descreve todo o escalonamento: importa a forma como se relaciona com as tarefas que a aplicação executa efetivamente.
Numa cadeia de processamento, a análise pode abranger as várias etapas envolvidas e as relações entre elas. A estrutura do executor e as dependências entre tarefas fazem parte do sistema avaliado. Os resultados de uma análise ou experiência associados a uma versão e configuração não devem ser transferidos automaticamente para outras versões, cargas ou plataformas. A investigação citada aborda uma configuração multithread específica; não equivale a uma garantia para todos os sistemas ROS 2.
O que fica fora do framework
O ROS 2 não elimina a influência do sistema operativo nem da plataforma onde é executado. A documentação do projeto sobre programação em tempo real apresenta o tema como um conjunto de requisitos e dificuldades de implementação, não como uma propriedade ativada simplesmente pela utilização do ROS 2. Como exemplo específico, a documentação do controlador ROS 2 da Universal Robots recomenda um sistema Ubuntu com capacidades de tempo real para esse controlador e indica que um kernel de baixa latência pode ser suficiente em muitas das situações descritas no guia. Esta recomendação diz respeito a esse controlador e não deve ser generalizada a todos os robôs ou aplicações.
Isto significa que duas implementações que utilizem ROS 2 não têm necessariamente o mesmo comportamento temporal se diferirem na plataforma ou na carga de trabalho. As observações devem estar associadas às condições em que foram obtidas: os componentes do sistema e a configuração são importantes para interpretar o resultado. Sem essa informação, um valor isolado não permite saber se representa as condições que a aplicação terá de enfrentar.
Também não basta verificar que as mensagens chegam ou que uma demonstração funciona em condições controladas. Um teste deve representar a carga e a sequência de trabalho da aplicação, registar os tempos relevantes e ter em conta os casos lentos, não apenas as médias. Convém medir de ponta a ponta, desde o evento que inicia o trabalho até à resposta relevante para o robô. Se o requisito for de segurança ou de missão crítica, a evidência de desempenho deve integrar uma avaliação mais ampla da arquitetura e do risco; um teste de desempenho isolado não equivale a uma certificação.
Uma verificação útil antes de adotar o ROS 2
Comece por documentar cada prazo: que evento o inicia, que resposta o satisfaz, com que frequência se repete e que margem existe. Em seguida, desenhe a cadeia de processamento que liga sensores, nós e atuadores. Para cada segmento, registe os componentes envolvidos, o trabalho que executam e as dependências de outras tarefas. Esta descrição transforma uma expectativa geral em perguntas verificáveis e ajuda a identificar se o atraso tem origem na comunicação, no escalonamento ou no trabalho da aplicação.
A descrição de cada prazo também deve distinguir claramente o início do trabalho da resposta considerada válida. Esta precisão permite comparar as medições com o requisito correspondente, em vez de medir por conveniência uma etapa diferente. Se existirem várias etapas, manter a relação entre elas na cadeia facilita a interpretação de onde o tempo se acumula e evita confundir o desempenho local de um componente com a resposta completa de que o robô necessita.
Depois, fixe a versão do ROS 2, o middleware, o sistema operativo, o hardware e a configuração a avaliar. Teste a carga esperada e condições desfavoráveis plausíveis, meça as etapas e a resposta completa e guarde a configuração com os resultados. Repita os testes após alterações importantes e confronte as conclusões com a documentação aplicável a essa versão. O objetivo não é demonstrar que o ROS 2 é «de tempo real» em abstrato, mas determinar se uma implementação definida cumpre requisitos definidos em condições documentadas. As fontes consultadas sustentam capacidades de configuração e análise, mas não estabelecem uma garantia universal de cumprimento para qualquer robô.