Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix missing ROS_MASTER_URI on master deployment #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

marcoshuck
Copy link

@marcoshuck marcoshuck commented Jan 19, 2021

Change

This PR solves an error while deploying the ROS application on Kubernetes

The ROS_MASTER_URI was not configured on the master node, and therefore a new env var was added to the master deployment.

Issue

While launching the ROS master deployment on Kubernetes, the following error was returned:

/opt/ros/melodic/etc/catkin/profile.d/10.roslaunch.sh: line 3: ROS_MASTER_URI: unbound variable

@marcoshuck marcoshuck changed the title Fix missing ROS_MASTER_URI on master Fix missing ROS_MASTER_URI on master deployment Jan 19, 2021
@marcoshuck
Copy link
Author

Care to give this a review? @diegoferigo thanks! 😃

@diegoferigo
Copy link
Owner

@marcoshuck The ROS_MASTER_URI variable is exported automatically by the entrypoint.sh:

source "/opt/ros/$ROS_DISTRO/setup.bash"

I'm not sure exporting this variable is the cleanest way to handle it. I suspect you encountered this problem after entering the container with docker exec [...]. In this case, the entrypoint is not executed and the script is not sourced. Maybe in this case the best solution is sourcing the script in the interpreter configuration (e.g. /etc/bash.bashrc).

My point is that if you don't have that variable defined, your setup is not sourcing the ROS initialization script. Exporting manually the variable will only provide a partially configured setup that could miss something else perhaps in other cases. The best way is always source the script.

@marcoshuck
Copy link
Author

marcoshuck commented Jan 26, 2021

Hey @diegoferigo, thanks for your response.

I agree it's not the cleanest solution, but I should mention that I got this problem while initializing the set of pods on my minikube cluster.

That being said, images for those pods were generated as described in the docs using docker-compose build and added to the cluster repository with minikube cache add.

Taking everything into account, I imagine the problem, even if it's related to what you've described, is happening somewhere else.

@marcoshuck
Copy link
Author

This problem only happens on the ROS master, and that's not the case for the workers (talker and listener deployments)

@marcoshuck
Copy link
Author

Does it make sense to reproduce this problem to see if I'm the only one who's having it?

@diegoferigo
Copy link
Owner

At the moment I don't have access to a machine in which I can install and configure minikube. Can you make sure that the entrypoint is called in the master deployment? If you browse the logs, you should read the echoed lines:

==> Executing master image entrypoint ...
-> Setting up ROS
==> Container ready

Another attempt could be to inspect the environment that roscore finds before running. I think you can get it printed to the logs by running env && roscore (ported to kubernetes syntax) in the args key:

- name: rosclustermaster
image: roscluster/master:v0
args:
- roscore
ports:
- containerPort: 11311
name: roscoreport

@marcoshuck
Copy link
Author

Sure, thanks @diegoferigo, will get back as soon as I have some logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants