Wow - ROS2 GoPiGo3 w/all sensors equals 45-60% load

GoPiGo
, ,
1

Big Test Tonight: Full Up ROS2 GoPiGo3 with:

  • GoPiGo3 node publishing:
    • /battery_voltage
    • /motor/encoder/left
    • /motor/encoder/right
    • /motor/status
    • /odom
    • /tf
    • /joint_states
       
      and subscribed to motor, servo, and LED commands
  • DI V53L0X ToF Distance Sensor - publishing at 20Hz
  • Grove Ultrasonic Ranger - publishing at 16 Hz
  • LIDAR - publishing at 9Hz
  • AND a new “safe” IMU Sensor at 30Hz target rate*

Is drawing 0.7A at 10.1v and loading the Raspberry Pi 3B+ at roughly 45% load average with some bumps at 60% load

********* ROSbot STATUS *****
2021-09-24 00:54:20 up 1:10, 3 users, load average: 2.09, 2.17, 2.33
Current Battery 11.15v EasyGoPiGo3 Reading 10.34v
5v Supply: 4.97
Processor Temp: 56.4’C
Clock Frequency: 1.40 GHz
throttled=0x80000

********* ROSbot STATUS *****
2021-09-24 00:54:25 up 1:11, 3 users, load average: 2.16, 2.18, 2.33
Current Battery 11.18v EasyGoPiGo3 Reading 10.37v
5v Supply: 4.96
Processor Temp: 56.9’C
Clock Frequency: 1.30 GHz
throttled=0x80000

BUT something weird was happening with the /imu_sensor/imu topic:

ros2 topic hz /imu_sensor/imu

started reporting 1Hz and it was slowly climbing - to 20Hz and then BOOM!

Distance Sensor di_i2c.py: OSError: [Errno 5] Input/output error
(Unhandled I2C BUS ERROR)

Looks like I need to toughen my ROS2 Distance_sensor node.

End of test - 1:15AM - imu is still kickin’ it strong - up to 30Hz finally.

p.s - Did you know that you can “hot charge” the new Li-Ion battery pack while running your GoPiGo3? It takes a little longer because the GoPiGo3 is using half or more of the charging current (in my case running ROS - 700mA of the 1000mA the charger will put out.)

1 Like
2

New Test: No I2 DI Distance Sensor

Everything runs better w/o the DI Distance Sensor running, and the processor load is running 30-40% even with driving around, with power consumption while driving at 7.25W (630mA at 11.4v).

Well not everything - my Rviz2 in the Ubuntu virtual machine on my Mac stops displaying the ultrasonic range after a while complaining:

[rviz2-3] [INFO] [1632485411.244881189] [rviz2]: Message Filter dropping message: 
frame 'ultrasonic_ranger' at time 1632485401.097 for reason 'Unknown

The topic is sent at 16 Hz average, with a minimum rate of 8 Hz reported.

The IMU reported 41 soft I2C exceptions in the first hour of running (even w/o competition from the distance sensor).

Processor temperature is holding nicely under 60 degC with room temp at 26 degC.

********* ROSbot STATUS *****
2021-09-24 08:37:56 up 1:03, 2 users, load average: 1.30, 1.29, 1.37
Current Battery 11.07v EasyGoPiGo3 Reading 10.26v
5v Supply: 4.98
Processor Temp: 58.0'C
Clock Frequency: 1.20 GHz
throttled=0x0

(Note the clock freq is not at max 1.4 GHz, so just taking it easy during Dave’s little “walk in the park”.)

1 Like
3

Cool report.
Any ideas on why the IMU started reporting more frequently? Did that happen in the subsequent run?
I’m not currently using the distance sensor - maybe I’ll just take it off. That would also let me mount the IMU along the center line, although I don’t know that that will be much of an advantage.

I assume the topic was still publishing? What happens if you restart RVIZ?

I’ve done that while testing my robot on a stand. It is handy.

2 Likes
4

The IMU factors out all “off center” of rotation automatically. No need to move it.

2 Likes
5

I think it was mutex competition between the Distance Sensor and the IMU. When I disabled the Distance Sensor, the IMU immediately published at a steady 30 Hz.

2 Likes
6

Yes the topic is steady, Rviz just seems to lose it. Restarting Rviz2 will get it back for a while, then eventually lose it again.

2 Likes