Gerenciando múltiplos espaços de trabalho ROS com sobreposição de variáveis de ambiente

Estrutura de teste

Crie dois diretórios de trabalho independentes, cada um compilado com catkin_make. A organização é a sgeuinte:

.
├── espaco_a
│   ├── build
│   ├── devel
│   └── src
│       ├── pkg_a_um
│       └── pkg_a_dois
├── espaco_b
│   ├── build
│   ├── devel
│   └── src
│       ├── pkg_b_um
│       └── pkg_b_dois
└── inicializar.sh

Comportamento do source isolado e em cascata

Sem aplicar source a nenhum espaço: as variáveis CMAKE_PREFIX_PATH e ROS_PACKAGE_PATH contêm apenas os caminhos globais (ex.: /opt/ros/noetic). Comandos como rospack find não localizam os pacotes personalizados.

Carrgeando apenas o primeiro espaço:

source espaco_a/devel/setup.bash
echo $CMAKE_PREFIX_PATH
# /home/user/projetos/espaco_a/devel:/opt/ros/noetic:/opt/openrobots
echo $ROS_PACKAGE_PATH
# /home/user/projetos/espaco_a/src:/opt/ros/noetic/share

Os pacotes de espaco_a e os do sistema ficam acessíveis.

Carregando o segundo espaço em seguida:

source espaco_b/devel/setup.bash
echo $CMAKE_PREFIX_PATH
# /home/user/projetos/espaco_b/devel:/opt/ros/noetic:/opt/openrobots
echo $ROS_PACKAGE_PATH
# /home/user/projetos/espaco_b/src:/opt/ros/noetic/share

O primeiro espaço é removido do ambiente; apenas o segundo permanece visível. É o comportamento esperado do overlay do ROS 1, onde o último source define o topo da pilha.

O problema concreto

O cenário real exige que um nó do espaco_a referencie dinamicamente recursos de um pacote do espaco_b. Se apenas espaco_a estiver carregado, o recurso não é encontrado. Se carregarmos apenas espaco_b, o nó do primeiro espaço não inicia. O simples encadeamento de source não resolve porque o último sobrescreve.

Solução 1 – Compilação encadeada com ambiente herdado

Apague os artefatos de compilação do segundo espaço (build e devel). Em seguida, ative o primeiro espaço e compile o segundo dentro desse contexto:

rm -rf espaco_b/build espaco_b/devel

source espaco_a/devel/setup.bash

cd espaco_b && catkin_make

Agora, ao carregar apenas o ambiente do segundo espaço, o primeiro é incluído automaticamente:

source espaco_b/devel/setup.bash
echo $CMAKE_PREFIX_PATH
# .../espaco_b/devel:.../espaco_a/devel:/opt/ros/noetic:...
echo $ROS_PACKAGE_PATH
# .../espaco_b/src:.../espaco_a/src:/opt/ros/noetic/share

O catkin_make inspeciona as variáveis correntes e as embute nos scripts gerados. Desse modo, o ambiente do espaco_a é preservado como um underlay adicional do espaco_b.

Solução 2 – Ajuste manual no _setup_util.py

Alternativamente, edite o arquivo espaco_b/devel/_setup_util.py e insira o caminho do espaco_a diretamente nas listas de prefixos e pacotes, replicando o efeito da solução anterior sem recompilar.

Ambas as abordagens são úteis durante o desenvolvimento. Para ambientes de produção, recomenda-se consolidar os pacotes em um único espaço ou utilizar ferramentas de empacotamento que garantam a resolução de dependências sem depender da ordem de source.

Tags: ROS catkin_make source espaços de trabalho sobreposição

Publicado em 10-27 04:44