I really cannot understand Matt did this, he seemed to be a brilliant EE. Even I would not make a voltage dependent voltage “reference”.
Too weird. The 5v rail seems to be singing to itself, there is so much load induced variation.
I really cannot understand Matt did this, he seemed to be a brilliant EE. Even I would not make a voltage dependent voltage “reference”.
Too weird. The 5v rail seems to be singing to itself, there is so much load induced variation.
What do you mean “Hopefully”?
You went to all the trouble to add an external supply and cabling, and did not run get_throttled in one shell, and stress in another?
throttled.sh:
#!/bin/bash
#
# loop printing out processor temp, processor clock freq, and throttled status
#
# 0x50000 means throttling occurred, under-voltage occurred
# 0x50005 means throttled now and under-voltage now
# 0x80008 means soft temperature limit exceeded (no throttling yet)
#
while true; do uptime && vcgencmd measure_temp && vcgencmd measure_clock arm && vcgencmd get_throttled; free -t -m; sleep 2; echo ''; done
Actually, it wasn’t necessary.
Anything more complicated than sneezing got me the alert.
Since I have a large monitor with a desktop showing 99% of the time, that’s better, faster, and just as effective as a script.
Joking, correct?
With the monitor and desktop, I would guess the Pi4 be eating 3W or 0.6A on the 5v supply.
When I stress Dave with stress -c 3 -t 300
it runs just above the 60degC soft temp limit, (which does not trigger frequency throttling), but no under voltage is reported. The power meter claims 8W load on the battery, not all of that going to the processor of course.
At stress -c 4, 1m load average 4.1 to 4.2, the temp climbs to 68degC in 5 minutes, but still no temperature throttling nor under_voltage throttling. Battery load was still reading around 8W.
Something seems off that you would ever see an under voltage condition in “normal use” conditions.
. . . and if you remember, I complained about it bitterly!
It is for that reason, and for that reason only, that I added the buck-converter to supply power direct to the Raspberry Pi’s USB power connector.
For reference:
GoPiGo3 v3.x.x
11.1v nominal Li-Ion Battery
Running stress -c 3 -t 300 just bumps the 60degC soft temp limit
(which does not trigger temperature throttling)
Running stress -c 4 -t 300 will reach 68degC, but will not trigger throttling
Note: No under_voltage throttling occured in either test
Running processes:
#!/bin/bash
#
# loop printing out processor temp, processor clock freq, and throttled status
#
# 0x50000 means throttling occurred, under-voltage occurred
# 0x50005 means throttled now and under-voltage now
# 0x80008 means soft temperature limit exceeded (no throttling yet)
#
while true; do uptime && vcgencmd measure_temp && vcgencmd measure_clock arm && vcgencmd get_throttled; free -t -m; sleep 2; echo ''; done
pi@PIOSLGCY:~/GoPiLgc/systests/throttling $ stress -c 4 -t 300
stress: info: [4296] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: info: [4296] successful run completed in 300s
temp=67.7'C
frequency(48)=1200000000
throttled=0x80008
total used free shared buff/cache available
Mem: 871 171 401 14 298 629
Swap: 99 0 99
Total: 971 171 501
13:41:15 up 15 min, 2 users, load average: 4.05, 3.33, 1.81
Ran that.
Also ran the remote camera robot and spun the wheels.
These are the results I received.
(It peaked around 72-or-so degrees.)
21:37:04 up 1:09, 2 users, load average: 4.03, 2.32, 2.19
temp=71.1'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 205 3145 69 435 3384
Swap: 99 0 99
Total: 3887 205 3245
21:37:07 up 1:09, 2 users, load average: 4.03, 2.32, 2.19
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 206 3145 68 434 3384
Swap: 99 0 99
Total: 3887 206 3245
21:37:09 up 1:09, 2 users, load average: 4.19, 2.38, 2.21
temp=70.6'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 207 3146 67 433 3384
Swap: 99 0 99
Total: 3887 207 3246
21:37:11 up 1:09, 2 users, load average: 4.19, 2.38, 2.21
temp=72.0'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 207 3137 76 442 3376
Swap: 99 0 99
Total: 3887 207 3237
21:37:13 up 1:09, 2 users, load average: 4.19, 2.38, 2.21
temp=72.0'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 181 3163 76 442 3402
Swap: 99 0 99
Total: 3887 181 3263
21:37:15 up 1:09, 2 users, load average: 4.17, 2.41, 2.22
temp=70.6'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 180 3175 65 431 3413
Swap: 99 0 99
Total: 3887 180 3275
21:37:17 up 1:09, 2 users, load average: 4.17, 2.41, 2.22
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 180 3174 66 432 3412
Swap: 99 0 99
Total: 3887 180 3274
21:37:19 up 1:09, 2 users, load average: 4.16, 2.44, 2.23
temp=71.1'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 180 3174 66 432 3413
Swap: 99 0 99
Total: 3887 180 3274
21:37:21 up 1:09, 2 users, load average: 4.16, 2.44, 2.23
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3176 65 431 3414
Swap: 99 0 99
Total: 3887 179 3276
21:37:23 up 1:09, 2 users, load average: 4.16, 2.44, 2.23
temp=71.5'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3177 64 430 3415
Swap: 99 0 99
Total: 3887 179 3277
21:37:25 up 1:09, 2 users, load average: 4.15, 2.46, 2.24
temp=71.1'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 180 3175 65 431 3414
Swap: 99 0 99
Total: 3887 180 3275
21:37:27 up 1:09, 2 users, load average: 4.15, 2.46, 2.24
temp=70.6'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3175 66 432 3413
Swap: 99 0 99
Total: 3887 179 3275
21:37:29 up 1:09, 2 users, load average: 4.13, 2.49, 2.25
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3175 65 431 3414
Swap: 99 0 99
Total: 3887 179 3275
21:37:31 up 1:09, 2 users, load average: 4.13, 2.49, 2.25
temp=71.5'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3174 66 432 3413
Swap: 99 0 99
Total: 3887 179 3274
21:37:33 up 1:09, 2 users, load average: 4.13, 2.49, 2.25
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3175 66 432 3413
Swap: 99 0 99
Total: 3887 179 3275
21:37:35 up 1:09, 2 users, load average: 4.20, 2.53, 2.26
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3177 64 430 3415
Swap: 99 0 99
Total: 3887 179 3277
21:37:37 up 1:09, 2 users, load average: 4.20, 2.53, 2.26
temp=72.0'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3178 63 429 3417
Swap: 99 0 99
Total: 3887 179 3278
21:37:39 up 1:09, 2 users, load average: 4.27, 2.57, 2.28
temp=71.1'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3178 63 429 3416
Swap: 99 0 99
Total: 3887 179 3278
21:37:41 up 1:09, 2 users, load average: 4.27, 2.57, 2.28
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 178 3178 63 429 3417
Swap: 99 0 99
Total: 3887 178 3278
21:37:43 up 1:09, 2 users, load average: 4.27, 2.57, 2.28
temp=71.5'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3178 63 429 3417
Swap: 99 0 99
Total: 3887 179 3278
21:37:45 up 1:09, 2 users, load average: 4.25, 2.60, 2.29
temp=70.6'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3178 63 429 3417
Swap: 99 0 99
Total: 3887 179 3278
21:37:47 up 1:09, 2 users, load average: 4.25, 2.60, 2.29
temp=71.1'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 178 3178 63 429 3417
Swap: 99 0 99
Total: 3887 178 3278
21:37:49 up 1:09, 2 users, load average: 4.23, 2.62, 2.30
temp=72.0'C
frequency(48)=1500398464
throttled=0x0
total used free shared buff/cache available
Mem: 3787 178 3178 63 429 3416
Swap: 99 0 99
Total: 3887 178 3278
21:37:51 up 1:10, 2 users, load average: 4.23, 2.62, 2.30
temp=72.5'C
frequency(48)=1500345728
throttled=0x0
total used free shared buff/cache available
Mem: 3787 179 3177 64 430 3416
Swap: 99 0 99
Total: 3887 179 3277
^C
pi@raspberrypi:~ $
No throttling, no hi-temp, no brownout.
Right now I’m running to exhaustion and I am expecting it to both warn and shutdown.
I will do the battery test to exhaustion later and plot the graph.
Super!
I really wish there was a reliable, inexpensive, i2c voltage/current/power sensor we could add to our bots. I tried the ACS712 sensor (analog voltage output) on my prior bot, but Either current variation was too high, or A2D conversion variation really dumbed down the precision below usefulness.
Robots need proprioception to become intelligent or sentient.
. . . that ran on a couple of coin-cells so that it didn’t depend on the robot it was monitoring for its reference voltages!
The TL431/432 is a three-terminal programmable reference diode that is wildly popular for virtually anything that needs a stable, cheap, and reasonably accurate reference voltage.
When connected as a two-terminal device, (the programming input tied to the cathode), it functions like a 2.5v zener but with, (supposedly), better regulation. Remember all that work I did with the battery pack and switching power supplies? Yep, that’s the one.
I don’t know what the programmed Vref is supposed to be, but if it’s anywhere near 2.5v, this would be a plop-in-place replacement.
tl431.pdf.txt (2.9 MB)
. . . and a dictionary to understand what’s being asked of them.
So 2.5v wouldn’t cut it.
Does that mean with a reference that is ± 0.041v and a 16:1 voltage divider we are asking too much to get a voltage reading better than ±0.7v - I didn’t take that class on circuit analysis - mesh analysis on a bank of solar collectors nearly put me in the school’s funny farm.
([SOLVED] GoPiGo3.volt() and .get_battery_voltage() vs Battery Voltage - #3 by Matt)
Going back and looking at that article, the reference to the 2v reference and the divider network appear to be two different things - I suspect that the microcontroller contains an A/D with a built-in 2v (±) reference.
Looking at the schematic, I note that there is a separate 5v input on pin 4 through an 820Ω resistor and a 0.1μF decoupling capacitor that’s not a power feed, and the VCC reference goes through the resistor network Matt mentioned, (and another 0.1μF decoupling capacitor), to pin 11. My bet is that these two pins are the pins where they measure the Vbatt and V+5 voltages.
I’ve downloaded the datasheet and I’m going to take a look at it.
I just don’t understand why raising the +5v rail causes the A/D for the battery voltage to go nuts. And we’ve seen this before when a Raspberry Pi adapter is plugged into a Raspberry Pi 3 on the 'bot, the apparent Vbatt voltage goes above 14v.
I suspect that folks like Matt are long gone - and more’s the pity - we’ll have to reverse engineer the firmware and schematic logic to make any sense out of any of this stuff.
Right now I’m running to exhaustion and I am expecting it to both warn and shutdown.
I will do the battery test to exhaustion later and plot the graph.
My script warned at just under 10 volts and formally shut down at 9.69 volts.
I followed your lead and my script is set to trigger a shutdown at <= 9.75 and warn at <= 10.00 - and I followed your script’s lead by requiring four successive warns or shutdowns before performing the action.
I numbered the three batteries, and I am going to plot the curve of each of them individually.
The first of the three started at 2:56pm Moscow time, (it is now 8:41pm), and we are at 10.24 v indicated on the meter.
The robot is just sitting there, wasting electricity, , and we’ll see what happens. Actually, I should probably modify it to provide “calibrated” at-the-terminal battery voltage readings as the uncorrected readings are less useful. (IMHO).
@cyclicalobsessive,
It turns out I already have a copy of “Carl” - apparently I cloned your repository at some point in time in the past and now I’ve brought it down to Charlie so he can have fun with some of the interesting things you’ve done.
My script warned at just under 10 volts and formally shut down at 9.69 volts.
This was Dave’s till shutdown test (LIDAR powered but not spinning, USB speaker, camera, IR sensor):
REV_PROTECT_DIODE = 0.81 # The GoPiGo3 has a reverse polarity protection diode drop of 0.6v to 0.8v (n=2)
WARNING_LOW_vBatt = 10.0 # Give Advance Warning battery is around "the knee" (~20 minutes to safety shutdown vBatt )
SAFETY_SHUTDOWN_vBatt = 9.75 # Battery Discharge Protection Circuit allows down to 8.15v (~15 minutes reserve at 9.75v)
IGNORE_TOO_LOW = True # Set False to test shutdown at SAFETY_SHUTDOWN_vBatt instead of running till battery fully discharged
This is it with no Carl/Dave dependence. It does not have shutdown protection, and it logs reading value not adjusted for diode drop battery voltage.
Carl/Projects/LogValueAndPlot at master · slowrunner/Carl · GitHub
From README.md:
Packages needed to be installed:
-matplotlib (sudo pip install matplotlib)
-plotly
It should be noted that, at least on the Raspbian-derived installations, if you want to install for Python3, you need pip3, not pip.
After installing with pip3, I was able to get past the “matplotlib module not found” errors, but now I get this:
pi@raspberrypi:~/Desktop/LogValueAndPlot $ python3 ./plotBattV.py battV/csv/battV-20220316-1456-1.csv
Input File: battV/csv/battV-20220316-1456-1.csv
Traceback (most recent call last):
File "./plotBattV.py", line 38, in <module>
dtObj = datetime.datetime.strptime(file_date, '%Y%m%d-%H%M')
File "/usr/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/lib/python3.7/_strptime.py", line 362, in _strptime
data_string[found.end():])
ValueError: unconverted data remains: -1
pi@raspberrypi:~/Desktop/LogValueAndPlot $ python3 ./plotBattV.py ./battV/csv/battV-20220316-1456-1.csv
Input File: ./battV/csv/battV-20220316-1456-1.csv
Traceback (most recent call last):
File "./plotBattV.py", line 38, in <module>
dtObj = datetime.datetime.strptime(file_date, '%Y%m%d-%H%M')
File "/usr/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/lib/python3.7/_strptime.py", line 362, in _strptime
data_string[found.end():])
ValueError: unconverted data remains: -1
pi@raspberrypi:~/Desktop/LogValueAndPlot $
What did I do wrong?
This is the file I was trying to plot. . .
battV-20220316-1456-1.csv.txt (107.2 KB)
(the “-1” indicates that this is the first of the three batteries)
Update:
The original file had a bunch of NULL bytes at the end. I removed them and tried again and got the same error.
What did I do wrong?
This is the file I was trying to plot. . .
battV-20220316-1456-1.csv.txt (107.2 KB)(the “-1” indicates that this is the first of the three batteries)
So line 38 is trying to get the date from the file name and it doesn’t expect that extra “-1” in the file name.
# reads data file passed as parameter e.g. ./plotBattV.py battV/csv/battV-YYYYmmdd.csv
# note datafile must be named exactly that format
...
file_date = inFile[-17:inFile.find(".csv")]
dtObj = datetime.datetime.strptime(file_date, '%Y%m%d-%H%M')
The easiest fix is probably to make some folders batt1, batt2, batt3 and change the file name back to the expected.
* If desire output in a specific place, set base_dir variable: ./ is the default
The original file had a bunch of NULL bytes at the end. I removed them and tried again and got the same error.
Yes, that is what happens when the power is yanked. Removing them is needed.
I also spied a more recent version of the battery logging toolset, but I don’t think the plot program changed. It seems like I added some options to the vBatt logging program when I started working with Dave and the Li-Ion Battery:
Autonomous ROS2 home robot based on GoPiGo3 and RaspberryPi
OK, I’m in.
I ran two graphs and they run from 0:00 to 23:59 even though the data on one graph is a narrow band down the middle and the other crossed midnight, so half the data is missing.
Two questions:
rosbot-on-gopigo3/systests/battery at main · slowrunner/rosbot-on-gopigo3 · GitHub
I ran two graphs and they run from 0:00 to 23:59
- Is it possible to scale the graph so that it fits the data like many of the pictures you show?
Did you use plotBattV.py or plotBattLife.py? Did you try the other one?
Do you know how to capture a specific folder, (and subfolders) from GitHub instead of having to clone the entire repository to get what I want? (i.e. the …/systests/battery folder and subfolders?)
No I don’t, so what I end up doing is make the desired folder on the RPi, in a browser clicking on each github file I want, clicking the RAW button, copying the URL, then in a shell type
wget [paste URL here]
to bring the files down one at a time. I usually chmod 777 *.py
at the end.
It appears I was using the “wrong” plotting script.
Here are the three batteries - all of which should have been started from fresh.
Note: Battery numbers are arbitrary and mean nothing other than a way to distinguish one battery from another.
Battery 1:
Input File: battV/csv/battV-20220316-1456.csv
First datetime: 2022-03-16 14:56:32 [11.693 volts]
Last datetime: 2022-03-16 21:31:07 [8.403 volts]
Total Life: 6.58 hours
Battery 2:
Input File: battV/csv/battV-20220316-2145.csv
First datetime: 2022-03-16 21:45:22 [11.659 volts]
Last datetime: 2022-03-17 04:02:49 [8.095 volts]
Total Life: 6.29 hours
Battery 3:
Input File: battV/csv/battV-20220317-1115.csv
First datetime: 2022-03-17 11:15:01 [11.976 volts]
Last datetime: 2022-03-17 18:24:37 [7.966 volts]
Total Life: 7.16 hours
The variation in battery lifetime is something like 52 minutes from shortest to longest - though I think that might be caused by the second battery test being run while I was installing and removing plotting dependencies two or three times to get it right.
In any event, I will want to re-run these tests using freshly changed batteries and nothing else happening to see if that difference is real.
The only thing I wish was that the battery voltage and time scales had minor graduations and some minor graduation graticule lines to help interpret the data without a compass and straightedge. I looked at the plotting code, (quickly, I was with the granddaughters all day today), and didn’t see anything that jumped out at me as far as what defined the graduations.
Thanks!
wish was that the battery voltage and time scales had minor graduations
https://matplotlib.org/stable/gallery/lines_bars_and_markers/simple_plot.html
https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.grid.html