Interfacing with GPIO pins makes robot stutter

GoPiGo
1

Hi. I have added two ultrasonic sensors to the raspberry with GPIO pins 23,24 and 17,27.
When I make the robot drive, in whatever way, it stutters extremely when I start the python script that reads (and writes) to the ultrasonic sensors via the GPIO pins. When I stop this script this stuttering doesn’t stop until I restart the python script that makes the motor drive.

I want to use this robot with ROS, I’ve tried this script with and without ROS integration and gives the same issue. (I’ve asked the same question on the ROS forums: https://answers.ros.org/question/286687/node-slowing-down-other-node-on-raspberry-pi/)

Whats going on?

2

Greetings!

I hate to resurrect an old message, but since nobody has made an effort to answer, here goes!

@quintvdijk

There is a very simple explanation.  Some of the pins you’re using are reserved for other purposes.  Specifically, pin 27 is a reserved pin and should not be used.

Viz.:
The two pins shown as white circles are “reserved” pins used for reading/writing to either an onboard EEPROM or the EEPROM required to be on any RPi “hat” - I’m not sure which.  Pin 23 is also one of the SPIO pins.

GPIO%20Pins%20on%20Pi

You should check your use of the other pins too.  Though most other pins are “fair game”, some are specifically analog only, some are digital only, and others can be both.  Additionally, many of the pins have programmable pull-up and/or pull-down elements connected to them - which, depending on what you want to do with them - may need to be programmed before the pin will do what you want.

Another caution:  Most, if not all, of the GPIO pins are connected directly to the processor or other important support chips! - they’re not “buffered” or “isolated” in any way.

Translation:  If you’re not careful you can “burn out” either the GPIO interface itself, or your entire Raspberry Pi.

Valuable Resources:

Jim “JR”