Grovepi+ and Arduino Grove Shield Device Compatibility

grovepi
faq
tinker
odroid-xu4

#1

I’ve been working with the Grovepi+ and the Raspberry Pi but I’ve been looking at other boards similar to the Raspberry Pi. Has the Grovepi+ been tested or would it work with any similar devices that have the same 40 GPIO pinout as the Raspberry Pi? For example, the Banana Pi, Odroid XU4, Tinker Board, or the Pine64? Their 40-pin pinout is identical to the Raspberry Pi so I was hopeful the Grovepi+ would work with them but I wasn’t sure if there was something else within the hardware so that it will only specifically work with the Raspberry Pi.

I also saw that there is a grove shield for the Arduino, would that be compatible with any Arduino compatible devices such as the Udoo x86 Ultra?


#2

Hi @nickmiller1591,

We haven’t tested the GrovePi with other platforms such as:

  • Banana Pi

  • Odroid XU4

  • Tinker Board

  • Pine64

I’ve been looking over the web and I saw that the Banana Pi, Tinker XU4 and the Pine64 have the same pinout scheme as the Raspberry Pi's one.
The exception is the Odroid XU4, where I can see that the pins’ functionalities don’t match.

Even though these platforms can run the same Debian distro, we’re not sure if they are going to work - there may be some little differences that can make the board reset indefinitely or stop the system from booting up or anything (you never know for sure).

So, this would require some testing before it’s a sure thing.


As for the Grove Shield, it should work as long as the platform is Arduino compatible. But then again, we haven’t tested with such platforms.


Out of curiosity, what project are you thinking at?
It seems you’re trying to fly away from the Raspberry Pi environment.
What made you took this decision?


Thank you!


#3

Thank you for the reply, sorry I’ve taken so long to get back to you. So I’ve been working on a project for monitoring and securing network cabinets in a manufacturing environment. Some places where we have network hardware are not environmentally controlled as well as having a lot of dust and dirt in the air which we want to protect our equipment from. So we house the hardware in a cabinet with either an air conditioning unit attached or a fan kit. What I’ve been working on is using sensors to monitor temperature and humidity inside and out of these enclosures and if an A/C unit is in use then to monitor the temperature of its output into the cabinet. This is where the Pi and Grovepi board come into play with the sensors. I wish there was a Grove compatible relay that can switch at least 12V because the other part of the project is integrating electronic locks which require their own 12V power supply, so what I use for that is a separate Pi that connects to a relay through the GPIO and have a USB magnetic stripe card reader or RFID reader that acts somewhat like a keyboard to read a badge swipe/scan compare to an access list and then unlock the cabinet door handles for secure access. I also use a camera on each Pi with motion detection to record an activity in the cabinets as well(we’ve had some issues with non IT associates going in or breaking into our cabinets and making changes themselves).

I’m pretty happy with the Raspberry Pi environment though, it works very well so far. I’ve just been charged with working a DA to compare the Pi to other boards like it and really like the the Grove add on boards to make interfacing with sensors much simpler because I don’t have to solder or build circuit boards myself.

I am delayed for a bit in getting some of the boards mentioned above to test with so I can definitely post my findings once I get them as I am going to try and test them out with the Grove boards.


#4

Hi @nickmiller1591,


That looks like a complex and interesting project.
I personally like these kinds of projects.

Maybe you can share pictures with us of what you’re working on at the moment.
We (including myself) do like these kinds of story-like descriptions.


Also, Seeed already has a Grove Relay that can be connected to your GrovePi just fine.
Here’s a link to it: https://www.seeedstudio.com/Grove-Relay-p-769.html

What you need is to set the appropriate port for the Grove Relay and then actuate it with the digitalWrite function from within a Python script. That’s all.


Hope this helps you a bit in your project.

Thank you!


#5

I would share some pictures but the company I work for keeps a tight lid on any photos being taken and especially distributed across the internet.

I have tried the Grove Relay, but the problem with it is the terminal size for bringing in the wire from the electronic lock set, the wires just don’t fit.

If I can get my hands on some other Pi-like boards, I’ll post my findings.


#6

So I finally was able to get a Tinker Board and an Odroid XU4 to test with. I was able to install the GrovePi software to the point of being able to detect the GrovePi+ when issuing a i2cdetect -y 1 command. I attempted to test a temperature/humidity sensor, the DHT Pro. When I ran the python script it gave me an error:

