How to soft reset gopigo leds

Hi everyone,

The leds of my gopigo2 robot fairly often become stuck either on (or off, I think) while my python autodrive program is running.
In these cases, using gopigo.led_on(l_id) or led_off(l_id) has no effect.

Restarting the raspberry pi brings the leds back under my control, but I would have wanted to fix them without exiting the autodrive program : both to be able to check programatically if there is a problem, then fix it, possibly by some soft reset of the leds.

Does anybody know how this problem can be adressed?

Thanks,
BKG

2 Likes

Suggest sending your post to support@modrobotics.com

The only thing I can think of to try is to open a second shell/terminal and run something like:

#!/usr/bin/env python

# FILE:  reset_leds.py
# USAGE:  python reset_leds.py

import gopigo
import time

# performs raw analog read
print("version:",gopigo.check_version())
time.sleep(1)

# performs i2c_block_command
print("battery voltage:", gopigo.volt())
time.sleep(1)

# performs i2c_block_command to control board
print("sending stop to gopigo")
gopigo.stop()
time.sleep(1)

# try turning LEDs on and then off (sets pin mode output and performs digital write)
print("Sending LED on")
gopigo.led_on(0)
gopigo.led_on(1)
time.sleep(1)
print("Sending LED off")
gopigo.led_off(1)
gopigo.led_off(0)
time.sleep(1)

print("Exiting")
2 Likes

Thanks -

When the gopigo is in need of reboot (which is what I hoped could be avoided):

I get -1 as output/status for volt() and stop(), and also for disable_servo().

For led_on/off, status 1 is returned, but the leds do not change (can be on/off when this starts).
Furthermore, get_led() returns 0, regardless of whether light is on or off.

check.version() returns 14.

Does this shed any more light on the situation?

1 Like

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.

2 Likes