Home        Store        Learn        Blog

Ping 360 time info/split image

Hello,

We’re considering using sector scans from the Ping 360 as part of dock inspections, to measure pile profiles and estimate the cross-section at different depths by scanning from multiple sides. I’ve had a look at the documentation and it looks like the device_data messages are sent at each motor angle (since the angle field is singular), which the ping viewer application then stitches together into an image for visual display.

  1. Is this correct i.e. during a scan we’d get several data messages sent throughout rather than just one full image message at the end? If that’s the case we can potentially use the IMU data to account for any minor position changes while scanning :smiley:

  2. The technical details in the specification say a 2m scan distance takes 9s for a full revolution, with the expectation that the scan time will be reduced through software optimisations. Curious as to whether there’s an estimate for how much that will be reduced by, and if it’s planned as near term or in a year or something.

  3. The minimum distance is specified as 0.75m at the moment. Presumably that’s a processing speed limit, but is that likely to decrease with the intended software optimisations, or are the optimisations more to do with motor movement than improving processing time?

  4. A continuous 360 degree scan is possible, but is continuous bouncing sector scanning possible, or does the motor only go one way? If it’s two-way and we request a scan from 350 to 10 degrees, how does it know which way to turn? If it’s one-way presumably the motor can move quickly from the end of one scan sector to the start of the next one in the region where it’s not scanning?

Yep, that’s correct, we do a bit of that with our current ping-viewer version if you enable the Heading Integration option, we use the ROV yaw information for that.
image

The scan time depends of software that is scanning and the firmware version of ping360, but with latest version of ping-viewer and experimental firmware version of ping-viewer, you can drop the scan time down to 4s@2m and even less depending of the communication method and scan configuration. We have plans to do a future release of the new firmware.

That’s more a factor related to the reflections of the signal and possible noise, you could also tune the sensor to accomplish shorter distances, but that’s not a recommend scenario.

With the protocol you just need to request angle - 1 when it requests the maximum angle and angle + 1 when it hits minimum angle. E.g:

...
- Request profile in 8º
- Request profile in 9º
- Request profile in 10º
- Request profile in 9º
- Request profile in 8º
...

you could also do:

...
- Request profile in 8º
- Request profile in 9º
- Request profile in 10º
- Request profile in 350º
- Request profile in 351º
...

Thanks for the in-depth response!

I’ll have to take a look at the ping-viewer repo and see if I can find where that’s done, for tips on how to implement it for our analysis :smiley:

Great to hear that the scanning speed has already been increased in the latest firmware versions. Given the note in the docs about RS485 possibly requiring an extra delay, I’m assuming USB would be faster? In saying that, are there likely to be issues overloading the bandwidth up to the top computer if going through the companion computer via USB, as compared to sending over RS485 through its own twisted pair in the tether? As is we’ve got two BR low-light cameras and the mavlink messages going through the companion computer tether connection, so I’m not sure we’ve got much bandwidth left on that pair…

Just looked at the ping-protocol docs again and it seems that we can adjust the range (to potentially less than 2m), range resolution, and rotation resolution as well as the sector angle. I’m assuming those are what you were referring to by “depending on … scan configuration”?

Interesting. Fair point on noise and it not being recommended - I’ll take a more careful look at our requirements and how we choose to mount the device. Hoping to stay above 0.75m distance, but if we need to get closer then I’ll ask about that in a separate post when I can be more specific about what’s desired.

Yeah that makes sense, although that seems to be specific to single angle requests. There doesn’t seem to be a way to set the direction for auto_transmit mode - is there some default (e.g. clockwise), or does it just take for example the shortest route from start angle to finish angle? I’m thinking something like a forwards bouncing sector scan doing 356->44 and then 44->346 as auto_transmit commands, but the documentation doesn’t seem to specify which way the scan would go for each command, and one or both of the commands might need to be sent as a set of individual angle requests instead to ensure the direction is correct.