Ping 360 time info/split image

[EliotBR (Eliot)]

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

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?

[patrickelectric (Patrick José Pereira)]

@EliotBR

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

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.

@EliotBR

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.

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.

@EliotBR

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?

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.

@EliotBR

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?

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º
...

[EliotBR (Eliot)]

Thanks for the in-depth response!

@patrickelectric

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

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

@patrickelectric

you can drop the scan time down to 4s@2m and even less depending of the communication method and scan configuration

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”?

@patrickelectric

you could also tune the sensor to accomplish shorter distances

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.

@patrickelectric

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

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.

[EliotBR (Eliot)]

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).

[patrickelectric (Patrick José Pereira)]

@EliotBR

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?

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

@EliotBR

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”?

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

@EliotBR

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.

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.

@EliotBR

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)

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.

@EliotBR

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 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.

[EliotBR (Eliot)]

@patrickelectric

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

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.

@patrickelectric

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

Cool, makes sense

@patrickelectric

About the direction, is ping-pong like, it scan clockwise and once it hits the desired limit, starts the scan again counter-clockwise.

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

@patrickelectric

Python should interfere a bit but not that much, can you share your scan test speed code ?

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)

@patrickelectric

The 4sec/rev is for the new firmware that is not available yet.

Ok, fair enough

@patrickelectric

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.

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.

[patrickelectric (Patrick José Pereira)]

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.

[EliotBR (Eliot)]

Thanks for the response!

@patrickelectric

I got around 4.3s scanning when running via ethernet and around 9s when running at 3M baudrate via serial.

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?

[EliotBR (Eliot)]

@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.

[patrickelectric (Patrick José Pereira)]

Hi @EliotBR,

@EliotBR

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

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

@EliotBR

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?

Probably that should do it.

@EliotBR

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?

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

@EliotBR

any chance you’d be able to confirm if there are additional electronics required to swap to using Ethernet instead of USB?

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

Changing Communications Interface on the Ping360

Let me know if something is not clear.

[EliotBR (Eliot)]

@patrickelectric

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

Ok, fair enough, thanks.

@patrickelectric

Check our guide, it contains all necessary information:

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.

[patrickelectric (Patrick José Pereira)]

Hi @EliotBR,

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.

[EliotBR (Eliot)]

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?

[patrickelectric (Patrick José Pereira)]

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.

[EliotBR (Eliot)]

Makes sense, thanks for the clarification.

@patrickelectric

I just tested the python script and I got around … 9s when running at 3M baudrate via serial.

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

[zarbokk (Tim)]

Hey @patrickelectric,
We are currently also trying to use the Scanning sonar with the Python scripts.
As Eliot already said the scan speed is much slower compared to the Ping Viewer.

You said that there is a new software, such that the control_auto_transmit method can be used.
Currently, when using the same script as Eliot, the message is not received. That means, that the software is not updated, right?
Therefore I wanted to ask for Updates or directions.
Currently, the only idea we have is to use the Ping-Viewer Code as a basis to develop a better library for us, which seems unnecessary with ping-python or ping-cpp.
Any directions you can help me?

Thanks

[EliotBR (Eliot)]

Hi @zarbokk, welcome to the forum

As some context, since the time when this thread was initially posted I’ve now started working for Blue Robotics

@zarbokk

As Eliot already said the scan speed is much slower compared to the Ping Viewer.

I haven’t tested this in a while, but I’ll try to set some time aside tomorrow to see if I can determine what the maximum reasonable speed is for a serial-USB connection with the ping-python library. It won’t be as fast as what Ping Viewer can achieve (because it’s compiled c++), but as Patrick mentioned it should at least be faster than 20 seconds, and will depend on the connection type and settings, as well as the transmitting settings. If it’s relevant, changing to an ethernet connection is now much simpler than it was before, because we’ve released an Ethernet Switch that it can be plugged into. I’ve described the changeover process here, but we haven’t yet updated our official guide to include it.

I would note that the ping-python library has had various speed improvements since when I was working with it last year, but they’re only available in the latest version, which is Python 3 only. If you’re connecting from the topside computer, or a standard Raspberry Pi that’s not running our Companion software, you can safely install bluerobotics-ping with pip (you should get version 0.1.2).

If, however, you’re trying to run your code on the Companion computer there can be some issues, because ping-python is already installed there on Python 2, and installing it for Python 3 as well will overwrite the ping-proxy.py script that’s used by the Ping Echosounder. If you’re only using the Ping360 then it should be ok.

@zarbokk

You said that there is a new software, such that the control_auto_transmit method can be used.
Currently, when using the same script as Eliot, the message is not received. That means, that the software is not updated, right?
Therefore I wanted to ask for Updates or directions.

