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.

We got a Ping360 (yay!), and I’m currently in the process of putting it through its paces.

I’ve installed ping-python and tried running the ping360.py file to get an initial idea of how to use the interface. I’ve done some other playing too, but I’m confused because the printed results give

full scan in 18607ms, 21Hz
full scan in 201214ms, 1Hz
full scan in 20146ms, 19Hz

which means the manual full scan runs ~10x faster than the auto_transmit full scan, and 400 individual single-grad steps takes a bit less time than 40 auto steps of 10 grads. With 200 samples per angle, a sample period of 80*25ns (2us), and a transmit duration of 5us, I believe that’s the fastest scan-speed possible, which is quite concerning.

@patrickelectric would you be able to clarify

  1. Is the general low speed because I’m using Python? (ping-viewer runs faster and with seemingly more data-points, but it’s still not the 9sec/rev quoted on the technical details page, and definitely not the 4sec/rev you suggested earlier)
  2. Is this indicative of a bug in the auto-transmit command? I’d definitely expect automatic ‘send as fast as you can’ to be faster than individual requests, since there’s just less communication required.

As some extra info, the amperage reading on my bench-top power supply I’m using for this is at basically the idle/motor off level while it’s doing the auto-transmits (80mA, vs 220mA when doing the individual commands scan, and 220mA when using ping-viewer too).

USB is just an serial adapter for the RS485, you can accomplish fast speeds with high baudrate but ethernet is preferable.

Yes and other settings such sample time, transmission time and etc.

auto_transmit is a message that is only available for the newer firmware version that is not available yet (3.2+), but you are correct auto_transmit work in a different way, you only need to set the scan range and the scan logic will be done by the sensor.
About the direction, is ping-pong like, it scan clockwise and once it hits the desired limit, starts the scan again counter-clockwise.
You also only seed to send the message once and the sensor will return all profiles as fast as possible using the configuration on the auto_transmit.

Python should interfere a bit but not that much, can you share your scan test speed code ? The 4sec/rev is for the new firmware that is not available yet.

As I said auto_transmit is not available yet and I surprised that it work for you somehow, but without the script I can’t be sure that you did.

Alright, fair enough. I’ll have to see how we go with USB and then look into changing to ethernet if we need more speed.

Cool, makes sense

That makes sense, thanks. I assume then that if you specify start=300, end=40 it would go as 300<=x<=40, whereas if you specify start=40, end=300 it would go as 40<=x<=300. Presumably the final behaviour will be documented once the firmware is released :slight_smile:

I’m just running the ping360.py file that gets auto-generated when you pip install --upgrade bluerobotics-ping. For reference, the code that’s run when running it as a script is:

if __name__ == "__main__":
    import argparse

    parser = argparse.ArgumentParser(description="Ping python library example.")
    parser.add_argument('--device', action="store", required=False, type=str, help="Ping device port. E.g: /dev/ttyUSB0")
    parser.add_argument('--baudrate', action="store", type=int, default=115200, help="Ping device baudrate. E.g: 115200")
    parser.add_argument('--udp', action="store", required=False, type=str, help="Ping UDP server. E.g: 192.168.2.2:9092")
    args = parser.parse_args()
    if args.device is None and args.udp is None:
        parser.print_help()
        exit(1)

    p = Ping360()
    if args.device is not None:
        p.connect_serial(args.device, args.baudrate)
    elif args.udp is not None:
        (host, port) = args.udp.split(':')
        p.connect_udp(host, int(port))

    print("Initialized: %s" % p.initialize())

    print(p.set_transmit_frequency(800))
    print(p.set_sample_period(80))
    print(p.set_number_of_samples(200))

    tstart_s = time.time()
    for x in range(400):
        p.transmitAngle(x)
    tend_s = time.time()

    print(p)

    print("full scan in %dms, %dHz" % (1000*(tend_s - tstart_s), 400/(tend_s - tstart_s)))

    # turn on auto-scan with 1 grad steps
    p.control_auto_transmit(0,399,1,20)

    tstart_s = time.time()
    # wait for 400 device_data messages to arrive
    for x in range(400):
        p.wait_message([definitions.PING360_DEVICE_DATA])
    tend_s = time.time()

    print("full scan in %dms, %dHz" % (1000*(tend_s - tstart_s), 400/(tend_s - tstart_s)))

    # stop the auto-transmit process
    p.control_motor_off()

    # turn on auto-transmit with 10 grad steps
    p.control_auto_transmit(0,399,10,20)

    tstart_s = time.time()
    # wait for 40 device_data messages to arrive (40 * 10grad steps = 400 grads)
    for x in range(40):
        p.wait_message([definitions.PING360_DEVICE_DATA])
    tend_s = time.time()

    print("full scan in %dms, %dHz" % (1000*(tend_s - tstart_s), 400/(tend_s - tstart_s)))

    p.control_reset(0, 0)