Traceback (most recent call last):
File "sensor.oy", line 1, in <module>
import grovepi
File "build/bdist.linux-armv7l/egg/grovepi.py", line 64, in module <module>
import RPi.GPIO as GPIO
ImportError: No module named RPi.GPIO.

I understand this is designed for the Raspberry Pi and that is the wiringPi terminology, but wiringPi has packages for the Tinker Board as well as the Odroid. For example, on the Tinker Board, it just changes the import RPi.GPIO as GPIO to import ASUS.GPIO and GPIO.

The problem I’m having is locating this build/bdist.linux-armv7l/egg/grovepi.py file. In the ~/GrovePi/Software directory there is a “build” directory and then a “bdist.linux-armv7l” directory within it. But after that, there is no “egg” directory. I’ve been searching through the "GrovePi’ directory for a couple of days now with no luck. Since it seems like its no an issue of that file existing or being installed correctly, my question is with the import grovepi statement, where is that grovepi.py script supposed to be located so I can attempt to make adjustments on it to get either the Tinker Board or Odroid working with the GrovePi+?


#7

Hi @nickmiller1591,

The location of your packages depends on where python is installed - it totally varies from environment to environment.


In our case, the location of the grovepi module is going to be the path to the grovepi module/file that’s found in the repository.
So, if you download the GrovePi repo and then you run the install.sh script, the grovepi module you are going to use system-wide when you import it in a python script is going to be the grovepi file that’s found in the repository.


Looking at your ImportError you got, it seems like RPi.GPIO is not installed on your system and without it, you won’t be able to use the grovepi package. This makes me think the install command didn’t get through.

  1. Can you tell us what steps you have followed in order to get the grovepi module installed?

  2. Also, can you import the grovepi module after you run the sudo pip install RPi.GPIO and tell us if it worked?

Generally, if you want to quick-install the GrovePi, I would use the following command:

sudo curl -kL dexterindustries.com/update_grovepi | bash

Though, please be advised that we haven’t tested the GrovePi on other platforms other than the Raspberry Pi, so we are not sure if what you’re trying to do is going to work.


Thank you!


#8

I followed the installation instructions from your website, I believe I used the curl command you mentioned above but may have performed the longer version. I created a directory /home/pi in order for everything to load correctly since that is the default directory used by the install script. I do remember errors coming up about installing RPi.GPIO during that process but everything else seemed to install correctly.

I don’t believe I can even use RPi.GPIO since I’m trying to use a different board such as the Tinker Board or Odroid.

What I’m trying to do is locate the file grovepi.py that “import grovepi” is accessing when it gives me the import error no module RPi.GPIO because I could possibly edit that file, change “RPi.GPIO” to use “ASUS.GPIO” since that is the wiringPi terminology for Tinker Board.

It doesn’t seem to be a matter of that being installed incorrectly because the error isn’t that it can’t locate the file but that the grovepi.py script in that file location includes RPi.GPIO which I need to change.


#9

Hi @nickmiller1591,

So, everytime the curl install command is run, the GrovePi repo is cloned into /home/pi/Dexter/ folder. That’s where you will find the repository.

Now, the installer script doesn’t install the grovepi module in the classical way, like with python setup.py install or with a pip install command, but instead, it just adds a path to python so that the modules which are located in the repository can be imported.

You’re asking me where is the grovepi module located. On Debian Jessie, the grovepi.py file is located at /home/pi/Dexter/GrovePi/Software/Python.

If for some reason it didn’t get there on your system (which would be highly unlikely), you can also type in a terminal python -v (-v comes from verbose and is used for tracing the import statements) and then just hit import grovepi. Even if it fails importing the module, you should get a path that says where the grovepi module is found on your filesystem. Use that path so you can modify the source file.

Please tell us if this reaches a conclusion. I’m curious to see if that solves your issue.

Thank you!


#10

Thanks for the responses and assistance Robert. It seems like it won’t work with the tweaks I’ve made. I got as far as being able to run a script to read from the temperature/humidity sensor without error but could only receive “nan” values. So there is definitely something going on deeper in the code that is beyond my skill in order to get the GrovePi+ to work with a different board even if that board has the same GPIO pinout as the Raspberry Pi.

