I have Ping Sonar Echosounder connected to Raspberry Pi 3B+ via USB over TTL/USB adapter.
PingViewer shows measurements without issues.
QGC shows “Rangefinder” value from Ping with lag and momentary losses.
Companion->System interface shows status: 55degC, “Throttled” and “Currently Under-Voltage”, CPU Load: %90-100. (When Ping Sonar Echosounder is not connected status is allways “OK”. CPU Load:50)
I have measured 5.03Vdc for RasPi and 0.07-0.12Adc to Ping1D but I cannot measure the transients.
I think the lag while updating RangeFinder value on QGC is caused by throttling or under-voltage status of RasPi. How do you think I can resolve this problem?
Please open a terminal on the raspberry pi by visiting http://192.168.2.2:8080. Type the command dmesg -w and show us the output. This will tell us if the ping is causing any problems on the usb bus.
Is this a BlueROV2, or a custom build? When did you purchase your ROV? We’ve updated our 5V supply for the Raspberry Pi, which you should get if you’ve got one of the previous models.
Do you have anything else connected to the ROV? I’m curious why you are running ardusub 4.1.0, unless you also have a waterlinked DVL attached.
I realized that heat is causing throttling, and throttling causing clock frequency down to 0.6MHz, frequency down causing processing load to increase and this causing lags and drops mavlink telemetry packages probably due to unprocessed services.
As a solution I have put some heatsink on RasPi and changed RasPi settings so that frequency does not drop to 0.6MHz. This seems to have solved this problem for now.
I am using Ardusub v4.1.0 because it supports LUA scripting.
If I keep the Ping 1D connected, the Companion CPU load increased within a few minutes after booting to more than 100% and the BR is no longer maneuverable (more than 30 secs delay on the companion side in receiving commands from topside). Terminal messages seem to indicate (http://192.168.2.2:8080) that the boot process doesn´t conclude (bcm2835-v412: error 0 waiting for frame completion; see oldBEC_withPing.pdf attached). The Ping itself, gives reasonable readings. Even with the new BEC, the system shows the same behavior (newBEC_withPing.pdf).
(Dis-)connecting the Waterlinked GPS doesn’t have any effect.
If I disconnect the USB cable from the Ping 1D BLUART USB to TTL Serial and RS485 Adapter, the system works well, and CPU load is around 50%. The booting sequence ends with “random: cnrg init done” (attached: message_end_noping.png, attached).
I tried to update the Ping 1D firmware using the new PingViewer version 2.2 but run into new problems. The automated update returns: “It’s only possible to flash via serial.” And the Ping communication / update procedure freezes (Ping_firmware_update_auto1/2.png). The manual update doesn’t work either. So I cannot update the Ping.
As I am currently supposed to map coral in Curacao and already lost one week of two trying to get the BR2 operational, I am running out of options. I really do need the altimeter. Any thoughts how to make it work?
I got the following hardware:
BR2 (rev 1, I suppose, bought in 2016)
Ping1D Echosounder Altimeter (bought in 2019) with Firmware v3.26
New BEC 5V 6A Power Supply
PingViewer v2.2.0
WaterLinked UnderWater GPS G2
Companion Computer Firmware v0.0.26 with heat sink and small fan (disconnecting the fan, doesn’t solve the problem, either).
That’s definitely not normal, and indicates something is going wrong.
bcm2835-v4l2 is a Raspberry Pi kernel module that allows v4l2 (video-for-linux-version-2) to work, so that USB cameras can be connected to. I’m curious as to whether it’s somehow trying to connect to the ping device as though it’s a camera, or if you have some issue with your actual camera.
This would imply there’s at least something funky going on with respect to the ping, although it’s unclear whether it’s related to the camera module error. I just went through your oldBEC and newBEC terminal outputs and they appear to be exactly the same other than minor differences in the timestamps. Do you have a USB camera connected (it’s not detecting one), or are you using a separate IP camera or something?
If you’re not using a USB camera I’d suggest you try commenting out the lines that start the video and audio services in companion. To do that, when you open the web terminal you can run nano companion/.companion.rc to edit the relevant file with the nano editor, then use the arrow keys to get to the relevant lines, and put a hash (#) in front to comment them out:
Then press Ctrl+X then y to save, and Enter to exit the editor. Reboot the companion and see if the waiting for frame completion error goes away, and hopefully also the issues with unexpected high CPU usage (although they may be unrelated).
This is telling you that updating with PingViewer can only be done if the Ping1D is directly connected to the device running PingViewer - you need to plug the USB cable into your topside computer, not the companion computer.
It’s technically possible to update the Ping1D through the companion web interface /ping endpoint, but that requires downloading the firmware manually onto your topside computer and uploading it through the web interface, which is a bit more troublesome and has more scope for issues than the auto update through PingViewer.
As a note, the command prompt message log that comes up when you open the new PingViewer isn’t meant to be there - that should be fixed if you re-download PingViewer 2.2.0
Dear Eliot,
thank you very much for getting back to me - on Sunday! I really appreciate your commitment.
I modified companion.rc as recommended and the final error (“bcm2835-v412: error 0 waiting for frame completion”) disappeared, but so does the video stream in QGC. So I reloaded the Default gstreamer options in the web GUI (http://192.168.2.2:2770/camera), reloaded the page, and applied them. This move made the error reappear (see messages below and screenshot) and the system started to heat again:
[ 26.560572] random: crng init done
[ 231.526773] media: Linux media interface: v0.10
[ 231.546109] Linux video capture interface: v2.00
[ 231.606800] bcm2835-v4l2: scene mode selected 0, was 0
[ 231.607934] bcm2835-v4l2: V4L2 device registered as video0 - stills mode > 1280x720
[ 231.612765] bcm2835-v4l2: Broadcom 2835 MMAL video capture ver 0.0.2 loaded.
[ 234.487347] bcm2835-v4l2: error 0 waiting for frame completion
My video device is the original Raspberry Pi Camera Module: mmal service 16.1 (Raspberry Pi Camera Module). I wonder if the streaming script or service expects the new low-light camera module?
Then, I set the MAVProxy --streamrate to 2 Hz (http://192.168.2.2:2770/mavproxy), and the system cooled down.
I tried to update the Ping1D firmware directly connecting its UART interface to the topside using an USB cable (COM7, 115,200 bits/sec) and PingViewer 2.2 (downloaded again 2 hours ago), but couldn’t establish the connection (and the command prompt message log still comes up). I didn’t manage to establish a direct connection with version 2.1 either. But the Ping sends data via the companion.
I’ll give it another try today and hope the systems will operate. Otherwise, I would have wasted a lot of time and money for field work in the Caribbean.
The video streaming functionality should work fine for the Raspberry Pi camera - it’s an option I’d forgotten about, which isn’t an IP camera but also isn’t a USB camera. It does go via the companion computer though, so at least the video service should remain. You can comment out the audio one if you want, but it likely won’t have much if any effect.
I believe the camera error is likely just from some probing the camera streaming script does to determine appropriate camera settings - if the video is coming through correctly then it’s likely not an issue.
Did you manage to get this working? We’re working on a companion update at the moment that should reduce CPU usage and will hopefully solve this and a few other issues people have been having, but I can’t guarantee a release time for it (we’re hoping for tomorrow). Would be great if the streamrate reduction has helped enough for your current work
Can you confirm you were trying Ping1D → USB-Serial converter (e.g. BLUART) → microUSB to USB cable → computer running Ping Viewer?
Apologies - it seems there was an issue with an automated build not happening properly. If you download again now you should get version 2.2.1, which should fix the command prompt issue.
