Hi All
I have some weird readings for the surface depth in QGC : some times around -4 meters, some times around -9 meters.
So I tried to run the pressure sensor calibration and ended with that errors :
EKF2 IMU0 forced reset
EKF2 IMU1 forced reset
So I ran all sensors calibrations. Same problem occured and still the same surface depth weird readings.
So I upgraded Ardusub and ran again all calibrations, same problem…
This is the log :
Resetting the kalman filters that estimate the vehicle’s motion/position state makes sense when you re-calibrate your depth sensor, otherwise they might register a significant acceleration that was actually caused by re-setting the depth zero-point. Note that it’s a warning not an error - the calibration was successful, so the EKFs are reset to start fresh with the new calibration values
That’s definitely an unusually large offset and range, and if the pressure or measurement time wasn’t actually significantly different between those readings it would suggest to me that your Bar100 might be damaged/faulty.
Note that the Bar100 has a \pm500 mbar accuracy, so depth calculations based on it can conceivably be off by up to ~5m if it’s not calibrated. Its precision is 3mbar however, so it should be able to measurably detect ~3cm of depth difference in fresh water. When the depth calculation is calibrated to a given pressure (the barometer calibration you ran), the estimated depth from that point should be accurate to within the precision amount (subject to water density differences, which shouldn’t be particularly relevant for measurements at/near the surface).
I’d suggest you try putting the ROV in some water and watching the depth readings. If it’s just an offset issue (e.g. caused by different air pressure from the initial calibration location+time) then the calibration you did should solve that, and the readings should reasonably accurately reflect the depth the sensor is at (you can try pushing it down into the water a bit to see the variation).
If the measured depth is varying from what it should be after you’ve performed an offset calibration then there’s likely something wrong with the sensor, in which case I’d recommend you contact support@bluerobotics.com, and link them to this thread. They can help make sure if the sensor is damaged, and are the people to talk to about a potential replacement or refund
I have a Bar100 connected to an Arduino UNO with a level shifter, but when I upload the example code in the BlueRobotics KellerLD Libary I get readings that (with the exception of temperature) are very off considering I’m running these tests just a couple of meters above sea level. The altitude reading in particular seems to fluctuate substantially from one reading to the next:
Sensor in air
Pressure: 45.78 mbar
Temperature: 23.45 deg C
Depth: -9.90 m
Altitude: 19730.47 m above mean sea level
Pressure: 42.72 mbar
Temperature: 23.40 deg C
Depth: -9.93 m
Altitude: 20051.02 m above mean sea level
Sensor in 1 cm water
Pressure: 42.72 mbar
Temperature: 22.35 deg C
Depth: -9.93 m
Altitude: 20051.02 m above mean sea level
Pressure: 39.67 mbar
Temperature: 22.30 deg C
Depth: -9.96 m
Altitude: 20390.68 m above mean sea level
This sensor has never been connected directly to the Arduino without the level shifter, but after testing with the Arduino I tried connecting it directly to an Adafruit Feather M0 Adalogger (without the level shifter) and received the same type of readings.
I’ve moved your post here because it seems to be on the same topic. I would direct you to my response above, with the additional note that an “offset calibration” in the case of the Arduino doesn’t seem to be something that’s built in to our KellerLD Arduino library, so you would need to just take a measurement at the surface and use that as your depth offset / zero value.
The depth and pressure measurements don’t seem to fluctuate too much, so it should be no problem to zero them. But does this mean I can only obtain relative, not absolute, pressure values? And given that the altitude reading fluctuates with a couple hundred meters from one reading to the next, is that simply the level of accuracy it has?
The Bar100 uses a Keller 7LD-PA sensor, which (according to the sensor datasheet on our product page) is an absolute pressure sensor with a zero-point at 1.0 bar. That said, pressure at sea level is dependent on weather, temperature, and location, and is not guaranteed to be exactly 1.0 bar (“standard” is 1.01325 bar), so accurate depth and altitude estimates based on the pressure measurement will likely need an offset calibration.
The sensor has a resolution of 3mbar, so the smallest detectable data change should be roughly 25m of altitude difference at mean sea level (~1013.25 mbar), but having looked at your provided values again they’re seemingly far below that. That’s clearly incorrect, but the valid pressure range of the sensor is from mean sea level pressure and up (from the datasheet), so potentially the readings should become valid a little deeper in the water. If not, there may be something wrong with the sensor, or perhaps the pressure values are being calculated incorrectly or something. Are the P_min and P_max values 0 and 100 bar, or something else?
As pressure approaches 0 (vacuum) the altitude increases as a power relationship, so at very high altitudes small pressure changes represent large altitude changes, which is why it’s varying by so much (given the pressure values being output). Water depth is linear with pressure, so that calculation is much simpler, and can have an offset adjustment equally well in the underlying pressure or in the calculated depth, whereas that doesn’t apply for the altitude estimates (which need to be adjusted in the pressure).
Thank you for the explanations!
The P_min and P_max values are 0 and 100 bar, and I just got a chance to test the sensor in 1m deep water. The resulting change in the pressure readings seemed to make sense (the depth I calculated from it was in the right ballpark) so hopefully there isn’t something badly wrong with the sensor itself and a surface-pressure offset should work, at least to obtain relative pressure measurements. I hope to be able to run more thorough tests in deeper waters this autumn, and if I can get my code in decent shape, share a simple script to get out corrected pressure and depth values in case anyone else runs into similar issues when using the sensor with an microcontroller.
If you’ve been testing it by pushing on the front with a finger or pen or something, or if it’s been hit by something then it’s very possible the diaphragm has been permanently deformed, which could explain the offset you’re seeing. I’m told sensor damage like this is an issue others have run into before.
As I mentioned in my first comment in this thread, the sensor accuracy is expected to be within \pm 500 mbar, and at roughly atmospheric pressure yours is seemingly off by about double that, so that’s at least cause for some consideration as to whether the sensor is otherwise behaving as expected. If possible it may be worth comparing the readings with a different sensor to see whether or not they’re consistent
Apologies for the late reply - I managed to get in touch with the distributor I bought the sensor from: they confirmed that they also use an offset, but that their raw values are around 981-1091 mbar. They also suggested that the sensor or wires might be damaged, but that they may not be able to fix this.
I did very gently press the front of the sensor with my thumb (values changed by 3-5 mbar), but only after I noticed the strange values (I found the suggestion on this forum somewhere, to see if the sensor was registering pressure changes at all). Other than that I’ve kept the protective cap on at all times (except when testing) - the way it was when it arrived in the post.
Unfortunately I don’t have another sensor to compare it to, and the funding for this research project is too limited to afford a new one - is there any chance the sensor could be repaired…?
If you expect it most likely arrived with the sensor damaged then I’d recommend you contact support@bluerobotics.com, to see if there’s anything we’re able to do.
Fair enough.
Unfortunately I don’t believe it’s repairable, and if it is we wouldn’t be doable by Blue Robotics.
If a thin diaphragm has been misshapen then I expect the only way to fix it would be to disassemble the sensor element itself, before reforming it and re-calibrating it, which would likely need to be done by Keller (if it’s even possible), and at the end it would effectively be a new sensor that was extra expensive to produce.
If you’re able to do an accuracy test (even just with a ruler in a tube/tank, or similar) you can determine whether it’s working sufficiently well for your purposes with an offset. If not you can try contacting our support email
temperature (assumes degrees C but can be anything)
pressure (must be in mbar)
As output you get
A .csv file containing the original values plus the corrected measurements (columns: Timestamp, Temperature, Original mbar values, Corrected mbar values, Correct depth in m)
A .png file of a plot showing the temperature across time
A .png file of a plot showing the corrected pressure measurements across time
A .png file of a plot showing the corrected depth measurements across time
If you do so, please include the order number (or at least rough order date), and a link to your original comment (for context)
Fair enough. The communication is digital, so the values the microcontroller reads can only be changed by the sensor itself. Accordingly, assuming the calculations are correct then the only plausible reasons for consistent incorrect measurements are the sensor being damaged or faulty, or if it’s being used outside its operating conditions (an overly high or low voltage is perhaps the most likely issue), but if you’ve tried multiple level converters and microcontrollers then the power supply seems unlikely to be the cause.
Given we’ve been selling the Bar100 for several years it’s unlikely the library calculations could be off so significantly, so it seems most likely that you have a faulty or damaged sensor.
