Open slowrunner opened 2 years ago
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).
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.
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: