The CPU usage of Create 3 is high

[atinfinity]

How are you connecting to your Create 3?

USB Ethernet (ROS 2)

Computer(s) Model(s) and Operating System(s)

No response

Which version of ROS 2 is installed on your computer?

Humble

Which firmware version is installed on your robot?

H.2.3

Which RMW is your robot running?

FastRTPS

Does your robot have an assigned namespace? If so, please share.

No response

Is the robot connected to a network? If so, what is the network type?

No response

Are there multiple Create 3 robots connected to your network?

None

Is multicast enabled?

None

What is the Adapter Board's USB/BLE Toggle currently switched to?

None

Describe your question.

I encountered this problem(turtlebot/turtlebot4#152).
And, I found the following description in this ticket .

The issue is being tracked here.

#381 is reported in Create 3. I checked that CPU usage of Create 3 is very high.
But, this ticket has no updates. Is this a problem of Create 3's firmware?
I think iRobot should clarify this issue.

[slowrunner]

@atinfinity Disclaimer: I'm not connected with iRobot, just a Create3 owner building a bot.

I confirmed that ros2 topic echo /tf indeed crashed the Create3 application after it started publishing the "missed message" notices.

Next, I wrote a simple listener that subscribed to the /tf topic, and printed one out of the 20 messages published each second. Running this also drove the CPU to 99% but I stopped it before the Create3 crashed.

TFMessage:
[geometry_msgs.msg.TransformStamped(header=std_msgs.msg.Header(stamp=builtin_interfaces.msg.Time(sec=1705124123, nanosec=898860959), 
frame_id='odom'), child_frame_id='base_link', transform=geometry_msgs.msg.Transform(
    translation=geometry_msgs.msg.Vector3(x=-6.172332689402538e-08, y=7.333262885822478e-08, z=-1.1724579085381492e-09), 
    rotation=geometry_msgs.msg.Quaternion(x=-0.005351303145289421, y=-0.0030440334230661392, z=-1.6528241758351214e-05, w=0.9999810457229614))), 

geometry_msgs.msg.TransformStamped(header=std_msgs.msg.Header(stamp=builtin_interfaces.msg.Time(sec=1705124123, nanosec=898860959), 
frame_id='odom'), child_frame_id='base_footprint', transform=geometry_msgs.msg.Transform(
    translation=geometry_msgs.msg.Vector3(x=0.00043117975500805983, y=1.3267657438476022e-05, z=0.0), 
    rotation=geometry_msgs.msg.Quaternion(x=0.0, y=0.0, z=-2.3838843787871156e-07, w=1.0)))]

BUT, I have to ask "Why would any application need to maintain the subscription after receiving the first topic?"
Doesn't this message contain two totally static transformations: odom->base_link, and odom->base_footprint,
so won't every message be exactly the same as the prior?

Can you help me understand the /tf use case that can kill my bot dead in its tracks?

[brianabouchard]

Interesting discovery! I suspect this is why the ROS 2 docs provide instructions on listening to transforms using either the dedicated tf2_echo command or writing a tf2 listener that leverages the TransformListener object from the tf2_ros package. In case anyone is interested in the source code, I was able to dig it up here: https://github.com/ros2/geometry2/blob/rolling/tf2_ros/src/transform_listener.cpp

[slowrunner]

Running the tf2_echo is indeed not deadly:

$ ros2 run tf2_ros tf2_echo base_link odom
[INFO] [1705278935.371105460] [tf2_echo]: Waiting for transform base_link ->  odom: Invalid frame ID "base_link" passed to canTransform argument target_frame - frame does not exist
[INFO] [1705278937.334302505] [tf2_echo]: Waiting for transform base_link ->  odom: Invalid frame ID "base_link" passed to canTransform argument target_frame - frame does not exist
[INFO] [1705278938.334473811] [tf2_echo]: Waiting for transform base_link ->  odom: Invalid frame ID "base_link" passed to canTransform argument target_frame - frame does not exist
[INFO] [1705278940.334621939] [tf2_echo]: Waiting for transform base_link ->  odom: Invalid frame ID "base_link" passed to canTransform argument target_frame - frame does not exist
At time 1705278942.275923378
- Translation: [-0.292, -0.011, 0.008]
- Rotation: in Quaternion [0.003, -0.005, 1.000, -0.029]
- Rotation: in RPY (radian) [-0.011, -0.006, -3.083]
- Rotation: in RPY (degree) [-0.625, -0.337, -176.633]
- Matrix:
 -0.998  0.059  0.007 -0.292
 -0.059 -0.998 -0.011 -0.011
  0.006 -0.011  1.000  0.008
  0.000  0.000  0.000  1.000

...


ABOUT:

>>>>>>> system date
Mon Jan 15 00:37:49 UTC 2024

>>>>>>> system uptime
 00:37:49 up 5 days,  6:10,  load average: 2.46, 2.25, 2.08

>>>>>>> system memory
              total        used        free      shared  buff/cache   available
Mem:          59080       40684        5812         356       12584       15956
Swap:             0           0           0

LOG:

Jan 15 00:34:17 Create3-WaLi user.notice create-platform: [INFO] [1705278857.368310048] [system_health]: CPU usage: max 73 [%] mean 58 [%] RAM usage: 40/59 [MB]
Jan 15 00:35:17 Create3-WaLi user.notice create-platform: [INFO] [1705278917.366547317] [system_health]: CPU usage: max 73 [%] mean 61 [%] RAM usage: 40/59 [MB]
Jan 15 00:36:17 Create3-WaLi user.notice create-platform: [INFO] [1705278977.364943086] [system_health]: CPU usage: max 92 [%] mean 68 [%] RAM usage: 40/59 [MB]
Jan 15 00:37:17 Create3-WaLi user.notice create-platform: [INFO] [1705279037.365257274] [system_health]: CPU usage: max 83 [%] mean 65 [%] RAM usage: 40/59 [MB]
Jan 15 00:38:17 Create3-WaLi user.notice create-platform: [INFO] [1705279097.366964379] [system_health]: CPU usage: max 86 [%] mean 70 [%] RAM usage: 40/59 [MB]
Jan 15 00:39:17 Create3-WaLi user.notice create-platform: [INFO] [1705279157.368363978] [system_health]: CPU usage: max 86 [%] mean 79 [%] RAM usage: 40/59 [MB]

I don't have a use case for the tranform_listener.cpp (or .py which also exists there), so I'll leave that exercise to the OP.

IMPORTANT NOTE: The Create3 docs show typing the bot-killer command when discussing the coordinate system. Perhaps this should be changed to two tf2_echo commands to keep the bot from crashing:

NOTE:  Press ctrl-c as soon as the transform starts appearing - to minimize load on the Create3

ros2 run tf2_ros tf2_echo odom base_link
ros2 run tf2_ros tf2_echo odom base_footprint

[slowrunner]

Perhaps even limiting the echo to once per 10 seconds with

ros2 run tf2_ros tf2_echo odom base_link 0.1
ros2 run tf2_ros tf2_echo odom base_footprint 0.1

to avoid overload and give time for user to hit ctrl-c

[alsora]

Doesn't this message contain two totally static transformations: odom->base_link, and odom->base_footprint,
so won't every message be exactly the same as the prior?

This is not correct.
Both odom -> base_link and odom -> base_footprint are NOT static transformations.
They do change over time as you move the robot around.

Static transformations are only published on the tf_static topic

[alsora]

I suspect this is why the ROS 2 docs provide instructions on listening to transforms using either the dedicated tf2_echo command or writing a tf2 listener that leverages the TransformListener object from the tf2_ros package

The reason why the docs suggest to use those is because "tf" is actually made of two separate topics: /tf and /tf_static.
The tools you listed will subscribe to both topics and combine them into a single tree, to facilitate their usage.

So, both those tools will always do more work than simply subscribing to tf.
(tf2_echo is mostly just a wrapper around creating an application made only of a tf listener)
On the create3-side you are now publishing two topics over the network.
On the laptop-side you are subscribing to two topics and combining transformations into a tree.