Ping 1D and Cockpit standalone version

Haven’t been able to get Ping1D to work with the windows standalone version of cockpit. Works fine with the browser-based Sonarview extension but Ping1D device doesnt appear when using Sonarview via an iframe window in the stand alone version of cockpit.

The Cerulean Omniscan Sonar which I also have installed works fine via iframe so wonder if there are some settings I need to check for the Ping1D?

Offhand I don’t know the issue, but let’s get to the bottom of this!

Can I see a screenshot of what you see in SonarView Discovery? for both the Ping1D and Omniscan?
What’s the URL in your browser bar when opening cockpit in the browser?
In SonarView, when you click the gear icon to go to App Settings and select “SonarLink and Discovery Options”, are these different between the Windows standalone version versus the browser-based version of Cockpit?

2 Likes

Thanks Dan I use the blueos.local url when running cockpit frome the browser (Chrome) but havent been able to replicate actually seeing the Ping1D device coming up in the browser versuion now.

So essentially looks like I cannot see the Ping1D device regardless of whether I use the browser version of Cockpit or the standalone.

Below are screenshots that shows Ping1D does seem to be connect but I just have no way of displaying it. Any help much appreciated!


.

So just to clarify - I can display the Omniscan fine in the Cockpit stand alone version but not the Ping1D device. It doesnt appear in the device discovery but appears to be connected to blueos as in the image below.

Also discovered today that I cannot save logfiles in the Cockpit version? Usually I just select record and it saves it to the path identified in the last screen shot above. In the manual it says this folder should be in the ‘home’ folder. I have tried adding that folder to everywhere that could be ‘home’ on a windows pc (root, user folders documents etc) to no avail. Doing a global search can locate no files with the ‘.svlog’ extension used in the browser version of Sonarview.

Hi @BillyBudd -
Omniscan logs can be found with the File Browser, under user data / sonarview.

As for Cockpit - what logfiles are you referring to?

1 Like

Many Thanks @tony-white - was refering to the Sonarview log files for the stand alone version of the cockpit which I thought was were stored on the topside computer for some reason. Have only used the Cerulean version of Sonarview previously and forgotten that I needed to enable pirate mode and use the file browser extension but the link for the Blueboat guide you provided had the info I needed (and more!).

tldr: I recommend you change the Vehicle IP address to 127.0.0.1.

I think the issue is a poor interaction between the “Vehicle IP address” and BlueOS networking setup. While BlueOS is reachable from outside via the blueos-avahi.local domain name, it’s not reachable from within BlueOS at that domain name.

Confusingly (even to me), the Sonarlink and Discovery Options Server field is resolved from your browser, whereas the “Vehicle IP address” field is resolved from within the docker container.

From outside blueos (on a linux computer or on the Raspberry Pi outside docker), you can list all hosts advertising their address (install with sudo apt install avahi-utils).

$ avahi-browse -at

Trying this from inside blueos shows that it can’t reach the avahi daemon:

$ docker exec -it blueos-core bash
Failed to create client object: Daemon not running

Thanks Dan but you’ve totally lost me here? - If the issue was the Vehicle IP address why would the Omniscan work via Sonarview in BlueOS but not Ping1D? Also wouldnt changing the vehicle IP address mean BlueOS would fail to connect?

you’ve totally lost me here

That’s fair - this is confusing!

If the issue was the Vehicle IP address why would the Omniscan work via Sonarview in BlueOS but not Ping1D

Omniscan works via the discovery protocol (which broadcasts out a discovery message over the local network), whereas Ping1D is using the “Ping Manager” which is published at http://YOUR-VEHICLE-ADDRESSS/vehicle/pings. So in order to find such a device, the vehicle has to be reachable at that address.

Also wouldnt changing the vehicle IP address mean BlueOS would fail to connect?

No. In SonarView App Settings, the “Vehicle IP address” field means “how do we reach BlueOS (including mavlink2rest and the Ping device serial-to-UDP relay) from the SonarLink service?”. Changing this value will not affect your ability to reach the BlueOS or SonarView GUI in the web browser.

An address starting with 127 (typically 127.0.0.1) means “the same machine I’m on”, so it will work here. It would also work to put the vehicle’s own hostname (e.g. blueos).

