PING)) Object with Temperature Compensation and More
Duane Degn
Posts: 10,588
As I mentioned in the OPP #8 thread, I've built a robot using Parts Parallax sent me in exchange for updating the Eddie code to use different hardware.
While the task of improving the motor control algorithm didn't necessitate my using Ping sensors, I decided I'd have more fun with the project if my robot could better sense its environment.
I found the original Ping code used in the Eddie software was susceptible to problems caused by Ping sensors interfering with one another since all the Pings were triggered at once.
As part of modifying the Ping section of the code, I ended up rewriting the Ping.spin code in the Propeller library to include "Eddie Units". A Ping measurement in Eddie Units is the time in clock cycles it takes the pulse to travel to and from a target divided by 512 (right shifted 9-bits).
Since I was modifying the code to use Eddie Units anyway, I decided to make some other changes. These changes include the ability to set the value of the speed of sound used to calculate distances and also includes the ability to approximate the speed of sound based on temperature.
Besides the ability to measure distances in milliseconds, millimeters, centimeters and inches found in the previous Ping code, I added the previously mentioned Eddie Units and I also added a method which will return the distance in units of tenths of an inch so us Imperial units fans can also measure distances precisely.
I've attached two demos for this new object. The demo included in the zipped archive displays the distance read by the Ping sensors in each of the units.
Here's the output.
The other demo displays the readings from two Ping sensors while continuously changing the temperature used to compute the speed of sound.
Here's some example output from this demo.
I plan to incorporate this Ping object into the new Eddie code.
It will be interesting to incorporate some sort of digital thermometer so the Ping object may be adjusted based on the current temperature. I think it's very likely one can improve the accuracy of distance measurements by adjusting the speed of sound parameter appropriately.
While the task of improving the motor control algorithm didn't necessitate my using Ping sensors, I decided I'd have more fun with the project if my robot could better sense its environment.
I found the original Ping code used in the Eddie software was susceptible to problems caused by Ping sensors interfering with one another since all the Pings were triggered at once.
As part of modifying the Ping section of the code, I ended up rewriting the Ping.spin code in the Propeller library to include "Eddie Units". A Ping measurement in Eddie Units is the time in clock cycles it takes the pulse to travel to and from a target divided by 512 (right shifted 9-bits).
Since I was modifying the code to use Eddie Units anyway, I decided to make some other changes. These changes include the ability to set the value of the speed of sound used to calculate distances and also includes the ability to approximate the speed of sound based on temperature.
CON '' Temperature Effects on Speed of Sound
{{
The speed of sound in dry air is approximately:
speed of sound = 331.3 + 0.606 * temperature
with temperature in units of Celsius
@25C speed of sound is 346.45 m/s
14.83 C at 340.29 m/s?
340.29 m/s is the value given by Google for the
speed of sound. This is used as the default
centimeters per second speed value.
The speed used to compute distances may be
changed with the "SetSpeedOfSound" method.
}}
Besides the ability to measure distances in milliseconds, millimeters, centimeters and inches found in the previous Ping code, I added the previously mentioned Eddie Units and I also added a method which will return the distance in units of tenths of an inch so us Imperial units fans can also measure distances precisely.
I've attached two demos for this new object. The demo included in the zipped archive displays the distance read by the Ping sensors in each of the units.
Here's the output.
This program "PingUnitsDemo141206a" demonstates the various units available when readings distances with the object "EddiePing141206a". Inches = 49 in, inches = 49.9 in, centimeters = 126 cm, centimeters = 127.0 cm, microseconds = 3730 us, Eddie Units = 1165
The other demo displays the readings from two Ping sensors while continuously changing the temperature used to compute the speed of sound.
Here's some example output from this demo.
This program "PingTemperatureDemo141206a" demonstates the temperature compensation feature of the object "EddiePing141206a". The temperature used to compute the speed of sound is now set to 27.0 C The speed of sound value used to compute distances is 34766 centimeters per second. Sensor # 0 = 128.0 cm Sensor # 1 = 130.0 cm
I plan to incorporate this Ping object into the new Eddie code.
It will be interesting to incorporate some sort of digital thermometer so the Ping object may be adjusted based on the current temperature. I think it's very likely one can improve the accuracy of distance measurements by adjusting the speed of sound parameter appropriately.
Comments
Jim
According to my research (reading the Wikipedia page about the speed of sound), altitude doesn't have much effect on the speed of sound.
I couldn't find a formula on how to compensate the speed of sound for humidity but I did find some tables listing the speed of sound at different pressures and relative humidity. As one would expect, the warmer the air, the greater the influence humidity can have since warmer air can hold much more water than cooler air.
At 25 C, the difference in the speed of sound between 10% humidity and 90% humidity is 1.4m/s. This is the same change in the speed as is caused by changing the temperature 2.3 degrees Celsius.
So humidity has an effect on the speed of sound, just not a large effect. While I doubt it's really worth the bother to worry about the changes caused by humidity, if I could find a formula which would accurately compute the change in the speed of sound based on humidity, I'd probably add it to the program.
The speed of sound is affected by the temperature and air pressure at different altitudes, not the altitude, so what you really need is a barometric pressure sensor (and the bonus is that you can calculate the altitude, or elevation, from that - but the accuracy depends on a lot of other things).
Again, from what I've read, air pressure has little effect on the speed of sound. The temperature of the air is the dominant factor influencing changes in the speed of sound in conditions we mortals (and most of our robots) are likely to encounter.
So if one have some sort of complex set of instruments and equations to go with them, the speed of sound could be computed by the parent object and then sent to the child "Ping" object to use the new speed of sound value in its calculations.
The program will recompute the conversion factors based on this new value for the speed of sound.
No matter. Am I right in remembering that the Ping works at about 40 kHz? If that's the case, that sets your maximum resolution, which is actually fairly coarse for ultrasonic distance measuring. I'ma thinkin' it's already above the differences barometric pressure and possibly typical room temperatures (typical for robotics) will affect you. That said, it would be interesting to see the math. If anything, I'd think variances in barometric pressure to have an almost negligent difference, given the resolution a 40 kHz wavefront can provide. Pressure can likely be safely ignored. The remaining question is whether variations from (say) 60F to 90F -- typical of conditions used in robotics -- be detectable, given the overall resolution of the sensor.
I think the difference between 60F and 90F would be detectable. A 30 degree F change would change the speed of sound by about 3% (if I did my math correctly).
If your obstacle is a meter away, the 3 cm error produced from using the wrong value for the speed of sound may or may not be significant but personally I'd like the extra accuracy.
At 40KHz and with the speed of sound 33130 cm/s the wavelength of the sound comes out to be 8.5mm which is about the resolution I get from a Ping sensor. I don't think it would be unusual to have the error from the using the wrong value for the speed of sound to be larger than the error inherent in the sensor.
I can certainly see why it's not common to worry about these small changes.