ROS2: Distance Sensor Node Using 68% CPU?

GoPiGo
1

In debugging “why is the slam-toolbox dropping all the lidar scans?”, I looked to see how the processor load was looking - uptime reports 1minute load of 1.64 which correlates to 41% load on the 4-core Pi4B CPU, and the temp is up to 64degC which is still in the “no worries” range (<70C, and <80C).

Next I looked at how much the top consumers were using, and discovered a very unexpected name at the top of the list:

top

which is surprising since the distance sensor is only publishing at 10Hz

DistanceSensor_hz
DistanceSensor_hz1454×224 101 KB

while the gopigo3_node is publishing odometry /odom and frame transform /tf topics at 30 Hz doing a bunch of math and only taking 24% of the CPU.

“Somethings Rotten In Denmark” as my 6th grade elementary teacher used to repeat when we didn’t know what we were talking about. I never understood that, nor his “What does that have to do with the price of eggs in Russia?”, but I wish he were here to help me “out of this pickle”.

2 Likes
2

This sensor has a really high processor usage for some reason. I can get a 10 Hz, single read, non-ROS, non-mutex protected, non-3-reading averaged, non-near and far limited, loop to be 15% of the CPU. I don’t know if that will be “safe”, and acceptable.

Most ROS robots do not have or depend on a “long range, wide beam” ToF sensor. I included it in my ROS2 exploration since it is common on GoPiGo3 robots, but am not going to start the node in the normal case to conserve resources.

For reference to anyone following after, this is my test code for the minimal load:

#!/usr/bin/env python3

from time import sleep
import easygopigo3 as easy

gpg = easy.EasyGoPiGo3(use_mutex=True)

my_distance_sensor = gpg.init_distance_sensor()

while True:
    # print("Distance Sensor Reading: {} mm ".format(my_distance_sensor.read_mm()))
    # print("Distance Sensor Reading: {} mm ".format(my_distance_sensor.read_range_single()))
    # print("Distance Sensor Reading: {} mm ".format(my_distance_sensor.VL53L0X.read_range_single_millimeters()))

    # just read it, no printing
    my_distance_sensor.VL53L0X.read_range_single_millimeters()
    sleep(0.10)

Interestingly, using this minimal read still results in 50% CPU load by the ROS2 distance_sensor_node.

For comparison, my ROS 2 IMU sensor node which performs three I2C sensor reads, of much more data,only consumes 26% CPU.

1 Like
3

Is this a script?

One of the things I noticed when doing my joystick controlled robot project was that a number of routines run like they’re the only thing on the 'bot and I found it necessary to write a generic throttling routine that would limit the amount of time spent doing that particular task.

  • Anything new to report?  No??  Next!
  • Has “x” amount of time passed yet?  No??  Next!

Otherwise I would have ended up flooding the network with irrelevant noise and not had time to do the other tasks I needed to do.

You may have to throttle that process too.

1 Like
4

Supposedly sleep(0.1) reduces the load to only 10 times per second. I have measured the “mutexed 3-reading, range-limited, averaged” performance at 17Hz if left unthrottled.

I’m throwing this sensor to the “been there, done that” bin for now. Serious off-track distraction.

1 Like