y2d2
commented
1 year ago I gave a wrong error message in the previous log it gave the following error message:
Could not transform base_link to odom: Could not find a connection between 'odom' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees..
anyways. Since I did 'hack away` a lot the recent days, I decided to start fresh with 1 robot today:
- Factory reset of the create3 platform and reinstalled the H2.2 update
- Flashed the rPi with the image
turtlebot4_standard_humble_1.0.0.zipI downloaded on the 10th of July and resized the sd card. - updated the rPi
sudo apt-get update && sudo apt-get upgrade -y - Somebackages were kept back so I decided to also perform a `sudo apt-get full-upgrade -y' (Not sure if this was needed, I will test tomorrow with the other robot what the difference is and which packages were kept back and report back here. I did see a lot of depth-ai stuff, which could explain the OAKD issue covered in this message.)
- Put it back in the robot and followed the instruction in the user manual to setup the robot in simple discovery using the fastDDS middleware.
- Tried out the 'ros2 topic list' on my controlling PC and this looked good.
- However when I tried to run the localisation node
ros2 launch turtlebot4_navigation localization.launch.py map=:./map.yamlwith ./map.yaml a custom build map I directly got the messageCould not transform base_link to odom: Could not find a connection between 'odom' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.. - This seemed new. The odom base_link transform in the past week has always been a bit shaky, but normally it comes through after some time, might drop some frames in the single agent setup.
- Stopped everything and rebooted the TB4
- Waited a bit used 'ros2 run tf2_tools view_frames` and got indeed a TF tree without odom frame:
- The /odom topic however publishing as normal
ros2 topic echo /odomas normal stayed blank for some time but then comes through and published the odom. However the TF tree remained the same. - It tried to broadcast the TF between base_link and odom my self using the
/odomtopic.
#!/usr/bin/env python3
import rclpy
from rclpy.node import Node
from tf2_ros import TransformBroadcaster
from geometry_msgs.msg import TransformStamped
from nav_msgs.msg import Odometry
class FramePublisher(Node):
def __init__(self):
super().__init__('tf_odom_base_link')
self.subscription = self.create_subscription(Odometry, "odom", self.update_o_bl_tf, 10)
def update_o_bl_tf(self, msg):
t = TransformStamped()
t.header.stamp = self.get_clock().now().to_msg()
t.header.frame_id = 'odom'
t.child_frame_id = 'base_link'
t.transform.translation.x = msg.pose.pose.position.x
t.transform.translation.y = msg.pose.pose.position.y
t.transform.translation.z = msg.pose.pose.position.z
t.transform.rotation.x = msg.pose.pose.orientation.x
t.transform.rotation.y = msg.pose.pose.orientation.y
t.transform.rotation.z = msg.pose.pose.orientation.z
t.transform.rotation.w = msg.pose.pose.orientation.w
self.tf_broadcaster.sendTransform(t)
def main(args=None):
rclpy.init(args=args)
node = FramePublisher()
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()- This however gave the following message:
[WARN] [1690903785.216893707] [tf_map_odom]: New publisher discovered on topic 'odom', offering incompatible QoS. No messages will be received from it. Last incompatible policy: RELIABILITY - It seemed to come from bad QoS parameters for the
/odomtopic (Maybe this is the reason why in the past theodom base_link tfwas not very stable and now maybe through some update is not working at all? (However, this seems like a create3 issue I suppose?) - Anyway update the code with:
#!/usr/bin/env python3 import rclpy from rclpy.node import Node
from tf2_ros import TransformBroadcaster from geometry_msgs.msg import TransformStamped from nav_msgs.msg import Odometry
from rclpy.qos import QoSProfile, QoSReliabilityPolicy, QoSHistoryPolicy
class FramePublisher(Node): def init(self): super().init('tf_odom_base_link') qos_profile = QoSProfile( reliability=QoSReliabilityPolicy.BEST_EFFORT, history=QoSHistoryPolicy.KEEP_LAST, depth=1 ) self.subscription = self.create_subscription(Odometry, "odom", self.update_o_bl_tf, qos_profile=qos_profile)
def update_o_bl_tf(self, msg):
t = TransformStamped()
t.header.stamp = self.get_clock().now().to_msg()
t.header.frame_id = 'odom'
t.child_frame_id = 'base_link'
t.transform.translation.x = msg.pose.pose.position.x
t.transform.translation.y = msg.pose.pose.position.y
t.transform.translation.z = msg.pose.pose.position.z
t.transform.rotation.x = msg.pose.pose.orientation.x
t.transform.rotation.y = msg.pose.pose.orientation.y
t.transform.rotation.z = msg.pose.pose.orientation.z
t.transform.rotation.w = msg.pose.pose.orientation.w
self.tf_broadcaster.sendTransform(t)def main(args=None): rclpy.init(args=args) node = FramePublisher() rclpy.spin(node) node.destroy_node() rclpy.shutdown()
- which resolved the issue and the tf was broadcasted.
- Now I tried to change the namespace (I did not try the new TF broadcaster here since now I ran into another issue: the oakd-pro stops after few seconds when the namespace is used (not the case when no namespace is used), I am not sure if this was also the case last week. So maybe has to do with the updates as well.
- I made a small shell script to monitor the topic list on my controlling PC: count=1 while true; do
echo "check $count for ROS_DOMAIN_ID=$ROS_DOMAIN_ID and RMW=$RMW_IMPLEMENTATION"
count=$(expr $count + 1)
ros2 topic list;
sleep 2;
echo "-------------------------------------------------------------------------"done
Running this while the TB rebooted showed the following results:
- At check 103 we see the topics from the create3 (I think) emerge
- At check 112 I think we start to see the rPI topics emerge
- at check 115 the oakd topics are emerging.
- At check 124 the oakd topics have ceased to exist.
Here are some of the checks: check 103 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/dock_status /tb1/hazard_detection /tb1/imu /tb1/interface_buttons /tb1/ir_intensity /tb1/ir_opcode /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/odom /tb1/robot_state/transition_event /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
check 104 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/dock_status /tb1/hazard_detection /tb1/imu /tb1/interface_buttons /tb1/ir_intensity /tb1/ir_opcode /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/odom /tb1/robot_state/transition_event /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
...
check 112 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/diagnostics /tb1/dock_status /tb1/function_calls /tb1/hazard_detection /tb1/hmi/buttons /tb1/hmi/display /tb1/hmi/display/message /tb1/hmi/led /tb1/imu /tb1/interface_buttons /tb1/ip /tb1/ir_intensity /tb1/ir_opcode /tb1/joint_states /tb1/joy /tb1/joy/set_feedback /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/odom /tb1/robot_description /tb1/robot_state/transition_event /tb1/scan /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
...
check 115 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/diagnostics /tb1/dock_status /tb1/function_calls /tb1/hazard_detection /tb1/hmi/buttons /tb1/hmi/display /tb1/hmi/display/message /tb1/hmi/led /tb1/imu /tb1/interface_buttons /tb1/ip /tb1/ir_intensity /tb1/ir_opcode /tb1/joint_states /tb1/joy /tb1/joy/set_feedback /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/oakd/rgb/preview/camera_info /tb1/oakd/rgb/preview/image_raw /tb1/oakd/rgb/preview/image_raw/compressed /tb1/oakd/rgb/preview/image_raw/compressedDepth /tb1/oakd/rgb/preview/image_raw/theora /tb1/odom /tb1/robot_description /tb1/robot_state/transition_event /tb1/scan /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
...
check 123 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/diagnostics /tb1/dock_status /tb1/function_calls /tb1/hazard_detection /tb1/hmi/buttons /tb1/hmi/display /tb1/hmi/display/message /tb1/hmi/led /tb1/imu /tb1/interface_buttons /tb1/ip /tb1/ir_intensity /tb1/ir_opcode /tb1/joint_states /tb1/joy /tb1/joy/set_feedback /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/oakd/rgb/preview/camera_info /tb1/oakd/rgb/preview/image_raw /tb1/oakd/rgb/preview/image_raw/compressed /tb1/oakd/rgb/preview/image_raw/compressedDepth /tb1/oakd/rgb/preview/image_raw/theora /tb1/odom /tb1/robot_description /tb1/robot_state/transition_event /tb1/scan /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
check 124 for ROS_DOMAIN_ID=1 and RMW=rmw_fastrtps_cpp /parameter_events /rosout /tb1/battery_state /tb1/cliff_intensity /tb1/cmd_audio /tb1/cmd_lightring /tb1/cmd_vel /tb1/diagnostics /tb1/dock_status /tb1/function_calls /tb1/hazard_detection /tb1/hmi/buttons /tb1/hmi/display /tb1/hmi/display/message /tb1/hmi/led /tb1/imu /tb1/interface_buttons /tb1/ip /tb1/ir_intensity /tb1/ir_opcode /tb1/joint_states /tb1/joy /tb1/joy/set_feedback /tb1/kidnap_status /tb1/mobility_monitor/transition_event /tb1/mouse /tb1/odom /tb1/robot_description /tb1/robot_state/transition_event /tb1/scan /tb1/slip_status /tb1/static_transform/transition_event /tb1/stop_status /tb1/tf /tb1/tf_static /tb1/wheel_status /tb1/wheel_ticks /tb1/wheel_vels
Tomorrow I will take note of the versions of the distribution and do the same without the `sudo apt-get full-upgrade -y' with the other TB4 and report on the results.
Please provide the following information:
sudo dpkg -s ros-$ROS_VERSION-turtlebot4-PACKAGE_WITH_ISSUE, but it should besudo dpkg -s ros-$ROS_DISTRO-turtlebot4-PACKAGE_WITH_ISSUE? at least so it is on my system.)Create3 firmware: H2.2
Expected behaviour When I connect 2 TBs using https://github.com/turtlebot/turtlebot4/issues/132 and run the localization and navigation stack for both of them I expect the TBs to work.
Actual behaviour As long as the localization and navigation of neither is running everything seems fine. The moment I start one of them most of the time it works, however, I noticed that the /odom topic and others of the other TB start to stop providing updates. The moment I start this localization and navigation of the second TB it is unreactive and is waiting for the /odom to /base_link transformation:
[controller_server-1] [INFO] [1690835508.615078609] [tb2.local_costmap.local_costmap]: Timed out waiting for transform from base_link to odom to become available, tf error: Invalid frame ID "base_link" passed to canTransform argument source_frame - frame does not existSometimes the other robots' navigation will also stop with the same issue or pause for long times with this message before continuing.The create3 log gives the following info:
[tb1.system_health]: Discovered 78 nodes! Considering using DOMAIN_ID to reduce the burden on the application Jul 31 13:49:49 iRobot-623CE57328134F83A5B4314DF6EBB89D user.notice ntpd: ntpd: reply from 192.168.186.3: delay 0.002503 is too high, ignoring Jul 31 13:50:32 iRobot-623CE57328134F83A5B4314DF6EBB89D user.notice create-platform: [INFO] [1690811432.968177493] [tb1.system_health]: CPU usage: max 99 [%] mean 98 [%] RAM usage: 39/59which makes me believe that the create3 platform cannot handle that many nodes. See https://github.com/turtlebot/turtlebot4/issues/234 for more details of what I tried to get it to work.
To Reproduce Provide the steps to reproduce:
ros2 launch turtlebot4_navigation localization.launch.py namespace:=tb1 map=:./map.yamlwith ./map.yaml a custom build map, but can be any map, and the navigation stackros2 launch turtlebot4_navigation nav2.launch.py namespace:=tb1Other notes I made a more detailed description (https://github.com/turtlebot/turtlebot4/issues/234) of the things I tried to make it work but did not make it a bug report and cannot figure out how to change it.