ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Using Ansible for more than installation?

Hi all,

I’m trying to manage a small fleet of robots with a half-baked swarm algorithm.
I’ve looked around and there are plenty of ansible roles that install ROS, but I can’t find any that expose run or launch.

Does anyone have an ansible playbook that can do things like trigger a launchfile? or is this a terrible idea?
I do miss the ROS1 remote launch feature.

Cheers!

From my limited experience with Ansible (and Balena) I’d say that using it for launching nodes is probably stretching what the platform is designed for.
For remote launch, I would recommend a tool like Freedom Robotics, where you can use the UI or API to launch nodes on robots. Here’s some examples through the API.
Disclaimer: I work for Freedom Robotics :slight_smile:

1 Like

I did consider trying a proper fleet management utility, but it didn’t seem like a good fit:
My target application is unlikely to have access to an internet connection or even a central base-station,
My robots don’t have wheels or batteries or anything that needs monitoring or logging,
My prototype cycle regularly makes fleet-at-once changes, which seems like it would need enterprise features on Freedom Robotics?

Using ansible to synchronise the robots with a local git server works beautifully, and using ansible to launch works fine for short benchtop tests (launch is beyond the intended scope of ansible, but it doesn’t leave a mess when it breaks)

For extended operation and restart at reboot, I’ve been using my lauchfiles wrapped in a systemd service. That has been absolutely bulletproof and very straightforward, and I highly recommend it.

I’ve put together an ansible template for automating ros-launch-as-systemd-service setup, that’ll appear on github soon.

Yep, one way to do this would be to have Ansible configure a systemd job that runs a launch file - I’ve used that strategy quite a bit in the past (an example can be found in my UBR-1 setup).

2 Likes

This is great!

I like your use of systemd dependencies to handle roscore, and how you’ve mapped the node’s stdout somewhere sane.

How did you get the rosdep line to work?
On my machines, it throws warnings as root, and stalls on the password prompt as user.
Do you have a no-password-sudo user on your base image?

There are two parts to this: first, I have “become: yes” on the commands that need sudo privilege. Then I run the playbook with the following command so that it will ask for my sudo password on start:

ansible-playbook ubr_ros1.yml -i inventory --ask-become-pass

There are also ways to create a “vault” for ansible, which is probably a better approach if you have other credentials to access or different sudo passwords for different robots.

This is something I’ve done for a long time - it is especially nice because you can restart the robot drivers/etc without needing to restart your remote RVIZ session since it still uses the same roscore. By making the robot.service start after roscore.service you can still restart everything by simply restarting the roscore service, because it will force the robot service to restart as well (in more complex systems, I’ve seen even more be chained - so like roscore, robot drivers, navigation, high level application might all be separate systemd jobs allowing the higher level stuff to be restarted easily - since usually that is the least reliable code).

1 Like

I’ve put something together, It’s only barely usable so far

I hope it helps someone,
please open some issues with suggestions and things I’ve missed.