GoPiGo3 Low Voltage Shutdown Specifics?

GoPiGo
1

( @Matt )

Some questions about GoPiGo3 power management

I have not previously let battery voltage drop below 8v which is when egpg.volt() returns 7.4v on my GoPiGo3. In fact, I usually shutdown with 15 - 45 minutes of power left (egpg.volt() returning 8.1 volts.)

Today I was running without my safety shutdown code thinking that gopigo3_power.py would safely force a shutdown before the 5v rail sags.

Just before my wireless remote shell went down:

  • egpg.volt() returned 4.92v
  • egpg.get_voltage_5v() returned 4.01v,
  • the processor was screaming “THROTTLED!!! = 0x50005”

.
Q1) Was my SD card at risk of corruption at this supply voltage?

Q2) When does gopigo3_power.py kick in?

Q3) Can too frequent calls or requests from multiple processes to egpg.volt() return erroneous values?

Q4) Can egpg.volt() calls interfere/collide with the GoPiGo3 board supply voltage protection measurements?

root       361     1  0 20:13 ?        00:00:00 bash /home/pi/Dexter/GoPiGo3/Install/gpg3_power.sh
root       723   361  0 20:14 ?        00:00:00 sudo python /home/pi/Dexter/GoPiGo3/Software/gopigo3_power.py
root       727   723  0 20:14 ?        00:00:00 python /home/pi/Dexter/GoPiGo3/Software/gopigo3_power.py

while True:
    if GPIO.input(22):
        os.system("shutdown now -h")
    time.sleep(0.1)

Carl’s last words before the world ended:

********* CARL Basic STATUS *****
2019-03-31  17:15:35 up  7:24,  2 users,  load average: 0.11, 0.05, 0.01
Battery Voltage: 4.92
5v Supply: 4.01
Estimated Life Remaining: 0 h -31 m
Processor Temp: 43.5'C
Clock Frequency: 600.0 MHz
throttled=0x50005
Distance Sensor: nothing within 90 inches

Juicer Values:
lastReading 5.08 volts
num of readings 45
shortPeakVolts 6.60 volts
shortMeanVolts 5.84 volts
shortMinVolts  5.49 volts
longPeakVolts  7.73 volts
longMeanVolts  7.24 volts
longMinVolts   5.08 volts
Traceback (most recent call last):
  File "./juicer.py", line 110, in <module>
packet_write_wait: Connection to 10.0.0.225 port 22: Broken pipe

(longXvolts is the last 5 minutes, shortXvolts is the last 1 minute.)

2

gopigo3_power.py does not automatically shut down the RPi due to low voltage. What it does is monitor the signal from the GPG3 to determine if the power button was pressed and the RPi needs to do a safe software shutdown.

To answer your questions:

  1. Yes your SD card could have been corrupted. This is most likely to happen if it’s actively being written to (writing a file) when the power gets removed. On a system such as the RPi, writing files could be very unpredictable, happening in background processes. This is why the power to a RPi should never be abruptly removed unless the RPi has already completed it’s software shutdown.

  2. gopigo3_power.py starts running as soon as the RPi boots up. However, refer to my comments above about what it does and does not do.

  3. I don’t believe so. If you have too many processes trying to communicate with the GPG3 at the same time, some of them will be delayed, waiting for the others to finish.

  4. I don’t believe so. Back-to-back communication with the GPG3 shouldn’t prevent the firmware from doing it’s thing. Maybe theoretically you could create a sort of “denial of service” attack, where the FW is so busy answering communications that it’s unable to perform all it’s other duties in a timely manner, but I have never recognized evidence of this type of situation.

The only way the GPG3 attempts to protect against low voltage shut-down is by disabling the motors when the voltage gets too low. It’s up to the user to monitor the voltage and shut down the RPi in a timely manner. You could easily create a script that shuts down the RPi when the voltage drops below a set threshold, but there is no way for the RPi to trigger the GPG3 to actually kill the power. Adding a “shutdown” command into the API and FW so the RPi can put the GPG3 into shutdown mode (as if the power button was pressed) has been discussed, but is not a development priority.

1 Like
3

That explains it. I knew it was how the GoPiGo board could cause a shutdown, but could not figure out what those conditions might be.

Like I said, I have always run with a safety voltage shutdown routine so this turned out to be a reckless experiment since I wasn’t around to see the power LED color changes.

I shan’t try again.

4

Basically worst-case is that the SD card gets corrupted and you lose all the files on it. In this situation you can simply re-flash the OS and boot up again. There shouldn’t be any hardware damage.

5

I haven’t seen that, but I have had two, or maybe three cards turn into read only. The would continue to boot just fine, and seem to be writing to the card, but they would forget the changes when rebooted or power cycled. This was not with GoPiGo, was with my prior Raspberry Pi bot.