Hi Guys,
Has anyone use Cygnus Ultrasonic Thickness gage on BR2? Keen to know if it’s possible. Do share your inputs if any of you have done it. Thanks.
BR, Fazdli
Hi Guys,
Has anyone use Cygnus Ultrasonic Thickness gage on BR2? Keen to know if it’s possible. Do share your inputs if any of you have done it. Thanks.
BR, Fazdli
@Fazdli, it should be possible. Do you have any datasheet or technical document for the device?
Hi Jacob,
You can take a look here.cygnus-mini-rov-mountable-data-sheet-iss2.pdf (1.9 MB)
Hi Mohamed,
You just need to use 1 spare twisted pair for the signal from the topside to the gauge.
And you power it from the terminal block.
I did it, it’s working well.
Regards
Hi Achat,
Thanks for the input.
Regards
A little late to this thread but here is a pic of a system we just shipped to a power utility for use in and around a hydroelectric dam facility. Mounted on the BlueROV2 Heavy is the Cygnus Mini ROV Mountable thickness gauge with the Cygnus G1 Probe Handler.
BlueLink, LLC is an Official Blue Robotics Distributor located in Southern California. www.Blue-Linked.com
Looks great ! Is there any reason why you couldn’t use a 422/232 to USB converter plugged into a USB port on the RPi, using a UDP, rather than tie up a spare twisted pair ? Just asking, not a criticism !
@richard-rickett @achat I’m also interested about the USB option. Should that be possible? Nice system @BlueLink_JC
Hi @GavXYZ (/@richard-rickett),
The Cygnus Ultrasonic thickness gauge is actually the sensor I was using in this post a couple of years ago (while working for a different company), which includes the code and steps I went through to get it set up and communicating. We were using a serial to USB converter in the ROV’s enclosure, which was plugged into a USB port on the Raspberry Pi
Hi @EliotBR ,
Have you tried integrating Cygnus Dive Model , I am unable to find the incoming data format for this model.
Hi @ishanb, welcome to the forum
When I was working with it I was only using the Mini ROV Mountable option, and I got the serial format and data interpretation information from the datasheet. I’m unsure whether the datasheets are available without purchasing the product or asking Cygnus.
That said, I wouldn’t be particularly surprised if the serial formats are the same, especially for sensors that are doing the same thing.
In case it’s useful, @rjehangir has been working on an extension for the Cygnus UT gauge, which follows on somewhat from the integration I originally made for Companion, but also includes a web interface that allows logging and labelling measurements.
That extension is not currently registered in the store, so if you want to try it out you’ll need to add it manually via the “+” button in the Installed tab of the Extensions manager:
Field | Value |
---|---|
Extension Identifier | rjehangir.cygnus |
Extension Name | Cygnus UT |
Docker image | rjehangir/blueos-cygnus-ut |
Docker tag | latest |
The “Custom settings” should be set to
{
"ExposedPorts": {
"8000/tcp": {}
},
"HostConfig": {
"Binds":["/root/.config/blueos/extensions/cygnus-ut:/root/.config"],
"PortBindings": {
"8000/tcp": [
{
"HostPort": ""
}
]
}
}
}
Hi @EliotBR sorry for a very basic question here.
But the Cygnus probe connects over serial. I have a USB hub in a separate bottle to my Pi and Navigator, would I be able to connect the cygnus via a serial to in the USB hub bottle and use the BlueOS extension that @rjehangir is working on?
p.s. Great to see the founder of the company contributing to the coding. It demonstrates the passion is there
Regards,
Kieron
Hi @XYZEng, yes, that should work just fine! The Cygnus extension is still only at like, 90% complete, so let me know if there are issues or if you need help installing it.
Hi @rjehangir and @EliotBR,
Thanks for the instructions above getting the plugin installed. I’ve just got the probe connected and working. The extension looks really great.
Note. I got around a problem where the USB device wasn’t showing up:
But I found I could connect by using modified “custom settings” in the extension:
{
"ExposedPorts": {
"8000/tcp": {}
},
"HostConfig": {
"Binds": [
"/root/.config/blueos/extensions/cygnus-ut:/root/.config"
],
"PortBindings": {
"8000/tcp": [
{
"HostPort": ""
}
]
},
"Devices": [
{
"PathOnHost": "/dev/ttyUSB0",
"PathInContainer": "/dev/ttyUSB0",
"CgroupPermissions": "rwm"
}
]
}
}
Though I’m sure there’s a more robust way to maybe show all devices in the extension. @EliotBR would you be able to check if I did that correctly?
Couple of questions here all related:
Displaying data:
Sending data:
I’ll have to look into / ask the others on this one - I’m yet to delve deep into Docker’s configuration/permissions options.
I’ve covered the process for this previously, but it’s rather painful, and requires building a custom QGC version.
Definitely - that’s one of the main kinds of use-case the Very Generic Indicator mini-widget is intended for
Do note that the extension already provides a /widget
endpoint that Cockpit can display in an IFrame widget, which includes some basic control over the data logging process.
Yes - it should be reasonably straightforward for the extension to output regular NAMED_VALUE_FLOAT
MAVLink messages with the thickness estimates, if that’s a desirable feature.
You could raise an issue and/or submit a pull request for that to the Extension if you think it’s valuable
That’s another potential path, although I don’t see particular value in doing so unless you want more functionality than the extension’s existing /widget
endpoint provides and you would prefer to use Node-RED for personal changes over making adjustments/contributions to the extension itself
Hi @XYZEng,
The easier way to give the extension access to hardware devices is to add "Privileged": true
under the Host Config
section. This will give it access to everything. Your way is a little safer since it only gives access to a single port!
The extension does not send any mavlink messages yet so there is nothing to show in the “very generic indicator”. Doing so is on my to-do list but I haven’t done that yet! Sending a mavlink message for named_value_float
should do the trick.
-Rusty
Thanks @EliotBR Eliot and @rjehangir ,
I remember seeing the requirement to rebuild QGC in another post to display mavlink messages. Cockpit definitely adds a lot more flexibility for subsea type tasks.
I had a look at the iframe, I can see how it will be handy when limited to one screen - as I can make it semi transparent.
I’ll stick with the extension to log data in the standard way for now.
I’d like to contribute with a pull request to see if I can get the Mavlink stream working, but I’m not quite there yet. Maybe the next time I’m preparing for a job with the Cygnus probe.
We recently integrated a Cygnus Ultrasonic Thickness (UT) gauge for one of our customers! A legacy customer, who maintains a hydroelectric dam facility, sent in their BlueROV2 (which they’ve had for a few years now) to upgrade it to full surface power. Along with the BlueROV2 system, they also sent in their Cygnus Ultrasonic Thickness Gauge, so we put it through its paces. We tested it in our pool with scrap metal and on a sea wall in Grand Traverse Bay. It performed well, with a maximum variance of only about a hundredth of an inch compared to the calipers.
The system is set up to work with either the BlueOS extension that @rjehangir developed or through VirtualHere software to forward the device to the topside, where it can be used with the CygLink software.
For use with the BlueOS extension, setting "Privileged": true
under the Host Config
section works well. It would be great if the extension could toggle between metric and imperial, but aside from that, it functions smoothly!
I’ve attached some images of the system below! We had two ROVs in the water to capture action shots of the unit with the UT gauge.
Cool! Thanks for sharing
Extension feedback/suggestions are likely easiest for others to find / keep track of / implement if it’s raised as an Issue in the relevant source repository (this one, for this particular extension)