| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Hello you all,
I’ve installed ros-melodic-rosbag from the AUR, but I don’t see a rosbag command available.
Did I miss something? Do I need to explicitly update my PATH to point to /opt/ros/melodic/bin? What else?
EDIT: Okay, I updated my path, but something is missing:
❯ rosbag
Traceback (most recent call last):
File "/opt/ros/melodic/bin//rosbag", line 34, in <module>
import rosbag
ModuleNotFoundError: No module named 'rosbag'
@trusktr Have you followed the installation instructions here: https://wiki.ros.org/melodic/Installation/ArchLinux?
I am sure you have been told this many times, but always read the manual lol.
@acxz hanks! I realized I was missing the source /opt/ros/melodic/setup.{bash,sh,zsh} part. I had assumed it would install things in the usual places like most other packages.
Yeah I agree, I also find that something annoying about ROS (just to keep things clear you have to do that sourcing for Ubuntu and Debian ROS as well). It’s mostly because ROS does not obey the Linux FHS (on mobile but you can Wikipedia File System Hierarchy) sucks on why this design choice was made in the first place. Debian has actually started to convert ROS packages to obey FHS but sadly I think only a small team is working on it and until ROS makes a concerted effort the issue will still remain. I don’t know if ROS2 fixes this issue tho.
not sure but i heard it does? will ask my team working on our common project.
In point of fact, I think it’s fairer to say that the official distribution of ROS does not default to installing in the system wide paths but instead uses the FHS /opt path for Add-on application software packages. ros is even a registered provider name with the delightful to say aloud, LANANA.
why this design choice was made in the first place.
Installing distributions to /opt/ros/$ROS_DISTRO and using scripts or other methods to manipulate system paths and variables for selecting between them enables multiple distributions to be installed on the same host without colliding. It’s the choice made for the official distribution but other distributors can and have installed a specific ROS distribution to the system-wide paths.
Ah thank you for explaining. That does make sense now that you point these things out to me. I just wish there was a way of using ROS without worrying about sourcing, but the only way to go about that with multiple distributions is for each command name to be specific to the distribution which sounds even worse. Thanks once again, @nuclearsandwich!
We could add the script in /etc/profile.d/, but I don’t believe this is a good idea. At least we can discuss.
Any idea where this requirement came from? Or what the consequences might be if it were relaxed? Installing ROS to normal Linux FHS and avoiding all the sourcing would make it easier to use, and would probably make the build tools a lot simpler too.
As a user, I like the ability to install/use multiple ROS versions on a single OS.
It’s also something used by a variety of robot hw mfgs, which install into their own prefix.
That would seem to be what @nuclearsandwich refers to when he writes that not installing into system locations directly …
Doesn’t seem too different from how virtualenv and Conda work to me.
Edit: tbh I don’t quite get why people immediately jump to conclusions:
“sucks”, really?
Quite a bit of work has gone into trying to avoid messing with users’ system, trying not to “take over someone’s main(..)”, actually working towards FHS compliance (REP 122, REP 123 and REP 124 and the myriad of discussions about it on ros-users) and without even referring to that history you conclude it sucks and everything is non-FHS compliant.
I apologize for my language, I was ignorant and I didn’t do my reading/research. I know now better. Thank you for pointing me to these resources. @gavanderhoorn
i just found sourcing to be particularly annoying for me since I only care about one ROS distribution at a time, but other users need that functionality. Also I don’t particularly like virtualenvs and condas either (although I do understand the use of them, similar to how I understand the use of ROS distributions). Would like everyone to be on the latest releases of software at all times, a big reason why I use Arch. Again I would like to apologize for my language without understanding the reasoning behind the design choices.
I have no issues with the current setup and I also prefer /opt install. For running ROS on startup I recommend making a systemd service, this is supported on most distros including ArchLinux and is easy to do. I have posted my setup to Github Gist as a guide:
https://gist.github.com/guru-florida/024f72385aa13cd2beb104ebcfdbc926
I am running on an RPi which doesnt have a shutdown button! 
So I added a little GPIO circuitry and my systemd service controls an RGB LED for status and a button for production/devel mode and long-hold for shutdown. At the moment it simply starts/kills processes, but I would like to switch to Node Lifecycle instead which is easily possible. No limits really on how to control ROS2 with some systemd/python ingenuity.
Colin
@gavanderhoorn I would like to point this out: https://wiki.ros.org/UpstreamPackages
I think this is great work by Jochen Sprickerhof and Leopold Avellaneda and would love to see the work they have done into mainstream ROS. Each distribution can just correspond to a major version number change for all the packages. I think the a good goal for ROS to have would be to try to get their work upstream to Debian so a myraid of other users/distributions can use it.
No problem. I’ve done a lot of “jumping to conclusions” myself.
I’m fully aware of the existence of those packages. And the problems they cause when they clash with the regular ROS releases (ROS Answers is full of reports about this).
That’s not to say there is no value in having those, but with the current approach, it looks like it’s an either/or situation.
So within 2 posts you’ve gone from:
to wanting to upstream ROS into Debian, which would result in almost the complete opposite of what you wrote earlier 
(try reading up on how difficult it was to get a “simple” patch to urdfdom into the Debian released version of that library).
But this is all off-topic for this thread. So I’ll shut up.
If your systems don’t need to support multiple rosdistros, you can source the environment setup scripts in your shell’s startup routines, e.g. in .bashrc / .bash_profile or ~/.config/fish/config.fish. That works on a per-user basis and depending on your system bringup methods you could either add sourcing the environment to default shell profiles in /etc/skel or find some other way to trigger them globally.
I am having a similar issue. I’m following the installation instructions and I get the following error:
$ rosdep init
Traceback (most recent call last):
File "/usr/bin/rosdep", line 3, in <module>
from rosdep2.main import rosdep_main
File "/usr/lib/python3.8/site-packages/rosdep2/__init__.py", line 40, in <module>
from .installers import InstallerContext, Installer, \
File "/usr/lib/python3.8/site-packages/rosdep2/installers.py", line 36, in <module>
from rospkg.os_detect import OsDetect
File "/usr/lib/python3.8/site-packages/rospkg/os_detect.py", line 42, in <module>
import distro
ModuleNotFoundError: No module named 'distro'
I did source /opt/melodic/setup.bash. A similar error occurs when I run roscore:
$ roscore
Traceback (most recent call last):
File "/opt/ros/melodic/bin/roscore", line 72, in <module>
import roslaunch
File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/__init__.py", line 62, in <module>
from .scriptapi import ROSLaunch
File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/scriptapi.py", line 42, in <module>
import roslaunch.parent
File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/parent.py", line 54, in <module>
import roslaunch.server
File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/server.py", line 79, in <module>
from rosgraph_msgs.msg import Log
File "/opt/ros/melodic/lib/python3.8/site-packages/rosgraph_msgs/msg/__init__.py", line 2, in <module>
from ._Log import *
File "/opt/ros/melodic/lib/python3.8/site-packages/rosgraph_msgs/msg/_Log.py", line 8, in <module>
import std_msgs.msg
ModuleNotFoundError: No module named 'std_msgs'
I am guessing this error is somehow related to python, it seems to me that it is trying to use python3 deps. When I install ROS from the AUR packages does it install ROS for python2? Maybe it does not install the dependencies required for python3? Is it possible to force it to use python2?
@Rezenders The place to post these questions is at the respective package’s github page at https://github.com/ros-melodic-arch
Ok. Sorry about posting it here.
Hi,
I’ve heard there is a “official” ROS-ArchLinux Community.
I like to be part of, what have I to do?
I’m package maintainer of some ros-melodic packages (https://aur.archlinux.org/packages/?K=majorx234&SeB=m)
and work on improvement of automatically PKGBUILD Creation
(https://github.com/majorx234/ros-build-tools-py3
Hey @majorx234 glad to see you being active!
There is a small number of us, so its nice if we stick together haha.
In terms of the ROS ArchLinux Community we have 3 main points of contact.
The first is this discourse thread, which is a p high level thread of just ROS on Arch Linux in general.
The second one is of course where we host the packages, the AUR.
However, since discussion and development is a bit hard to do via the AUR comments, we have moved over to the following Github organization: https://github.com/ros-melodic-arch
The way our current pipeline is works is as follows:
(bionade24) in charge of syncing changes from the github repo to the AUR. bionade24 also maintains oscloud(https://wiki.archlinux.org/index.php/Unofficial_user_repositories#oscloud) which has the binary packages for ros-melodic-*
(jwhendy, acxz) along with bionade24 we help maintain the github organization and are in charge of reviewing community submitted PRs
Some of us are also working on getting the ros-noetic-* packages set up here: https://github.com/ros-noetic-arch
If you could transfer the ownership of your existing ros-melodic-* packages to bionade24 and create a package request issue with your packages at https://github.com/ros-melodic-arch/ros-melodic-desktop-full we can create the associated repos and have them part of the ros-melodic=* stack that stays in sync.
As for utilities check out: https://github.com/bionade24/aur-ci