RoboStack: instale o ROS1 sem Docker, em qualquer sistema
Quem acompanha o logbook desta pesquisa sabe que o NUC embarcado no robô roda ROS Noetic dentro de um Ubuntu dedicado — a única opção realista quando o hardware físico está em jogo. Mas a maior parte do trabalho de um dia de pesquisa não acontece em cima do robô. Acontece escrevendo um nó, testando uma transformação TF, depurando uma mensagem antes de arriscar subir qualquer coisa pro NUC. E nesse momento o problema de sempre aparece: ROS1 foi pensado para uma versão específica do Ubuntu, e qualquer pesquisador num Mac, num Windows ou numa distro Linux mais recente precisa escolher entre dual-boot, máquina virtual ou um container Docker só para compilar um workspace.
RoboStack resolve esse problema de um jeito que boa parte da comunidade ROS1 ainda não conhece — e é justamente por isso que este texto existe: não como post, mas como página de referência técnica, separada do diário de bordo da tese, para quem quiser economizar o tempo que eu não economizei a primeira vez.
O que é RoboStack
RoboStack é uma distribuição do ROS — tanto ROS1 quanto ROS2 — empacotada inteiramente dentro do ecossistema Conda, construída sobre o conda-forge. Em vez de depender de pacotes .deb amarrados a uma versão exata do Ubuntu, o RoboStack compila o ROS e suas dependências como pacotes Conda comuns, instaláveis com mamba ou micromamba em Linux, macOS (incluindo Apple Silicon) e Windows.
Na prática, isso significa rodar ros-noetic-desktop dentro de um ambiente isolado, do mesmo jeito que qualquer pesquisador de dados já está acostumado a isolar um ambiente Python com Conda — sem tocar no sistema operacional, sem exigir uma versão específica de Ubuntu, e sem o overhead de uma VM ou de um container.
Por que isso importa pra quem trabalha com ROS1
ROS1 Noetic tem suporte oficial só até abril de 2025, e sua dependência declarada é Ubuntu 20.04. Qualquer pesquisador que:
- usa Mac (Intel ou Apple Silicon);
- já migrou pro Windows ou pra uma distro Linux mais nova;
- precisa manter dois ou três ambientes ROS diferentes na mesma máquina sem que um pacote conflite com o outro;
…historicamente caía em uma de três soluções: dual-boot, VM ou Docker. Todas funcionam, todas têm custo. Dual-boot rouba a máquina inteira. VM rouba performance gráfica (relevante pra RViz, Gazebo, qualquer coisa em OpenGL). Docker resolve o isolamento, mas adiciona uma camada extra de complexidade pra quem só queria compilar um workspace catkin e seguir com a pesquisa.
RoboStack troca essas três opções por um mamba create e alguns minutos de download.
Pré-requisitos
- Linux e macOS: nenhum pré-requisito além do instalador abaixo.
- Windows: além do instalador, é preciso ter o Visual Studio 2022 com suporte a C++ instalado, já que parte do ROS é compilada localmente durante a resolução de dependências.
Passo a passo: instalando o ROS Noetic
1. Instale o Micromamba
Em Linux e macOS, um único comando instala o Micromamba, configura o conda-forge como canal padrão e prepara o shell:
"${SHELL}" <(curl -L micro.mamba.pm/install.sh)
Abra um terminal novo depois de rodar esse comando, para que as variáveis de ambiente sejam carregadas.
Antes de continuar: nunca instale pacotes do ROS no ambiente base. Isso é a causa mais comum de ambientes quebrados — o RoboStack espera que conda/mamba fiquem isolados no base, e que o ROS viva só dentro do ambiente dedicado que você vai criar agora.
2. Crie o ambiente e instale o ROS Noetic
# Cria o ambiente "ros_env" com o ROS Noetic Desktop
micromamba create -n ros_env -c conda-forge -c robostack-noetic ros-noetic-desktop
# Ativa o ambiente
micromamba activate ros_env
# Garante que o canal robostack-noetic fique fixado neste ambiente
micromamba config append channels robostack-noetic --env
A ordem dos canais importa: conda-forge primeiro, robostack-noetic depois. Inverter essa ordem é uma fonte comum de conflito na resolução de dependências.
3. Ferramentas de desenvolvimento e catkin
Com o ambiente ativado, instale as ferramentas de build:
micromamba install -c conda-forge ros-dev-tools catkin_tools
catkin_tools é a ferramenta de build recomendada para workspaces de ROS1 dentro do RoboStack — o catkin_make tradicional funciona, mas catkin build lida melhor com o ambiente Conda.
Para compilar um workspace existente:
cd ~/catkin_ws
catkin build
Testando a instalação
Em dois terminais separados, com o ambiente ativado em ambos:
# Terminal 1
micromamba activate ros_env
roscore
# Terminal 2
micromamba activate ros_env
rviz
Se o RViz abrir e o roscore continuar rodando sem erro, a instalação está completa. Não é preciso (e não se deve) fazer source de nenhum setup.bash manualmente — a ativação do ambiente Conda já cuida disso.
Problemas comuns (e como resolver)
“Multiple packages found with the same name” — sintoma de ter instalado conda ou mamba dentro do próprio ros_env, e não só no base. Solução: recrie o ambiente sem essas ferramentas dentro dele.
Erros de CMake não encontrando um pacote durante o build — normalmente falta apontar o CMAKE_PREFIX_PATH para o prefixo do ambiente RoboStack. Confirme que o ambiente está ativado antes de compilar.
RLException: Unable to contact my own server no macOS — configure ROS_MASTER_URI e ROS_HOSTNAME para 127.0.0.1 e confirme que /etc/hosts resolve localhost corretamente. É o erro mais comum reportado por quem migra do Ubuntu nativo pro macOS via RoboStack.
Erro de Python em builds customizados (find_package(PythonInterp) pegando o Python errado) — aponte explicitamente o Python do ambiente:
catkin build --cmake-args -DPython_EXECUTABLE=$CONDA_PREFIX/bin/python
GL/gl.h não encontrado, no Linux — instale os headers e drivers de OpenGL da sua distribuição (libgl-devel ou equivalente) antes de compilar pacotes com renderização 3D.
Quando RoboStack não é a resposta
RoboStack não substitui uma instalação nativa quando o projeto depende de:
- drivers de hardware específicos do kernel (ex: drivers de tempo real, alguns drivers de câmera ou de barramento CAN) que esperam módulos do kernel já carregados pelo sistema operacional — exatamente o caso do NUC embarcado no robô desta pesquisa, que roda Ubuntu nativo por esse motivo;
- integração profunda com o gerenciador de pacotes do sistema, como serviços
systemdque esperam pacotes Debian/RPM já instalados fora do Conda.
A regra prática que uso: RoboStack no notebook, para desenvolver e testar nós isolados; Ubuntu nativo no hardware embarcado, onde o robô de fato roda. As duas abordagens não competem — resolvem problemas diferentes.