Ok, fair enough

Interesting, I wonder how it’s working…
The part of the generated ping360.py where it’s defined is within the Ping360 class definition:

    def control_auto_transmit(self, start_angle, stop_angle, num_steps, delay):
        m = pingmessage.PingMessage(definitions.PING360_AUTO_TRANSMIT)
        m.start_angle = start_angle
        m.stop_angle = stop_angle
        m.num_steps = num_steps
        m.delay = delay
        m.pack_msg_data()
        self.write(m.msg_data)

I can paste the whole file if you want, but you should be able to get it just by installing bluerobotics-ping with pip.

Hi,

I just tested the python script and I got around 4.3s scanning when running via ethernet and around 9s when running at 3M baudrate via serial.
Remember to run --help to check the options, with the default option baudrate (115200), you’ll get around 18s.
Is just a matter of configuration.

Thanks for the response!

Is that on the existing available firmware, or on the new and improved one that isn’t publicly accessible yet?

As for the baudrate configuration, for some reason I assumed it would be set by default to the max rate, and didn’t bother to do the maths to realise that 115200 isn’t a fast enough data rate to enable the expected data speeds - my bad, should’ve thought about it a bit more. I’ll have to try increasing the baudrate and see how it goes.

If it turns out we decide to switch to using ethernet for the extra speed, the changing communication interface guide doesn’t yet specify what’s required. I’m assuming the ping360 doesn’t provide a strong enough signal to go through the full tether length, so would we need another fathom X on each end of one of the currently open pairs? I’ve been warned against trying to use multiple pairs simultaneously for camera streaming because of electrical noise that gets across because the pairs aren’t shielded from each other - has noise caused any issues for you with the ping360?

@patrickelectric any chance you’d be able to confirm if there are additional electronics required to swap to using Ethernet instead of USB? I’ve done the wiring for USB on one of our ROVs but would ideally like to know if there are extra components required for Ethernet before we decide how we want to install it on our other one.

Apologies if my earlier private message made it seem like I’d sorted this out - I should have been clearer.

Hi @EliotInsight,

Is with the new firmware, but not using the new messages that speed the communication, the behaviour should be the same for you…

Probably that should do it.

You should be fine if I understood correctly, you are using a par for the communication and the other specific for ping360, right ?

You should have a JST-GH to JST-GH inline adapter for USB.
Check our guide, it contains all necessary information:

Let me know if something is not clear.

Ok, fair enough, thanks.

I’ve got the USB connection working fine, but I’m considering trying out the Ethernet option. As I mentioned in an earlier comment that guide doesn’t seem to include any information about how to do the Ethernet configuration - it only specifies details for USB and RS-485.

Hi @EliotInsight,

Sorry for that, the guide does not explore much about the ethernet capability.

But be aware, if you move the connector to the ethernet port inside the Ping360 and then plug the cable into the USB port you will fry the ethernet transformer.

With that in mind, you can follow this simple guide for the ethernet cable wiring:

In the same guide you’ll see the connector for ethernet as Ethernet Configuration Port, the pins are also labelled as T-, R-, T+ and R+.

You can check the proper wiring following the table with RX and TX lines here:

Remember that is the male connector, you’ll need to mirror it if you’re going to use a female connector.

Tip: Security camera adapters are a really good and cheap source for a female socket.
Tip2: The colors may be different from one site to another, it’s safer to use the pins numbers.

Thanks for the wiring table and the tips. I believe the wiring info is provided in the technical details of the Ping360 page - I’m mostly wondering if a separate fathom X is required on each of the tether, or if I can instead just connect the ping360 wires directly to the tether wires. You responded to my original query with “Probably that should do it” but I wasn’t sure if that was meaning

  1. “yes, the assumption is correct and an additional fathom x on each end is required”, or if you meant
  2. “no, the ping360 can communicate directly with the top, just join the wires straight to the tether and make sure they’re in the existing connector you’re using at the top”

Apologies for my miscommunication, hopefully that’s more clearly expressed now? :slight_smile:

Sorry if I was not clear.

Well, it depends of the distance and communication method.
If you are using ethernet, you’ll probably need a extra phatom-x, but I’m not sure if someone have tried it before.
If you are using RS485, it should handle a short distance, but probably not suitable for your tether length.

Makes sense, thanks for the clarification.

You mention here that you were able to run at 3M baudrate. I tried this the other day by changing the 2000000 to 3000000 in line 73 of ping360_bridge_manager.py, and when I did that it seemed to start fine on the companion computer (the behaviour was as normal in screen -r bridgemanager), but it wasn’t detected by PingViewer for some reason.

I’ve just realised I should probably check the actual Ping360-id-2 screen session in case that tells me anything of interest - I’ll get to that on Monday. If there’s anything special I need to do on the top side, or if there’s some reason 3M baud won’t work for the standard USB configuration please let me know :slight_smile: