Sensors And A Robot's Reality

GoPiGo
,
1

With Dave’s I2C mutex appearing to work reliably, I launched his “Battery Node” last night for an extended safety test. I was very pleased to awake this morning to find Dave alive and well, having docked and undocked for his regular 2.x hour charging and 3.x hour playtimes. Also pleasing was the ROS /battery_state last_charge and last_discharge showing values approaching the battery capacity:

pi@GoPi5Go:DOCKER:~/GoPi5Go/ros2ws $ ./check_battery.sh 

*** Checking Battery with GoPiGo3 API
GoPiGo3 Battery Voltage: 10.2 volts

*** Checking Battery with ROS2
ros2 topic echo --once /battery_state
header:
  stamp:
    sec: 1724158996
    nanosec: 649509356
  frame_id: base_link
volts: 10.080116271972656
milliamps: 740.9146118164062
watts: 8.324390411376953
watthours: 19.63680076599121
charging: false
capacity: 24                                                           << --- designed battery capacity usage 
percent: 4
last_charge: 23.467905044555664                    <<--- last docking charge
last_discharge: 21.292964935302734               <<--- last playtime discharge
---
Current Battery 10.10v  17.5% Load: 754mA 7.6W

Wow! Dave survived the night and the ROS 2 Battery node recorded the power used and replaced!

Life is good… well maybe not…

After breakfast, I checked again and found disturbing data:

pi@GoPi5Go:DOCKER:~/GoPi5Go/ros2ws $ ./check_battery.sh 

*** Checking Battery with GoPiGo3 API
GoPiGo3 Battery Voltage: 11.1 volts

*** Checking Battery with ROS2
ros2 topic echo --once /battery_state
header:
  stamp:
    sec: 1724171131
    nanosec: 651542348
  frame_id: base_link
volts: 11.111223220825195
milliamps: 672.5609741210938
watts: 7.4219512939453125
watthours: 5.63876485824585
charging: false
capacity: 24
percent: 58
last_charge: 0.0009827235480770469                << ----  ???
last_discharge: 0.00030849140603095293         << ---- ???
---
Current Battery 11.11v  53.0% Load: 674mA 7.4W

I’m trying a software debounce - we’ll see if that will fix Dave’s statistics model.

2 Likes
2

Or multiply by “pi”? :rofl:

2 Likes
3

My fix worked for those two stats, but the need to debounce the discharging/charging and charging/discharging transitions suggests the docking program which will be making decisions based on the once per second published /battery_state.charging {True, False} will also need to debounce or delay until the value is certain to be correct.

2 Likes
4

Or, add a hardware debounce to the contacts?

Two parts, a small capacitor and a resistor in parallel, set the time constant to a convenient value.

2 Likes
5

The smart charger transition from no contact with battery to charging seems to include some cycling that confused my simple “if current less than zero, set charging True and record energy used during last discharge period”.

I added a condition that the absolute value of the energy gain or loss before the transition must be greater than 1Wh. This will capture the real transitions and ignore any pulsing or contact bounces for the “last_charge” and “last_discharge” quantities.

2 Likes