That value indicates a problem with I2C communication between the Raspberry Pi and the GoPiGo board.
In my work with the newer GoPiGo3, my robots sometimes start reporting [Errno 5] IOError when I attempt I2C reads. Sometimes after a bunch more I2C read attempts the problem will clear and my bot can continue normally. Most times the I2C bus does not heal itself, and I must perform a power-off-on cold boot to restore full function.
Perhaps if someone really understood how I2C works at the “write bytes, read bytes” level it can be restored, but from the standpoint of the GoPiGo3 API, I have not been successful.
One thing you might try is to use the mutex protected class (in every running program on the bot):
#!/usr/bin/env python3
import easygopigo
import gopigo
print("gopigo.debug:", gopigo.debug)
print("setting gopigo.debug True")
gopigo.debug = True
print("gopigo.debug:", gopigo.debug)
print("Instantiating mutex protected egpg")
egpg= easygopigo.EasyGoPiGo(use_mutex=True)
print("gopigo.debug:", gopigo.debug)
print("setting gopigo.debug True")
gopigo.debug = True
print("gopigo.debug:", gopigo.debug)
count = 0
battery = 0
while ((count < 500) and (battery < 7)):
count+=1
try:
battery = egpg.volt()
print("battery: {}".format(battery), end="\r")
except Exception as e:
print("volt() threw exception: ", str(e))
egpg.led_on(1)
egpg.led_off(1)
(I don’t have a GoPiGo and the GoPiGo3 does not have a debug variable so I could not try that code)
I don’t expect that will solve the issue, but it is something to try before throwing the bot out the window in frustration.