Hi!
I’m experimenting with the Raspberry Pi4 + GrovePi + Ultrasonic ranger and i’m facing an issue with the output of the Ultrasonic ranger. Whenever I start the python script, there’s no output and no errors given. I’ve uploaded the logs from the troubleshooter and a screenshot to see the issue.
Other devices like the LEDbar or the buzzer are working, but the ultrasonic ranger isn’t 
.
I followed this guide:
So any suggestions are welcome and hopefully we can fix the issue 
log.txt (3.0 KB)
Is the Grove Ultrasonic Ranger plugged into D4?
When you press ctrl-c, where does it say it was when the keyboard exception is detected?
what is the output of:
cat /etc/os-release
I do not know anything about GrovePi, but it is interesting that you have lots of I2C devices plugged in, and the grove_ultrasonic.py which does not use I2C first sets hardware I2C.
Have you tried:
sudo python grove_ultrasonic.py
Have you tried running grove_ultrasonic.py as the first test after a cold boot?
Are you sure the Pi4 8GB is compatible with the GrovePi+?
Thanks for your reply!
I will test your suggestions in the next 2-3 days and share the outcomes with you .
Is the Grove Ultrasonic Ranger plugged into D4?
When you press ctrl-c, where does it say it was when the keyboard exception is detected?
pi@raspberrypi:~/GrovePi/Software/Python $ sudo python grove_ultrasonic.py
^CTraceback (most recent call last):
File "grove_ultrasonic.py", line 49, in <module>
print(grovepi.ultrasonicRead(ultrasonic_ranger))
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 299, in ultrasonicRead
number = read_identified_i2c_block(uRead_cmd, no_bytes = 2)
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 242, in read_identified_i2c_block
data = read_i2c_block(no_bytes + 1)
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 232, in read_i2c_block
raise KeyboardInterrupt
KeyboardInterrupt
Output of cat /etc/os-release
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Have you tried this with no other sensor attached?
Are any other GrovePi example programs running when you tried grove_ultrasonic.py?
What happens if you copy the grove_ultrasonic.py program and comment out the line that sets the I2C bus to hardware I2C?
pi@raspberrypi:~/GrovePi/Software/Python $ sudo python grove_ultrasonic.py
65535
65535
65535
65535
^CTraceback (most recent call last):
File "grove_ultrasonic.py", line 49, in <module>
print(grovepi.ultrasonicRead(ultrasonic_ranger))
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 299, in ultrasonicRead
number = read_identified_i2c_block(uRead_cmd, no_bytes = 2)
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 242, in read_identified_i2c_block
data = read_i2c_block(no_bytes + 1)
File "/home/pi/GrovePi/Software/Python/grovepi.py", line 232, in read_i2c_block
raise KeyboardInterrupt
KeyboardInterrupt
pi@raspberrypi:~/GrovePi/Software/Python $
sudo python grove_ultrasonic.py
Have you tried running grove_ultrasonic.py as the first test after a cold boot?
Are you sure the Pi4 8GB is compatible with the GrovePi+?
Website says:
Compatible with Raspberry Pi model B/B+/A+/2/3/4
But i’m not sure if it’s compatible.
Conclusion
I will google about the “65535” output and see if more people have this issue.!
@CapibaraChris I took a read through the grovepi.py to understand the GrovePi+ a little better, and see that everything happens via I2C commands between the Raspberry Pi and the GrovePi+ ATMEGA 328 (Arduino) controller, which explains why the keyboard interrupt always happens in an I2C operation. It is trying to read the ultrasonic distance value from the GrovePi+ via I2C regardless of using hardware or software I2C.
Software I2C supports clock stretching which somehow returns a value, (albeit not a useful value), where hardware I2C does not.
The troubleshooting log shows that your RPi4 is seeing all your I2C sensors.
Everything that is and is not happening is inside the Arduino. It is perhaps telling that your log file from the troubleshooting script stopped when checking for the Arduino firmware version. This should have returned a firmware version of 1.4, I think.
@jimrh once reported something about a RPi4 messing up the Arduino firmware update in the GoPiGo3 robot which uses the same Arduino but different firmware.
I didn’t pay enough attention at the time because I only run RPi3B and RPi3B+. He documented how he “recovered” the Arduino to proper operation using a RPi3.
I have reached the limit of my abilities in your situation. If you bought the board from ModRobotics, I suggest that you run the troubleshooter again to get a latest log and send it with a summary of your situation to support@modrobotics.com as well as watch for Jim to comment on your situation. I believe he is best able to help you.
(If you bought the board from someone else, I do not know who is the official support. I really have not followed the GrovePi, GrovePi+ generations. It started out as a DexterIndustries kickstarter I believe, then Seeed continued its life, and then ModRobotics bought DexterIndustries, so I don’t know who all the players are today.)
If indeed the issue comes down to have been due to using a RPi4, I really hope the GrovePi+ website will get a warning about using RPi4. Just my suspicions talking - sorry if this is not the problem.
I have to confess I am puzzled too, though I have been busy this last few days wasting time running down rat-holes due to crappy hardware - my microSD to USB “dongle” adapter. . .
. . . decided to go all pear-shaped on me and so I inadvertently generated a bunch of trash images that I’ve been testing against. Tomorrow I go out and get another adapter that actually costs some money and isn’t a piece of GAGH!
Regarding the “Pi-4 nukes a GoPiGo-3 board” issue I described.
The only similarity between the two is that they both use the same processor family. In the case of the GoPiGo-3 controller board, Dexter Industries actually brought out a couple of pins, specifically the SWDIO and SWDCLK on GPIO physical pins 18 and 22, to use as a “sideways” JTAG interface where the Raspberry Pi could upload firmware updates to the 'bot.
As far as I know, (and my knowledge here is quite limited), I do not believe that the ability to update the Grove-Pi firmware was ever implemented. (I also don’t have any schematics or other Grove-Pi documentation either.)
Even if that DOES exist, enabling that interface isn’t a simple task.
I would need to do a lot more research before I’d point my finger at that as a root cause.
I found this:
Here’s a schematic:
GrovePi+ v3.0.pdf.txt (75.7 KB)
There’s a bunch of other, interesting, data on that site too.
There does not appear to be any provision for any kind of JTAG connection for flashing firmware, though there are SPI and i2c connections.
Based on my (very) quick look at the schematic, a Grove Pi is nothing more than a level-shifting interface multiplexer board. I think SparkFun has something similar that uses their Qwik connector format.
I guess I am at a loss too.
Have you tried this ultrasonic device on anything else?
Is this for 3v or 5v i2c?
I’ll be happy to take a closer look, but it won’t be for a couple of days or so.
=====================
Update:
Apparently the GrovePi can have it’s firmware updated!
(Item 6 on the page above)
What I would try:
Important caveat:
You now know everything I know about the GrovePi. 
I’m looking forward to messing with it, but there’s a bit on my plate just now.
From the DI GrovePi Git:
To update the firmware to the latest version (Currently version 1.4)
cd /home/pi/Dexter/GrovePi/Firmware
sudo bash firmware_update.sh
It seems to do it all over the GPIO somehow:
#!/usr/bin/env bash
update_grovepi_firmware(){
avrdude -c gpio -p m328p -U lfuse:w:0xFF:m
avrdude -c gpio -p m328p -U hfuse:w:0xDA:m
avrdude -c gpio -p m328p -U efuse:w:0x05:m
avrdude -c gpio -p m328p -U flash:w:grove_pi_firmware.hex
}
Thanks for all the thoughts and suggestions.
This is my first Raspberry Pi4 & GrovePi so i’m new to all of this .
I have tried to install the Raspbian for Robots 2019-12-19, but it didn’t work because the Pi4 told me that I needed a newer OS version (or something like that, didn’t pay that much attention).
Firmware Update & Version
(tflite1-env) pi@raspberrypi:~/tflite1 $ cd /home/pi/Dexter/GrovePi/Firmware
(tflite1-env) pi@raspberrypi:~/Dexter/GrovePi/Firmware $ sudo bash firmware_update.sh
Updating the GrovePi firmware
=============================
http://www.dexterindustries.com/grovepi
Run this program:
sudo ./firmware_update.sh
=============================
Do you want to update the firmware? [y,n]y
Make sure that GrovePi is connected to Raspberry Pi
Firmware found
Press any key to start firmware update
. . .
gpio/direction: No such file or directory
avrdude done. Thank you.
gpio/direction: No such file or directory
avrdude done. Thank you.
gpio/direction: No such file or directory
avrdude done. Thank you.
gpio/direction: No such file or directory
avrdude done. Thank you.
(tflite1-env) pi@raspberrypi:~/Dexter/GrovePi/Firmware $ ls
Archive grove_pi_firmware.hex new_fw_search.sh Source
firmware_update.sh grovepi_firmware_update.sh readme.md version.txt
(tflite1-env) pi@raspberrypi:~/Dexter/GrovePi/Firmware $ cat version.txt
1.4.0
(tflite1-env) pi@raspberrypi:~/Dexter/GrovePi/Firmware $
Additional Information
This is the GrovePi:
We’re building upon the “PiRacer”
I will continue to work on the project and update this post .
Interesting, I asked on Amazon
Might that be sensor fusion for human detection/disambiguation?
There was a thread a year ago on this:
The thread does not include a work-around.
As far as updating firmware on the GrovePi is concerned, I would want to do a bit more research there before recommending it as a general practice.
Important Caveat:
As far as I know, and please understand my knowledge is limited, the software that updates the firmware on things like the GoPiGo and the Grove-Pi, (et. al.), was written back when things like the Pi-4 weren’t even a gleam in their daddy’s eyes yet.
The operating system and underlying libraries have made tremendous advancements, however I do not know if the specific firmware flashing utilities have been updated to keep up with the rest of the software.
One of the nice things about boards like the Arudino is that they have a native two-step boot process where the first step is a “gakekeeper” kind of step that determines if you are loading software, (i.e. a “sketch” or whatever), or do you want to update the device’s firmware.
If you’re updating the firmware, this first-step of the process takes the data you start sending and acts like a built-in JTAG adapter and flashes the internal device firmware in such a way that it’s really difficult to TOTALLY “brick” the device.
The GoPiGo, Grove-Pi, (etc.), use a lower-level approach where the Raspberry Pi runs software like avrdude - that then bit-bangs the appropriate firmware.
The “Arduino” way is vastly superior because the boot-loader firmware is intimately associated with a particular processor and board family.
The “GoPiGo” way is more flexible, but with flexibility comes complexity and with complexity comes a vastly increased chance for error.
========================
The bottom line is that significant research needs to be done on the Dexter Industries firmware updating software before I would trust it out of my sight.
Unfortunately, as important as this is, I don’t have the time to dedicate to a research effort of that magnitude right now. Later? Absolutely! When? I have no idea.
With regard to messing with the firmware, the best advice I can give is this:
. . . . unless you know how to handle venomous beasties well enough not to get bitten.