It DOES NOT work to put a mdns address (e.g. blueos.local. or blueos-avahi.local.) though I believe it should (I submitted a bug report at bug: blueos does not use mdns · Issue #2902 · bluerobotics/BlueOS · GitHub).

Thanks for clearing that up Dan! - I changed this as suggested (see below) but the Ping1D still doesnt show up on Sonarview discovery. In fact changing the vehicle IP address didnt affect the Omniscan as was still detected fine so not sure what this setting does?

Also I installed the latest version of PingViewer and confirm that the Ping1D works fine here - uses a udp address (think it was 192.168.2.2:9090).

With Omniscan, we discover the IP address dynamically, so you’re right that it disregards that field - that’s no indication that it won’t work. If you can assure that the vehicle has static IP address 192.168.2.2, then you should be able to use that instead of 127.0.0.1.

If neither 192.168.2.2 nor 127.0.0.1 work, then please send me the logs from SonarView on BlueOS so I can check out what’s going on.

2 Likes

Thanks Dan - Tried 192.168.2.2 as the vehicle address in Sonarview Discovery
with no luck. Have attached the last couple of Vehicle logs as well as a couple of logs from the Ping1D running on Pingviewer. Attached a screenshot which seems to show the vehicle has a static IP 192.168.2.2. The screenshot shows the network is connected on eth0 but not usb0. I’ve always wondered what usb0 is for - do I need to have that connected?

00000038.BIN (19.7 MB)
00073-2024-09-19_22-19-53.tlog (14.0 MB)Processing: 20240920-102939269.bin…
20240920-103129757.bin (764.6 KB)

In the previous screenshot, I see you put in 172.0.0.1 instead of 127.0.0.1 so try that one again. In the latest screenshot, I can see that it’s not successfully getting positional data from MAVLink.

The logs I need are from the extensions screen (extensions manager → installed → SonarView → view logs).

thank you for your patience!

1 Like

OK - will try and thanks for your patience too!

Hi Dan

Tried again with 127.0.0.1 (see attached screen shot) but the Ping1D still doesnt show up in discovery. I looked at the section you advised (extensions manager → installed → SonarView → view logs) but this only brings up a terminal window is there some way to extract logs from here? The previous logs I sent were extracted in pirate mode using the file browser from userdata/Sonarview/Omniscan450.

Hi Dan - not sure if you saw my earlier response to your suggestions but appreciate any update on this issue if you are still following this?

Hi Dan - not sure if you saw my earlier response to your suggestions but appreciate any update on this issue if you are still following this?

Yes! I’m sorry I didn’t notice you responded.
@tony-white could you please unmark this thread as solved?

I looked at the section you advised (extensions manager → installed → SonarView → view logs) but this only brings up a terminal window is there some way to extract logs from here?

Is there anything in that terminal window?

Unfortunately, I don’t think there’s a way to easily download the logs from that window. New logs should stream as text on that terminal window but it may or may not work.

Here’s the other way.

Navigate your web browser to http://blueos.local:9134/v2.0/list_containers and look for something that contains the words “sonarview” and the “name” field. It should be something like (maybe exactly) "/extension-nicknothomsonarview1100".

If that’s what it is, then go to the following URL (if the name is different, adjust this URL accordingly):

http://blueos-dan.local:9134/v2.0/log?container_name=/extension-nicknothomsonarview1100
1 Like

@BillyBudd Were you able to trace those logs? Got a moment to hop on the phone and figure this out?

1 Like

@o.o Yes Dan be great to chat if you’ve time. I’m in Sydney Australia (GMT +11 hours) but just email me (buddbill@gmail.com) to get my number/whatsapp.

The terminal window does stream text (once Sonarview is started!). Have attached screenshot and also txt file with the output captured.


sonarview log.txt (23.1 KB)

Also not sure if its relevant but tried enabling serial devices in Sonarlink and discovery options (attached screen shot).

This made no difference but when I look at ‘Ping Sonar Devices’ on the blueos main page it shows a UDP 9090 bridge for the Ping1D but when I look at ‘Serial Bridges’ it says no bridges available.

Perfect! That text file tells me exactly what I need to know.

  • SonarLink is trying to connect to the vehicle at blueos-avahi.local but can’t. Please use an IP address for the “vehicle IP address”. Either 127.0.0.1 or 192.168.2.2. blueos-avahi.local will definitely not work there, even though it works for the “Server” field.
  • I don’t think Ping devices show up in “serial bridges” interface. At least they don’t for me. So that’s expected. I think the “serial bridges” interface only shows devices that you’ve manually created a tunnel for.
  • “Enable Serial Devices” in that settings page is not necessary and doesn’t work on BlueOS. But it’s not interfering with anything either.
1 Like