GoPiGo2 Distance Sensor Issues

Hey there,

For a long time I’ve been working to debug my distance sensor (the white one) on my GoPiGo2. The basic issue is that when looping to print the distance readings, the sensor will start printing a continuous stream of "0"s after a while, with the only fix I’ve discovered being to disconnect the sensor for a little while and then replug it in, only for for the 0 stream to reappear a few seconds later. I’ve scoured this forum for threads searching and plugging in fixes for a solution. Sadly most of the threads have either been for the GoPiGo3 robot with ports the GoPiGo2 doesn’t provide, or just dead after a few replies and with no solution. On the software side of things, I’ve traced errors back to a .egg file which is unfortunately locked from end user inspection. I’ve reached a serious dead end here, any help?

1 Like

To look inside treat it like a zip file

Unzip -v xxx.egg

But the file I am guessing is the ?

If so see

In my opinion you should try initializing the distance sensor with
And see if that fixes your problem. (It always does for me.)


Do what I did. I copied 'em all to a directory in my home folder and changed the ownership to pi:pi. (you need to be root to do this)

You can un-zip all of the little beasties and snoop them out to your hearts content.

the egg file is not meant for you to change it
The code should be in /home/pi/Dexter/di_sensors/Python/di_sensors.

if you make a change you need to run
python3 install after so a new egg gets created. (you have to be in /home/pi/Dexter/DI_Sensors/Python to run this command)

1 Like

Correct me if I’m wrong, but my understanding was that Python looks in the current project directory first to satisfy dependencies (like includes) before looking elsewhere in the Python path.

So, if I wanted to “dink” with a library file, (like, I could place a copy in my project’s directory and Python would use that one first.

Another reason for doing that, (placing a copy of the .egg file in your home path and unpacking it there), is that the rest of the system can use the True and Authorized version while you dink with your private copy.

Hi again, sorry for the delay but I had to wait until the weekend for me to have enough time to work on it again.

Anyways, thank you everyone who helped in the thread! I also emailed support who gave me some other tags to try out. With all this help I was able to fix my issue, so I would like to share my findings here if anybody else has these issues in the future.

I ended up using the .start_continuous() and .read_range_continuous() to get a nonstop continuous stream of reading printed without any need for time.sleep() delays.

For the tags, I was given three tags to try, those being RPI_1, RPI_1SW, and RPI_1HW. I’m using the DIstanceSensor module, so my implementation was something like DistanceSensor(bus = ‘RPI_1’) in the initial declaration. Of the tags, RPI_1 and RPI_1SW worked perfectly, while RPI_1HW gave me an IOError: I2C bus not supported error when I ran all of them from the terminal.

Also, support told me if you’re using EasyDistanceSensor, you can just replace “bus” with “port” in the initialization, although I didn’t confirm it.

Thanks again and I hope this thread helps other people as well!