Ping360 range setting and the angle definition

[yuki (Yuki Kihara)]

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)

[EliotBR (Eliot)]

Hi @yuki,

Note that:

@patrickelectric

With Ping360 you have access to the direct parameters to configure the sensor without any abstraction, making the sensor more powerful [than Ping Echosounder] and as result a bit more complex to configure.

@yuki

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

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

@yuki

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

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

@yuki

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?

The following information may be useful:

@EliotBR

A few gotchas:

1. the ping angles are measured in gradians, so the angle attribute is a value from 0 to 399
2. the ping360 zero angle is at the back where the penetrator is, so ‘forwards’ (the direction of the arrow on the bottom of the Ping360) is at angle 200 gradians
3. Sonar (and all time of flight sensors) measure the time it takes for the pulse to return, so while d_{sound} = v_{sound} * t_{sample}, the target is half of that: d_{target} = \frac{d_{sound}}{2}

The following function can be used to determine the target distance per sample:

def meters_per_sample(ping_message, v_sound=1500):
    """ Returns the target distance per sample, in meters. 
    
    'ping_message' is the message being analysed.
    'v_sound' is the operating speed of sound [m/s]. Default 1500.

    """
    # sample_period is in 25ns increments
    # time of flight includes there and back, so divide by 2
    return v_sound * ping_message.sample_period * 12.5e-9

@yuki

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.

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

@EliotBR

auto_transmit is a part of the protocol specification, but isn’t yet available in Ping360 devices. There’s a new firmware that’s been tested somewhat internally, but it’s not yet public, and there isn’t yet a publicly available firmware updater either.

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.

[yuki (Yuki Kihara)]

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}

[EliotBR (Eliot)]

From the same post I quoted earlier,

@EliotBR

If you have the sample index (from within the data array) the distance at the start of the sample time is just

sample_start_distance = sample_index * meters_per_sample(ping_message, v_sound)

(i.e. the first sample (index 0) has distance 0m).
Alternatively, you can get the distance to the middle of the sample time with

sample_average_distance = (sample_index + 0.5) * meters_per_sample(ping_message, v_sound)

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

---

@EliotBR

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.

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

[yuki (Yuki Kihara)]

Is the minimum range 0m instead of 0.75m?

[EliotBR (Eliot)]

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:

@EliotBR

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.

[yuki (Yuki Kihara)]

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?

[EliotBR (Eliot)]

@yuki

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

• If using a UDP connection via the Blue Robotics companion computer, power on the ping device(s) before or at the same time as the companion computer, so they can be detected correctly on companion startup

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