Hi, I’m working on a (diver-held) device to map underwater caves/mines. I think sonar could give me the last bit of the mapping puzzle and I’d be very grateful for any pointers on things to worry about/that might help.
It seems like four ping sonars (one facing up, one down, one left and one right), perpendicular to the axis of travel would give me left, right, up and down distances from the diver holding the device. I’m taking depth, direction and distance measurements roughly every 100ms or so (though could go slower).
I understand that I can’t fire four ping sonars at the same time and would have to cycle them one after the other.
The bottom/wall/roof composition varies but is usually hard rock, the bottom almost always has a covering of silt/mud of varying depths (though usually not much more than six inches/15cm or so).
Passage size varies from roughly 2m to 20m+ (diameter).
The internals of the device use an Arduino (esp32 based) so I imagine talking to ping sonar would at least be straightforward.
Thanks!
That’s correct, although assuming the caves you’re in aren’t rectangular that still leaves quite a lot of unknown information in the corners. How accurate does the map need to be?
If the profile all around is important then it may be worth using a scanning sonar (like our Ping360) instead, although then you would need to make your own distance estimates from the scan data, and your processing requirements and cost would be higher.
I’m interested how you’re doing this. Depth is presumably a pressure sensor, I assume direction is from a gyroscope, and is distance from a tether length or something?
On the “measurement every 100ms” front, note that the Ping Sonar has a beamwidth of 30°, so distance measurements will already be somewhat “averaged” along lengths of the tunnel - reflections come from a region ~50cm long for a wall 1m away, and ~10m long for a wall 20m away.
It’s still useful to have an orientation measurement as close as possible to each sonar measurement, but in a pinch you may not lose much accuracy by measuring less frequently (if for some reason that becomes necessary), especially in the larger cave diameters. A Ping360 has a 2° “horizontal” beamwidth (in the rotation direction), but 25° “vertical” beamwidth so the averaging effect would be similar.
If that’s insufficient for your accuracy requirements you may be able to narrow the beam width by recessing each Ping into a hole, to block sound transmission/receiving from the sides, at the cost of some sensitivity, and less awareness of objects not directly in front of the sonar.
Note that if the walls are quite flat, and perpendicular to the sonar transducer(s), the strongest reflection should come from the small region closest to and directly in front of each sonar, in which case the averaging effect is less relevant.
That’s correct, otherwise there’ll be significant measurement issues due to echoes/neighbouring transmissions.
That may cause some extra measurement uncertainty, but shouldn’t prevent a measurement estimate from being made.
Indeed - Arduino devices can use our ping-arduino library, which should enable quite simple setup, although for an esp32 board you may also need to use a library like EspSoftwareSerial to enable being connected to all 4 Pings at the same time.
Passages and chambers definitely aren’t all rectangular, not by a long shot. That said, it is more important to get a sense of the size of the passage than its precise profile at any given point. Accuracy isn’t hugely important, in the bigger chambers +/- 0.5m would be more than enough and in smaller passages +/- 0.1m would be great. I don’t need a perfect profile so I think the ping might to do the trick. (I looked at photogrammetry but given there’s often turbidity in the water and the problems of lighting I think sonar might be the answer.)
Measurements: depth is pressure sensor, yes, bearing is a compass and distance is based on hall sensors on a prop to measure distance (kind of like a flow meter). For some caves I’m also able to check distance against known points on a guide line in the cave. I can also (usually) run multiple surveys through the same cave to average out anomalies.
The compass also contains a gyro so I can get orientation too and adjust the LRUD (left/right/up/down) measures based on how the diver is holding the device.
Thanks for the tip about espsoftwareserial.
I think the next step for me is probably to get my hands on a ping and see how it performs
Sounds like you’ve done a fair amount of thinking this through - I’m keen to find out how this progresses
That may be ok, although be aware that large amounts of metallic material in the environment (from structures, or perhaps ore veins or something) can result in significant errors in compass readings, so that’s something to keep an eye out for.
Hi @JaspalX, I am always happy to see people working on underwater caves as I had spend a fear amount of time doing so.
It is not an easy problem but I think that you are on the right track for your task. Range measurements form the Ping shouldn’t be a problem and your accuracy will depend from the distance from the walls and the beam footprint at that point. I will agree with @EliotBR to have a second look at the Ping360 as it may give you more information and will remove the need to synchronize 4 sonars.
Normally in caves the major issue is the horizontal localization and 3D orientation of your system because you want to know how to position your measurement to your map.
The orientation can be solved with a MEMS roll/pitch/heading sensor and a pressure sensor. Just take care with the heading because as @EliotBR mentioned, you can get errors from metallic structures (pipes, supports, cement, etc.) or natural iron in the walls.
For the horizontal positioning; In case you have fixed reference points or you know the distances from where you taking the measurements, you are all set! If not, then becomes a much more complicated and expensive task. Maybe this thread gives you some more helpful info.
Thanks for the link, I saw your thread earlier, nice work
I hear you about the ping360, but that’s double the cost…since this is a hobby/project I can just about rationalise the cost of four pings dive gear is already expensive enough )
I just wondered if could explain this (quote below) a little more @EliotBR, as I am also looking to improve accuracy and reduce an interference from other ping sonar. For instance do you know how deep would these recesses would need to reduce interference from other sonar or narrow the beam width? Could these recesses be too deep and cause issues?
The best way to avoid interference between sonars is to not allow them to ping at the same time, e.g.
to
Specific amounts are difficult to judge without testing, because sound is a pressure wave so it will spread out to some extent as soon as it leaves a recess. My intuition is that the transmit and corresponding responses would be something like this:
where the recess increases the initial noise a bit, but reduces the transmitted energy that goes out to the sides (i.e. reduces the beam width), and also reduces energy received from the sides. Whether or not that’s desirable depends on your use-case.
For something like that to work the recess would need to be made of a material that’s quite reflective and/or absorbant of the sound. A significant density difference from the travel medium (water) would help with reflection, and something with density changes throughout would be absorbant - perhaps something like buoyancy foam could be a good candidate.
The main potential issue I can think of would be whether it’s possible for the opening to move fast enough that less/no sound returns in time. I’ve done the return maths before for the ‘completely open’ case in this post, and in the (very conservative) worst-case scenario of an effectively infinitely deep recess the permitted travel distance would be more like the radius of the sonar (~25mm) to still detect the return.
With a target distance d_t, sound speed v_s the echo time is t_{echo} = 2 d_t / v_s. The max travel speed is then
If instead the expectation is say fresh water (v_s \approx 1480m/s) with targets within a couple of meters, v_{tmax} = 9.25m/s. For reference, our technical details specify that the maximum forward speed of a BlueROV2 is 1.5m/s. Given the estimate conservatism, I don’t expect movement speed to be a limiting factor.
Note that if the hole entrance is quite far from the center of rotation of the vehicle/setup, rotations could be a bigger issue than translations, although I don’t expect data collected from a spinning setup would be considered as valid anyway.
It’s also worth noting/considering that the sonar isn’t designed to operate with a highly precise beam. A recess of some sort may be helpful, but is experimental and not guaranteed to work. If tighter spread is an actual requirement then it may be better to get equipment that’s designed for that (e.g. phased array imaging sonars), although understandably that can be expensive.
Thank you very much @EliotBR for the extremely helpful answer!
It sounds like I would need to do some tests to see whether using a recess is beneficial for me, although it does seem like it might be, somewhat, helpful.
Why is it that rotations would be an issue? Is it because with a spinning setup the sonar could be moved into a position where it cannot receive the return echo quicker than if moving in translation?
If the recess entry is far from the rotation center then a small rotation results in a large movement, and if it’s large enough then the return signal could be blocked. I doubt it’s likely to be the limiting factor, but if you’re concerned about it you can do a calculation for max rotation rate given rotation center, sonar position, recess entry position, and target distance, and possibly include movement velocity as well (since if you’re rotating and translating the total movement of the recess entry is greater).
Hi JaspalX, did you make progress on this?
I am looking for a sonar device to be used in cave surveying as well and found the ping360. Would you be interested in getting in contact with me?
I have created a custom dive computer from scratch (hardware and software) running an stm32 mcu and containing a compass, accel, gyro as well as having a can bus connector. Thinking of using that as a platform for creating my own mapping device.
I never did get this sorted I suspect my efforts were a bit more amateur than yours!
I was always struggling with leaks in the housing I used and in the end gave it up to focus on other things (we’re using a mnemo now and will simply take LRUD measurements).
Sounds like what you’ve got would be perfect for the job and as you seem to be able to make a watertight housing I imagine you won’t have the same hassles as me
FWIW I do know of someone who simply took a hand held fish finder and waterproofed it to get LRUD type measurements in a similar environment.
