What can be wrong using ALL the Grovepi+ ports (+8 i2c Hub) when using threads?

Hi there, I am building a system that uses ALL the ports:

  • I am using 5.1V 3A power… is this going enough to “feed” the system?
  • using multiple threads is ok with such system? (e.g., one will be waiting to push button do to x) in other words, do I need to implement socket or semaphores to guarantee data will be not corrupted?
  • is this ok to work 24/7 like a proper industrial system?
  • btw some Grove sensors are not supported in RPI got a custom port to rpi (a dev created a library)

Maybe the solution will be communicating 2 rpis (both with Grovepi+ sensors) via Ethernet/WIFI/Bluetooth/GPIO?

Thanks in advance!



I’m order to help you, we really need more information about what you’re doing.

If I assume that your question is entirely about the Raspberry Pi’s ability to source power to other devices, then that is not something the Pi was designed to do.

In the case of my GoPiGo robot, I have to provide two power sources to guarantee enough power to both the Pi-4 I am using and the robot’s own circuitry:

  1. +12 vdc to the robot (which also provides a limited amount of +5v to the Raspberry Pi)

  2. An additional +5 vdc through the Raspberry Pi’s own power connector to guarantee that the voltage to the Pi doesn’t droop under heavy robot loads.

I do this by connecting the 12v source through a relatively high current 12v to 5v converter and feeding the +5 through the power connector on the edge of the Raspberry Pi’s own circuit board.

Since I am not sure what you are trying to do, I am not sure what advice to give you.


Thanks, nothing to do with the NoPiGo I will be using x2 RPIs with Grovepi+ each connected by ethernet

1st one does cameras checks to trigger different robotics while the 2nd one is simply reading from different sensors. Both devices share info reading via ftp a text file for making decisions by the 1st one

So far I think this split will have zero issues in terms of software interruptions/crashes and as you explained, RPI may handle well the power needed for these (now even more with the system split in 2)

On the other hand, it is a real pity that Dexter did not add libraries for certain sensors such as the Grove - 2 Channel Inductive Sensor (LDC1612) - Seeed Wiki among many others only compatible with Arduino…


Part of the problem ISN’T Dexter, it’s the design of the sensors and the lack of support Seeed studios provides.

In many cases devices that were supported have changed beyond recognition, but the basic driver code hasn’t.

I have bought sensors and devices from a number of vendors, Seeed Studios among them.

In my own experience, both Arduino and Pi, I have never gotten a Seeed Studios device to work properly.

There are other people on these forums who have also tried Seeed Studios sensors with no success.

Another thing is that Arduino and the Pi are really directed to two different segments of the maker-space market.

The Arduino is intended to be a low-level controller whereas the Pi is a higher level computing platform. A good example are the designs where one or more Arduinos are connected to sensors, do the lower-level data acquisition and data conversion, (which the Arduino excells at), and feeds processed data to the Pi for more advanced analysis and control.

As far as industrial applications are concerned, Raspberry Pi’s are used all over the place.

However, the Pi itself is not specifically certified or rated for commercial/industrial applications. You as the system integrator are responsible for insuring compliance with whatever regulatory and safety standards, (UL, food and health, OSHA, EPA, etc.), that might be applicable.

There are vendors that make boards that the Pi compute module plugs into that are certified for more industrial applications.

If there are industrial certified Raspberry Pi’s, I have not seen them, at least not recently.

If you can provide greater detail about what you want to do, I can advise you better.

As far as thread-based programming is concerned, we need to know exactly what you are doing and exactly what errors you are seeing. Unfortunately, your original posting does not provide any specific detail about what you want to do.

1 Like

I don’t know much about the GrovePi+ But the DI_sensors classes implement a mutex already. You should follow that design pattern, even if you are not using the DI_sensors classes.

1 Like

I would be cautious about I2C on the GrovePi+ to work “24/7 like a proper industrial system”. I don’t have experience with the GrovePi+, but in my RaspberryPi powered robot some sensors produce both soft and hard I2C errors. I have an IMU sensor which uses “clock stretching” that produces soft errors about 10 to 15 an hour. One of my distance sensors produces random non-recoverable errors about once a month, requiring a cold boot to clear the I2C bus failure.

1 Like

Also the Pi was never intended to be a “24/7 industrial grade” device. It was originally designed to be a teaching tool, a bridge between the Arduino and “real” computing systems, an advanced controller that could run a tiny version of Linux that was cheap enough that people could grab a few and play with them.

Fortunately, (or unfortunately as the case may be), the Pi exploded beyond what anybody expected.

It was, (and still is), an educational tool, not a MIL-883 or DOD-2000 certified solution.

The fact that people have found commercial applications for it speaks well of it as a platform - but that wasn’t the original design goal.

So long as you understand what you’re working with, you shouldn’t have too many problems.

@cyclicalobsessive is the resource for more advanced programming on this beastie and anything he says is worth listening to.

1 Like

If you will be using more than one of any I2C sensor on a single GrovePi+ make certain the sensor bus address can be set to be different.

1 Like

See Power Limit, External Supply? - #2 by karan

And add up all your specific sensors’ power requirements.

1 Like

thanks guys, I didn’t expect such a participative forum, thanks a lot!

next thread will be about using robotics with rpi :smiley:


Since you have a RPi, and are interested in robotics, I encourage you to consider joining the participation here around running ROS 2 on the GoPiGo3 robot. (It takes $129+shipping investment for the basic robot.)


Allow me to heartily endorse this.

My 'bot Charlie who endorses this too.

IMHO, the GoPiGo is the most underrated robot on the market today. Here is what I had to say about it awhile back and it’s all still true except that they have a better rechargeable battery pack and the baseline O/S is GoPiGo O/S, if you want to start up relatively easy.


@cyclicalobsessive’s opinion on the 'bot:


And every word’s as true as gospel.

Though designed for classroom use, it’s low cost, versatility and ruggedness make it an ideal choice for anyone other than the most demanding DARPA-hound roboticist.

I have had mine for almost exactly four years now and I haven’t run out of stuff to play with, and that’s using the base software!

There is literally no end to the stuff you can do with it.

No kidding, there’s a posting somewhere here about a Ph.D. physicist who used a bunch of GoPiGo-3 robots to simulate the behavior of individual objects in a chaotic domain! It’s a lot easier to understand and visualize than a blackboard full of dry calculus equations.

And, even today, it’s still at a price-point of about $200 USD. The only things even close to that offered by ANYONE are micro:bit based 'bots.

Seriously, do it. You won’t regret it.


Charlie is very cute, indeed :slight_smile: talking about the advanced robotics I am seeking, just published a thread here (Need advanced robotics for RPI that do most of the job) in case you got some ideas

Thanks in advance

1 Like