I am migrating to ROS2 for the Rosbot PRO, and have come unstuck (partially) with the Astra RGDB. The current ros_astra_camera package under the 20.04 install works (and runs) as described on this other topic. The image can be obtained, but only by selecting a topic along the lines of ‘camera_optical_frame’
The issue is suitable launch files for the astra, similar to the ROS1 astra_launch package. It appears an initial problem is there are no transform frames connecting the astra optical frames to the URDF. However, there are various other arg/params set in these packages along with the nodelet manager?
Are these any available launch files for the RGBD as this stage? Or can I be pointed in a direction to link the camera into the rest of the hardware stack in ROS2?
PS: I am not worried (at this stage) about the registered images, but for now the RGB (although the former would be nice)
Thank you for any assistance.
Currently, there are no officially supported packages for Astra RGBD in ros2 and I wasn’t able to find any example launch file for RGBD.
To link camera frame with the robot you will need transforms between base_link and camera frames. You can do that for example by creating like base_link - camera_link transform and then specifying transforms between camera_link and rgb, depth optical frames - something similar to this astra_frames transforms.
Alternatively, you can make direct transforms between base_link and camera optical frames.
Thank for the information.
I have been looking at creating suitable launch files myself, basin on the ROSv1 astra_launch package, similar to as linked.
On this topic, do the Husarion team have any experience in connecting with the ROS2 implementation of the image pipeline or using the astra camera in ROS2 in general? I have encountered another issue with QoS policies, both the default RViz settings, and now with image pipeline,
I ask because, for teaching starting at the end of next month, I need to determine if I should move to ROS2 (which is the now support ROS version) or use the older noetic ROS1.
Currently, when working with Astra and ros2 we are running camera in ros1 and using ros1 bridge to get topics in ros2. I’ll have a deeper look at how to run Astra in ros2 later this week and try to give you some more information. Regarding QoS policies it’s very likely you have to set reliability to best effort, more info here: Qos policies
Thanks for continuing to follow-up. I have been investigating as well, which I’ll describe here that might help you and/or my understanding. On the QoS side, to the best that I can determine, the Husarion version of the ros_astra_camera in the publisher topics sets the qos to be
rmw_qos_profile_sensor_data. The impact is the QoS settings for image topic becomes
It seems to be, that by default, most image processing assume the reliability of the topic to be
RMW_QOS_POLICY_RELIABILITY_RELIABLE which causes a conflict according to the ROS2 docs. From what I can determine:
- I can’t determine how to interact/change/modify the receiving package QoS, and it might not be possible?
- Instead, I can successfully modify the ros_astra_camera code to use a different QOS, and this “solves” the issue, though I’m unsure of the flow-on impacts.
The use of ROS1 bridge is noted, thought I guess this would mean it would just be better to stick with ROS1 until additional ros packages have ROS2 ports.
On a side note, is Husarion’s interested in any pull-requests for the ros_astra_camera package? I had observed, for instance, that the parameters (such as the TF output frame) can’t be set, and a small code fix permits it.
Sorry for late response. ROS 2 does not officially support a way to configure QoS settings at runtime. There is way to do this at startup but it is up to the node developer to enable this, more info here: configurability of QoS.
If there is no way to configure Qos in image processing package then only solution at this stage is to modify code in ros_stara_camera or desired image processing package.
About pull-requests for the ros_astra_camera if you see quick fixes feel free to make one. We of course will have to verify it before merging.
Thanks for following up. It seemed to me (at this time) the image_processing pipeline QoS could not be modified, however I will reinvestigate it.