I have had my Ultrasonic working fine, but then it stopped working. Now it only shows the same value 680. I have tried different digital ports and restarted everything, but still nothing worked.
Any idea? Is that possible that the sensor got broken? I handle them very carefully always.
Thanks John for replying. Strangely it is now working again. I donāt recall anything that I have done besides plugging everything out and in again and reboot it.
I got a new GoPiGo2 starter kit a few days and Iām having the same problem that was originally reported by mmansur: The ultrasonic sensor was working in a the basic example, then I tried it a little later after a reboot and it stopped working. When I test with basic_test_all.py and the āuā command, values near 684 (+/- 1) are always returned, no matter how far away the obstacle is.
Since mmansur said the problem went away when reconnecting, I powered off, unplugged the senorās cable on both ends, waited a minute, plugged it back in, and tried again, but the behavior didnāt change.
karan, thanks for your reply. I just tried running that test and it repeatedly prints Error.
Iām surprised that a GrovePi program would work with the GoPiGo. Note that on the GoPiGo the ultrasonic is connected to port A1, but this program mentions D4. Iām just starting, so Iām probably confused.
In case this gives you a hint, I should also mention that even before it stopped working, it was working a little strangely. After first connecting it I tried the obstacle-avoiding example, and although it did stop before hitting an obstacle, it stopped at greatly varying distances from the obstacle ā from 1 in to 2 ft. I only ran this program a few times, then shut the GoPiGo off, then later tried it again and thatās when it stopped working completely.
Hey @mark1: Can you follow this tutorial to generate a log for the GoPiGo and upload the log here. Can you also upload a screenshot of your setup and a closeup of your connections.
Hey @mark1 ,
It really looks like your the sensor is broken since everything else looks good. We have not seen a problem like this before. Thanks a lot for testing it out. Iām really sorry for the frustration.
Can you contact us here, under āGeneral Questions and Feedbackā and we will have a replacement shipped to you immediately.
Again, Iām really sorry to hear about this; weāll make it right immediately.
Do let us know how the new sensor works for you when you get it.
-Karan
Thanks for you help Karan. I filled out the form, and when I press Send it does itās little animated dance, but then there is to āmessage sentā confirmation ā hope this is normal.
Karan, thank you for sending a replacement. However, it is not working either, so perhaps the problem is in the GoPiGo board?
When I test with grove_distance_sensor.py, it always prints 0 as before. When I test with basic_test_all.py and the āuā command, it always prints 690 or 691.
@mark1,
That is kind of puzzling, we have not seen the GoPiGo and the ultrasonic sensor behave like that before. Can you try downgrading the firmware to version 1.5 by running the firmware update script here.
Make the script executable:
sudo chmod +x firmware_update_15.sh
then run it:
sudo ./firmware_update_15.sh
and try out the basic_test_all or this example with the correct pin number.
I am currently dealing with the same problem here. Donāt know whether I should make another thread or just reuse this one. My setup is a Raspberry Pi with the GrovePi+.
Running the grove_ultrasonic.py script always returns values of 670. It is the version 2.0 of the ultrasonic sensor that I have but I believe from reading other posts that should not make a difference. Executing a flow in Node-RED reading the same ultrasonic sensor gives me the same value.
Itās better for posting it here. It makes sense since itās the same issue. Another topic would be redundant and no one likes duplicates.
Thank you for thinking about it.
Thank you for the quick reply. After I, a day later, booted the Raspberry Pi in order to do the things you suggested, the sensor seemed to be working. This is really strange as nothing has changed to the setup. Could it be possible that there was interference from other devices? I donāt see any difference with the way I ran things yesterday.
Anyways, it seems to be okay now. In a little while I will try to test it in the real environment. Hopefully it is still functioning there.
The readings should have fluctuated provided there were bad contacts, interferences, etc. At least, thatās how Iām thinking.
Itās weird the values consistently stayed at 670.
Without more feedback, I canāt tell what was the reason for it to behave this way.
Please let us know how is going to work the following days.