Aborting ROTATE because initial hazard is not getting cleared?

[slowrunner]

Why did the hazard not clear and the explore continue? (This doesn't look like a complex hazard situation.)

[INFO] [1635609142.847961009] [create3_coverage]: Aborting ROTATE because initial hazard is not getting cleared

The full log:

[INFO] [1635608924.038151337] [create3_coverage]: Accepting goal request
[INFO] [1635608924.040617706] [create3_coverage]: Executing goal
[INFO] [1635608924.097034238] [create3_coverage]: Reflexes are enabled on the robot!
[INFO] [1635608924.099398054] [create3_coverage]: Sending undocking goal!
[INFO] [1635608963.909060169] [create3_coverage]: Undocking succeeded!
[INFO] [1635608968.774922245] [create3_coverage]: Reached drive straight max distance: 0.250916
[INFO] [1635608998.841633768] [create3_coverage]: Spiral completed!
[INFO] [1635609001.608250178] [create3_coverage]: Stop driving straight: traveled 0.116123/5.000000: hazards 1 dock 0
[INFO] [1635609048.781359045] [create3_coverage]: Rotation completed: from -0.901778 to 2.134330
[INFO] [1635609058.547966186] [create3_coverage]: Reached drive straight max distance: 0.251280
[INFO] [1635609088.614677887] [create3_coverage]: Spiral completed!
[INFO] [1635609091.614681016] [create3_coverage]: Stop driving straight: traveled 0.138735/5.000000: hazards 1 dock 0
[INFO] [1635609130.881360213] [create3_coverage]: Rotation completed: from -2.568480 to -0.647966
[INFO] [1635609140.781295134] [create3_coverage]: Stop driving straight: traveled 0.173716/0.250000: hazards 1 dock 0
[INFO] [1635609142.847961009] [create3_coverage]: Aborting ROTATE because initial hazard is not getting cleared
[INFO] [1635609142.914624582] [create3_coverage]: Coverage action terminated

[pcouvignou-irobot]

I experienced the same issue on January 13 2022 with a real Create3 robot; it was 100% reproducible out of 2 create3_coverage runs. I was using the latest firmware build linux+create3-dev+daredevil-create3-dev+79 and the latest ROS2 Galactic libraries (sudo apt update).

[carlsondc-ceva]

I saw this behavior with a Create3 robot. I had previously disabled reflexes/safety limits. After restarting the ROS2 app, it worked correctly. It seems to be inconsistent-- sometimes the coverage node enables reflexes successfully, and sometimes the /motion_control parameters get updated but the reflexes don't seem to work.

After starting up, run the following commands to disable reflexes/safety:

ros2 param set /motion_control safety_override "full"
ros2 param set /motion_control reflexes_enabled false

Initial state of /motion_control params in non-working case, from ros2 param dump /motion_control:

/motion_control:
  ros__parameters:
    max_speed: 0.46
    min_speed: 0.03
    qos_overrides:
      /parameter_events:
        publisher:
          depth: 1000
          durability: volatile
          history: keep_last
          reliability: reliable
    reflexes:
      REFLEX_BUMP: true
      REFLEX_CLIFF: true
      REFLEX_DOCK_AVOID: false
      REFLEX_GYRO_CAL: true
      REFLEX_PANIC: true
      REFLEX_PROXIMITY_SLOWDOWN: true
      REFLEX_STUCK: true
      REFLEX_VIRTUAL_WALL: false
      REFLEX_WHEEL_DROP: true
    reflexes_enabled: false
    safety_override: full
    use_sim_time: false
    wheel_accel_limit: 900

coverage node output:

[INFO] [1676307007.510846717] [create3_coverage]: Node created!
[INFO] [1676307021.854939276] [create3_coverage]: Accepting goal request
[INFO] [1676307021.856332759] [create3_coverage]: Executing goal
[WARN] [1676307021.859402891] [create3_coverage]: Some reflexes were disabled, activating all of them
[INFO] [1676307023.195922059] [create3_coverage]: Stop spiraling: time spent 1.177539/30.000000 hazards 1 dock 0
[INFO] [1676307025.240734176] [create3_coverage]: Aborting ROTATE because initial hazard is not getting cleared
[INFO] [1676307025.308057513] [create3_coverage]: Coverage action terminated

After this, /motion_control's reflexes_enabled param is true, and there are no other changes. The robot drove full-speed into the wall and did not back up so it looks like neither reflexes.REFLEX_PROXIMITY_SLOWDOWN nor reflexes.REFLEX_BUMP were honored.

I reset the safety params to what I thought should work:

/motion_control:
  ros__parameters:
    max_speed: 0.306
    min_speed: 0.03
    qos_overrides:
      /parameter_events:
        publisher:
          depth: 1000
          durability: volatile
          history: keep_last
          reliability: reliable
    reflexes:
      REFLEX_BUMP: true
      REFLEX_CLIFF: true
      REFLEX_DOCK_AVOID: false
      REFLEX_GYRO_CAL: true
      REFLEX_PANIC: true
      REFLEX_PROXIMITY_SLOWDOWN: true
      REFLEX_STUCK: true
      REFLEX_VIRTUAL_WALL: false
      REFLEX_WHEEL_DROP: true
    reflexes_enabled: true
    safety_override: backup_only
    use_sim_time: false
    wheel_accel_limit: 900

I get the same behavior, though.

After restarting the ROS2 application (curl -X POST http://192.168.186.2/api/restart-app), I see:

/motion_control:
  ros__parameters:
    max_speed: 0.306
    min_speed: 0.03
    qos_overrides:
      /parameter_events:
        publisher:
          depth: 1000
          durability: volatile
          history: keep_last
          reliability: reliable
    reflexes:
      REFLEX_BUMP: true
      REFLEX_CLIFF: true
      REFLEX_DOCK_AVOID: false
      REFLEX_GYRO_CAL: true
      REFLEX_PANIC: true
      REFLEX_PROXIMITY_SLOWDOWN: true
      REFLEX_STUCK: true
      REFLEX_VIRTUAL_WALL: false
      REFLEX_WHEEL_DROP: true
    reflexes_enabled: true
    safety_override: none
    use_sim_time: false
    wheel_accel_limit: 900

The robot now seems to do reasonable things, and the log output is

[INFO] [1676307541.878904231] [create3_coverage]: Node created!
[INFO] [1676307554.600925293] [create3_coverage]: Accepting goal request
[INFO] [1676307554.602391295] [create3_coverage]: Executing goal
[INFO] [1676307555.266694434] [create3_coverage]: Reflexes are enabled on the robot!
...

Strangely, after doing this I tried to disable safety and then restore the original parameters using the ros2 param load command-- and this time the coverage node appeared to successfully re-enable reflexes, as it was able to work correctly.

The other piece of information to put out there is I am using ros2 run teleop_twist_keyboard teleop_twist_keyboard to control the robot, which uses drive speeds that are above the typical 0.3 m/s limit. Don't know if that might factor into this behavior.