Ping Sonar range setting and the angle definition

1.Is an effective range set in ping-viewer reflected when python code is executed?

Can an effective range be set up in ping360.py?

2.When I use ping360.py transmitAngle(x), does “x “ represent the angle from the direction sonar is facing? Also, is the center of the sonar’s orientation (X=0) the same direction as the triangle drawn on the bottom of the sonar?

When X=40 and while looping, does the sonar scan from 0 to 39 and then circle back around without scanning to 0? (0-39 scan → rotate without scanning 40~399 → 0-39 scan → …)
It takes about 0.5s to return to 0.
sonar.pdf (99.8 KB)

Hi @yuki,

Note that:

Yes, assuming you don’t turn off the device in between (parameters are reset to the defaults when the device turns on).

The range per sample is determined by the sample_period, so the total range is determined by sample_period and number_of_samples, together with the speed of sound in the water you’re operating in (see here if you want to estimate it from vehicle data, and here for estimating salinity).

If you want to make a set_range function, it may be worth looking at how it’s implemented in Ping Viewer :slight_smile:

The following information may be useful:

Not certain what you’re referring to here.

If you transmitAngle(40) and then transmitAngle(0) it will go the shortest direction back to the target angle (0 in this case), and it won’t transmit or take samples until it gets to the target angle. If you want you can test that by sending transmitAngle requests for 40, then 0, then 200 - it will take longer to get from 0 to 200 than from 40 to 0.

If you’re referring to the auto-transmit section then

The “not released” state is documented for auto_device_data but apparently got missed for auto_transmit - I’ve added that fix to a pull request.

Thank you for your reply. Very helpful.

When I calculate distance from intensity data, is the following equation correct?

\begin{align}d = \frac{element\ number_{intensity} \times (range_{max} - range_{min})}{n_{number\ of\ samples}} + range_{min}\end{align}

From the same post I quoted earlier,

Assuming

  • your d is the same as my sample_start_distance,
  • your element\ number_{intensity} is the same as my sample_index, and
  • range_{min} = 0 (which is the case for any data returned from a Ping360),

then you’re left with meters_per_sample = \frac{range_{max}}{n_{number\ of\ samples}}, which is indeed the case :slight_smile:


Update on this - that PR has been merged, and the docs have been updated accordingly :slight_smile:

Is the minimum range 0m instead of 0.75m?

The data starts at 0m, but echoes within the sensor head after a transmission take a while to die down, which means that there’s noise in the readings up until about 0.75m, so reflections off external objects within ~0.75m of the sensor can be difficult to see/detect properly.

This image gives a sense of the noise from internal reflections when the sensor is scanning a 2m range:

Note that when the scanning range is set to longer the transmitted pulses are also longer, and the echoes take a bit longer to die out.

Thanks! Very helpful.

By the way, the sonar will sometimes fail to connect and reconnecting the power wire will allow it to connect.
Is it possible that this is an initial defect?

How are you detecting and connecting to it? In our Companion software there’s some Ping device detection code that runs on startup, and any devices that don’t register at that time get missed and don’t get configured or connected to properly. Our first troubleshooting step is

I’m unsure if BlueOS supports hot-plugging - I think it’s at least planned to, if it doesn’t already. The general idea would be to monitor/hook into when USB devices are connected, and whenever a new device is detected to try to determine if it’s a Ping device, and if it is configure it as relevant :slight_smile: