Humble: Errors when trying the Create 3 Coverage Example

[swilloughbypme]

Problem:
Using Humble, "Some subscriptions haven't discovered their publishers yet" error from the create3_coverage node when sending the send_goal action as in the coverage example's read-me.

Setup:

• VirtualBox VM running Ubuntu 22.04 & Humble
• Create 3 running the H.0.0 Humble firmware
• The Humble branch of the create 3 examples built successfully in the create3_examples_ws workspace folder

Sending the following command in a terminal window, the create3_coverage node seems to start correctly:

retupmoc@UbuntuVM:~/create3_examples_ws$ ros2 run create3_coverage create3_coverage
[INFO] [1672690800.512621597] [create3_coverage]: Node created!

However, when I run this line in a new terminal window:
ros2 action send_goal /coverage create3_examples_msgs/action/Coverage "{explore_duration:{sec: 500, nanosec: 0}, max_runtime:{sec: 1000,nanosec: 0}}"

I see these 2 errors in the first window.

[WARN] [1672690841.650113362] [create3_coverage]: Some subscriptions haven't discovered their publishers yet
[WARN] [1672690841.650202055] [create3_coverage]: Rejecting goal request: robot nodes have not been discovered yet

I see where the first error comes from in the node's code (and that error causes the second error), but I'm at a loss as to which of the subscriptions is causing the problem. Node code:

bool Create3CoverageNode::ready_to_start()
{
    if (m_dock_subscription->get_publisher_count() == 0 ||
        m_hazards_subscription->get_publisher_count() == 0 ||
        m_ir_opcode_subscription->get_publisher_count() == 0 ||
        m_odom_subscription->get_publisher_count() == 0 ||
        m_kidnap_subscription->get_publisher_count() == 0)
    {
        RCLCPP_WARN(this->get_logger(), "Some subscriptions haven't discovered their publishers yet");
        return false;
    }
...

Grasping at straws, I tried switching to cyclone dds on both the vm and the Create 3, but no luck. Also tried with the Create 3 docked and undocked.

I'm still very new to ROS2 (and ROS in general) so troubleshooting something like this is still baffling. Any help appreciated!!

Steve

[justinIRBT]

Given that all publications it is waiting for are coming from the same place (the robot) it’s likely not seeing any of them if it is not seeing one of them. To verify communication, can you try
ros2 topic list —no-daemon —spin-time 5
from the same terminal window that you are running the create3_coverage from. You can use this to first verify communication before running. If you aren’t seeing the robot topics, you can try alternate dds configs or VM networking settings until you can see the topic list.

[rkburns]

Having the same problem with Humble. My output:
pi@rb-robot-pi:/projects/create3_examples_ws/install$ ros2 topic list
/battery_state
/cmd_audio
/cmd_lightring
/cmd_vel
/dock <----- created when create3_coverage runs
/dock_status
/hazard_detection
/imu
/interface_buttons
/ir_intensity
/ir_opcode
/kidnap_status
/mobility_monitor/transition_event
/mouse
/odom
/parameter_events
/robot_state/transition_event
/rosout
/slip_status
/static_transform/transition_event
/stop_status
/tf
/tf_static
/wheel_status
/wheel_ticks
/wheel_vels
pi@rb-robot-pi:/projects/create3_examples_ws/install$ ros2 node list
/_internal/composite_hazard
/_internal/kinematics_engine
/_internal/mobility
/_internal/stasis
/create3_coverage <----- created when create3_coverage runs
/mobility_monitor
/motion_control
/robot_state
/static_transform
/system_health
/ui_mgr
pi@rb-robot-pi:~/projects/create3_examples_ws/install$ ros2 action list
/audio_note_sequence
/coverage <----- created when create3_coverage runs
/dock
/drive_arc
/drive_distance
/led_animation
/navigate_to_position
/rotate_angle
/undock
/wall_follow

[justinIRBT]

There was an issue with the humble branch, the dock topic hadn't been updated (it was using the galactic topic name "/dock" instead of the humble name "/dock_status".) I pushed a change to update it. @rkburns Given that you are seeing topics, I believe this should resolve your issue if you pull the change in the humble branch. @retupmoc1 Can you confirm you are seeing topics, then give this update a try.
Thanks

[swilloughbypme]

Hi @justinIRBT!,

Working like a charm now. The little guy is bumping into stuff all over the house.

Many thanks,
Steve

[rkburns]

Hello...now it works, however I don't see recovery from the "bump reflex" (?) ... I see the output "[create3_coverage]: Reflexes are enabled on the robot!" but the robot cannot recover from hitting an obstacle. The sequence:
[INFO] [1672772155.803468433] [create3_coverage]: Accepting goal request
[INFO] [1672772155.804426713] [create3_coverage]: Executing goal
[INFO] [1672772156.297643951] [create3_coverage]: Reflexes are enabled on the robot!
[INFO] [1672772163.798618073] [create3_coverage]: Stop spiraling: time spent 7.500655/30.000000 hazards 1 dock 0
[INFO] [1672772165.865211174] [create3_coverage]: Aborting ROTATE because initial hazard is not getting cleared
[INFO] [1672772165.931811000] [create3_coverage]: Coverage action terminated

[justinIRBT]

@rkburns Can you

ros2 topic echo hazard_detection

Looking at the code, it seems like the robot is reporting that a hazard is active. That topic should show an empty vector of hazards if nothing is active, otherwise it will show a type and a frame of each active hazard which will indicate which hazard is triggered:
https://github.com/iRobotEducation/irobot_create_msgs/blob/main/msg/HazardDetection.msg

[rkburns]

Hello...so I get (alot) of:

header:
stamp:
sec: 1672797801
nanosec: 912585873
frame_id: base_link
detections:

• header:
  stamp:
  sec: 1672797801
  nanosec: 912585873
  frame_id: bump_front_left
  type: 1

...a power cycle seems to have cleared it well enough to do some exploring. I would probably like to work on fine-tuning obstacle clearance. I'll count it as a win for Humble :)