Unfortunately the firmware that supports auto-transmitting is still not publicly available. If I understand correctly that’s mostly because there have been issues making a suitable cross-platform software that can actually install it onto the device, and that’s also been a low priority lately because of focus on other critical projects.

@zarbokk

Currently, the only idea we have is to use the Ping-Viewer Code as a basis to develop a better library for us, which seems unnecessary with ping-python or ping-cpp .
Any directions you can help me?

You shouldn’t need to refer to Ping Viewer when developing the functionality you want, although it may be helpful to do so for things that Ping Viewer already does well. That said, if you’ve got any particular questions about how to achieve a particular thing then you’re welcome to ask about them here (or in a separate topic, if appropriate).

I’ll be better placed to respond to those once I’ve had a chance to refresh myself on the current state of connecting via ping-python, which as mentioned I’ll try to do tomorrow

[zarbokk (Tim)]

Thanks for your quick reply,

First, our goal is to change the Scan Distance + Resolution dependent on the current situation that we have with ROS, because sometimes the measurement speed is of importance, and sometimes the actual measurement of the environment.

Regarding the speed of python vs C++:

I am very happy to also just use C++ if that is faster, that is not a problem in general. Currently, we use a custom setup for the BlueROV, which includes our own RPI with ROS running and everything python3.
That means the connection is started from the RPI, which is connected to the ping360, and then transferred with ROS. We first tried out the Ping360 ROS driver, which resulted in very low speed compared to ping viewer. Maybe there exists a problem that the package is very slow compared to the current python-ping architecture? But I think the package is using exactly that API.
But I am not sure about that.

Regarding the Ethernet, this is of course possible, but maybe not our first approach. But we keep that in mind thanks. Also, if the Ping-Viewer is as fast over USB, the ethernet would not solve the problem in the case of the python-ping approach. The bottleneck should be somewhere else in that situation, or am I wrong?

One Question regarding the Ping-Viewer code:
Is the Ping viewer also not using the auto transmit mode? If that is the case C++ seems to be much faster.

I am looking forward to hearing from your experiments.

[EliotBR (Eliot)]

@zarbokk

We first tried out the Ping360 ROS driver , which resulted in very low speed compared to ping viewer. Maybe there exists a problem that the package is very slow compared to the current python-ping architecture? But I think the package is using exactly that API.

Ping360 ROS driver isn’t something we’ve created or that we maintain, so it may not be up to date. From a quick look, the README specifies

@Ping360 ROS driver - README

!Headsup! B.R. just updated their package with some breaking changes, make you sure you use version 0.0.9 for now.

so that’s definitely quite outdated. I’d suggest checking the forks to see if someone else has been maintaining a more up to date version. The first one I clicked on seems to have 51 more commits than the original repo and was last updated 10 days ago, so is perhaps a good bet, although I haven’t looked at any of the other forks, and don’t know if the maintainer of that fork has made modifications for their own use-case that could cause issues elsewhere.

@zarbokk

Also, if the Ping-Viewer is as fast over USB, the ethernet would not solve the problem in the case of the python-ping approach. The bottleneck should be somewhere else in that situation, or am I wrong?

Ethernet is faster than USB, and C++ is faster than Python, so the fastest option is Ethernet with C++. That said, I won’t know comparisons until I’ve done some testing tomorrow. I also don’t have much C++ experience, so I’ll likely only test Python (with both Ethernet and USB) and then see how that compares to Ping Viewer (as a rough equivalent of a C++ reference)

@zarbokk

One Question regarding the Ping-Viewer code:
Is the Ping viewer also not using the auto transmit mode? If that is the case C++ seems to be much faster.

Nope. Auto transmit mode is a firmware option that doesn’t yet exist publicly, so it can’t be using it.

C++ may be much faster (it’s definitely possible), but it could also be using different settings or something else. Hard to say until I’ve tried it/looked into it

[zarbokk (Tim)]

@EliotBR

@Ping360 ROS driver - README

!Headsup! B.R. just updated their package with some breaking changes, make you sure you use version 0.0.9 for now.

so that’s definitely quite outdated. I’d suggest checking the forks to see if someone else has been maintaining a more up to date version. The first one I clicked on seems to have 51 more commits than the original repo and was last updated 10 days ago, so is perhaps a good bet, although I haven’t looked at any of the other forks, and don’t know if the maintainer of that fork has made modifications for their own use-case that could cause issues elsewhere.

Yea, we also noticed that one, but didn’t test it yet, because the changes they made were not related to the python-ping library, but added other things and capabilities. Therefore we didn’t feel like that would lead us into something. But we will try that as well next week.