I have a Ping1D connected to a Raspberry Pi 4 through the Serial connection on the Navigator HAT inside a BlueROV2 Heavy. The Raspberry Pi is running Version 1.1.0-beta.9 with V3.26 on the Ping1D.
The Ping1D is confirmed working as it can communicate with PingViewer, QGroundControl, and it is displayed in the “Pings” page of the companion application. However, when I try to run the following Python example code to talk to it, the software says the Ping1D object failed to initialize. It does not throw an IP address error, suggesting the communication to 192.168.2.2:9089 is open, but the Ping1D is not responding correctly. I have tried this communication both with PingViewer running and not.
from brping import Ping1D
import time
myPing = Ping1D()
#myPing.connect_serial("COM4", 115200)
# For UDP
myPing.connect_udp("192.168.2.2", 9089)
if myPing.initialize() is False:
print("Failed to initialize Ping!")
exit(1)
# set the speed of sound to use for distance calculations to
# 1450000 mm/s (1450 m/s)
myPing.set_speed_of_sound(1450000)
while True:
data = myPing.get_distance()
if data:
print("Distance: %s\tConfidence: %s%%" % (data["distance"], data["confidence"]))
else:
print("Failed to get distance data")
time.sleep(0.1)
Is there an issue within BlueOS with creating the Serial to UDP bridge that breaks the Ping-Python interaction? For this particular project, we need to be able to access the Ping1D independently of PingViewer or MAVLink, especially because we need to be able to change configurations.
Generally a Ping1D should be at port 9090, not 9089, unless you have multiple connected. Is 9089 what’s showing up in Ping Viewer?
On the “IP address error” point, the code will happily ‘connect’ to any reachable subnet, but will throw a ConnectionRefusedError once you actually try to do something (e.g. initialise, get/set a value, etc) if the connection is invalid (i.e. there’s nothing talking back). I get that error if I try to initialise on port 9089, so it’s interesting that you apparently don’t.
That doesn’t seem possible because the code you posted has the Failed to initialize section commented out. Assuming that code is not actually commented out in the program you’re running, if there is a recognisable ping device of the correct type then initialize() should return True. False is returned if there is something at the other end of the specified UDP connection, but that is not behaving like the expected device (e.g. a different type of ping device, or a camera stream, etc).
Not that we’re aware of - the normal code works well for me when making a valid connection
Thanks for the reply Eliot. To your first point, 9089 is the UDP bridge port specified by BlueOS in the “Pings” page on the web dashboard. It works, so I don’t question it
I commented that out for testing and failed to uncomment when submitting this, I will edit the OP accordingly. The interesting thing is that the the PingViewer application is able to connect to and talk with the Ping1D at 192.168.2.2:9089, but the Python script always fails. In theory, there should be a valid Ping1D device at the end of that port.
Thinking about it more, this problem may be related! PingViewer is actually unable to change the settings of the Ping1D when connected. We can see the data come in, but modifying the speed of sound, emit rate, and other parameters does not seem to do anything. That is the secondary reason though.
I’m not certain what’s going on, so I’ve brought it up internally, but my guess is the unexpected port is related somehow. Can you download the latest log for the Pings service and provide it here?
Go to the var/logs/blueos/services/ping in the File Browser
Sorry for the delay, just now circling back around to this thread.
Fired up the BlueROV2 just now and the “Pings” page is reporting that the Ping1D is now broadcasting at port 9090, as expected. Still no dice on getting a good connection from Ping-Python or Ping Viewer.
Attached is the log file from this recent test run. Please let me know if there’s anything I can do or try.
That seems like a potentially positive start, at least.
And that’s less positive.
I just had a look through this and it seems like there’s an issue with our Ping service that is falsely detecting your device despite not properly being able to communicate with it, after which it keeps the connection around and just repeatedly tries (and fails) to request distance measurements and reconnect every so often.
It does seem to have detected the firmware at the start though, and your Ping Sonar is apparently on v3.26.0, which is a few behind our latest recommended version. BlueOS does not yet have the ability to update a Ping device’s firmware, so I’d recommend you connect your Ping Sonar directly to a computer running Ping Viewer (via USB), and follow the update process, which should improve its performance, and will also hopefully allow it to connect properly to BlueOS
I would recommend making sure you’re on the latest Ping Viewer version before trying to update the firmware, as there were some issues with an earlier version. Also make sure to select the highest for the firmware (currently 3.28_auto) - it may not be the first option in the dropdown.
Eliot, you’re gonna love this. I have tried two Ping1Ds, two different USB-UART converters (including a BlueRobotics 1st party BLUART adapter), and three different versions of Ping Viewer an still cannot talk to these sensors over PingViewer or python! I have tried all of the setups at 9600 baud and 115200 baud. I have also switched TX/RX multiple times, just to be sure. I cannot update to the newest firmware because PingViewer cannot detect the sensor to upload the code.
However, the Arduino 1D example works like a charm for both of them. When I go through the Arduino, its perfectly content spitting out values. That example works at 9600 baud for both. I am stupefied. Is there any data I can send your way that would be beneficial to try and track this down??
The sonars themselves are at least able to communicate and send profiles
They’re confirmed to be working with an Arduino, and were detected by BlueOS
It’s unlikely to be the USB-UART conversion
You’ve tried two converters
It may be the USB cable
Although that’s unlikely if you used the same cable and the device was being detected by the BlueOS Pings service
It’s unlikely to be Ping Viewer itself
You’ve tried multiple versions
It may be the computer you’re running Ping Viewer on
If you’re connecting directly to the sonar via USB then it may be missing FTDI drivers, or could have a problem with the USB port you’re using
If you’re connecting via BlueOS then your computer may have a firewall or network settings configured that aren’t allowing the UDP connection from the BlueOS Pings service
that’s still a potentially poor explanation though, because for ping profiles to be received the communication has to be working in both directions
Given the Arduino code was apparently working, are you able to try changing the settings there, and confirming that it was successful (speed of sound may be easiest to verify, as the distance estimates should change - try setting 343 mm/s (for air)).
It’s also still very confusing that Ping Viewer and ping-arduino can (or could?) seemingly talk to the sonars, but ping-python apparently can’t make a connection…
It might be helpful to send a Sensor log from Ping Viewer?
We were able to finally talk to one of the Ping1Ds over Python. It turns out both of the USB-UART converters we used were bad (including the BlueRobotics one). When we used a third, one of the Ping1Ds immediately started talking to Ping-Viewer but the other didn’t. It could be a bad splice in its connections as even in the Arduino example it was inconsistent - we will investigate that further on our end.
So we were able to do a firmware update to the working on and talk to it over Python. All is well now, even though it has taken months of running around in a circle.
For future reference, is there anyway to attempt a firmware update without going through ping-viewer?
Hmm, that’s a bummer. I wonder if the poorly working sonar perhaps ended up damaging the converters.
Ping Viewer comes bundled with the program it uses for flashing firmware. Basic instructions for using that to manually flash on a firmware are provided in the Device Recovery section