Is there any plans to build a Grovepi+ type board for different SBCs such as the Odroid or Tinker Board or any others?


#11

So I actually was making a small oversight. I thought I had ordered the DHT Pro, the white sensor but actually received the blue one. I hadn’t even given it a second thought while I was testing but when I changed the 1 to a 0 in my Python script for the blue sensor I started to get a reading on the Tinker Board. Now the problem is, I have 3 of them running on ports D3, D5, and D7 and when I print the values, they are all the same. It seems to give the D3 reading for all of them, when I hold that sensor in my hand to warm it up, all my printed temperatures/humidities go up with it. If I hold D5 or D7 in my hand though, no readings change. My script is below:

import grovepi
import time
import os
from datetime import datetime

sensorIn = 3  # Port D3
sensorOut = 5 # Port D5
sensorAC = 7 # Port D7

# temp_humidity_sensor_type
blue = 0    # The Blue colored sensor.
white = 1   # The White colored sensor.


datestr = time.strftime("%Y-%m-%d")
timestr = time.strftime("%H:%M")
datetimestr = time.strftime("%Y-%m-%d %H:%M:%S")
try:

        
        sensorIn = 3
        sensorOut = 5
        sensorAC = 7
        blue = 0
        white = 1
        datestr = time.strftime("%Y-%m-%d")
        timestr = time.strftime("%H:%M")
        datetimestr = time.strftime("%Y-%m-%d %H:%M:%S")
	# This example uses the blue colored sensor. 
	# The first parameter is the port, the second parameter is the type of sensor.
	tempInF = 0.0
	tempOutF = 0.0
	humIn = 0.0
	humOut = 0.0
	tempACF = 0.0

	#print(datetimestr)
               
        [tempIn,humIn] = grovepi.dht(sensorIn,0)  
        #print("tempIn = %.02f C humIn =%.02f%%"%(tempIn, humIn))
        time.sleep(.2)
        
        
        
	
        [tempOut,humOut] = grovepi.dht(sensorOut,0)  
        #print("tempOut = %.02f C humOut =%.02f%%"%(tempOut, humOut))
        time.sleep(.2)
       
        
	
        [tempAC,humAC] = grovepi.dht(sensorAC,0)  
        #print("tempAC = %.02f C humAC =%.02f%%"%(tempAC, humAC))
        time.sleep(.2)
        
        
        tempInF = tempIn * 9.0 / 5.0 + 32.0
        tempOutF = tempOut * 9.0 / 5.0 + 32.0
        tempACF = tempAC * 9.0 / 5.0 + 32.0
        print tempInF
        print humIn
        print tempOutF
        print humOut
        print tempACF
                
	
        

except IOError:
        print("Error")

#12

The GrovePi still will not work on the Odroid XU-4. I may have fixed the issue above by extending the timeout between sensor readings to a whole second, I’m not sure why I would need to do that but I am at least able to increase the temperature around each sensor and see the changes and increasing the temperature on the firs sensor doesn’t affect the other 2 sensor readings…any insight into that would be appreciated as to why I would even need to extend the timeout between readings.


#13

Hi @nickmiller1591,

I’ve been looking at the source code of the GrovePi's firmware and it does like it supports the use of multiple DHT sensors at the same time.
Let me contact the original developer of the firmware and see what he has to say about this issue. I’ll be back with an answer as fast as I can.

During my missing period, did you find anything else we could use?

Thank you!


#14

Yea, I’ve used it with multiple DHT Pro sensors before with the Raspberry Pi and GrovePi. I was able to get the GrovePi working with the Tinker Board and it was giving me readings, the issue I have is that the Tinker Board seems to need a larger timeout between reading each sensor or else it will output the same reading for every sensor as if it was just reading from one and printing it out multiple times. Probably something unique to the Tinker Board’s I2C communication.


#15

Hi @nickmiller1591,

I’ve tried to dig a bit more into this issue and I haven’t got anywhere with it mainly because I don’t have a Tinker board to test on in the first place.

I think it has to do with how I2C works on Tinker, because otherwise, it wouldn’t work on the RaspberryPi too. If I were in your situation, I would test each instruction found in the source code while analyzing the I2C signal with a logic analyzer until I’d find the issue.

Or you could reach someone on Tinker's forum who got into something similar.

Thank you!