[DBG] [SE]: !velocity_stopped debugging message -> means cmd_vel topic is unresponsive.

[royito55]

I've been trying to figure out why the create 3 randomly stops responding to the /cmd_vel if the base is left on for long enough.

I know it's not an issue with the wheel motors because I can still call the /dock, /undock, and /drive_distance actions and there is no issue with them.

I think I found something: sometimes, the create 3 outputs this message:

user.notice create-platform: [DBG] [SE]: !velocity_stopped - cmd_vel:-300,-300 meas_vel:-168,-156

When this (debugging) message appears, the /cmd_vel is unresponsive, and the only way to reset it is manually turning the base off and on again.

When this message does not appear, then the /cmd_vel topic works fine.

What is the problem here? Is this a reflex or something I can turn off? Can I deactivate it? I want the base to be responsive to /cmd_vel 24/7

[alsora]

Hi @royito55 ,

The log that you posted indicates that the robot is NOT stopped, indeed you can see that there's a velocity command (-300 in this case) and the encoders are measuring the wheels as moving (-168).
This log is usually produced when the robot starts moving after being stopped.

The robot is, in theory, always responsive to /cmd_vel.
I see however that you are driving backward (negative wheel velocities), maybe you are hitting the backup limit? The robot has cliff sensors only on the front, so it can't safely backup indefinitely without risk of falling down into a hole/gap.

If you know that there are no holes/stairs/gaps where the robot could fall down, you should disable the backup limit.
You can find some docs here: https://iroboteducation.github.io/create3_docs/api/safety/
You should set ros2 param set /motion_control safety_override full
If you want your change to persist, you should use the YAML configuration file (which can be modified via the webserver: https://iroboteducation.github.io/create3_docs/webserver/application/)

If this doesn't fix the problem (or if you already did that), it would be helpful to get a full log.

[royito55]

Thank you for your explanation! I kept looking and it seems maybe a sensor was misbehaving and was causing a reflex to activate and prevent movement?

I already had the full override, but noticed that enable_reflexes was still on.

Setting all the reflex params of the /motion_control node to False seems to have solved the issue.