I have a HC-SR04 rangefinder which should not even work but somehow it works perfectly on ground upto 4m and then in flight it goes crazy even when something is in range, reading 0. It uses GPIO to communicate on the trig and echo pins. so I suspect lack of echo signal on the rangefinder in flight but i need to verify this. Weirdly, the stat is 4 which means good signal which suggests proper functioning of the rangefinder, but the quality is -1, meaning invalid. the readings works but then spikes down to 0 very often
So, is there some way to log the GPIO signals? The transmitted data on the trig from pixhawk and the echo signal input?
In the log RCOU messages it detects the pin as GPIO (verified by the text that comes on hovering over the pin) but its value stays 0
Hm, what is a random module.
Especially on Amazon, every product has a manufacturer’s identifier, a reference number, and an Amazon internal product number (ASIN).
How you testet the range? What kind of objects? Moving or steady?
The HC-SR04 Ultrasonic Distance Sensor provides very short (2CM) to long-range (4M) detection
I had a look to the ardupilot source. The update rate of the trigger impuls is 15Hz => period 67ms.
The distance is calculated on 58µs / cm. So this is a absolut maximum distance of 11,55m which ardupilot theoretically can measure. Also ardupilot has a relative simple inbuilt glitch filter. It still rejected any rapid changing values with a change from one measurement to the next greater than 0,5m. And last ardupilot sets the distance to 0 if measurments missed for more than a second.
This are just only the limits from ardupilot firmware.
If you are able to built your own firmware it is possible to change any code.
So you can just try to comment out the line state.distance_m = 0.0f;
in file ardupilot/libraries/AP_RangeFinder/AP_RangeFinder_HC_SR04.cpp
But if you do it on a copy of the master brunch you also will get all other firmware changes since your actual version. So be carefully to select the correct version you want.
Also the expected behaviour is that you always get the last measurement but you don’t get any information how old is this information
From a previous issue with compass I had cloned entire copter 4.6.3 stable
So it shouldn’t be a problem
I looked into the code as you mentioned and it only sets to 0 when it fails, if it gives valid reading then it passes the valid reading again. But, in my case the readings very often fall to 0 which can be fixed but sometimes they work and they set to 0 and never climb back. This should not be caused from the code as per my understanding, so it could be hardware. According to me, I need to log the gpio pin status so I can see in the log what happens when it fails, like stopping of echo, failure to return, or something else. So, can I log a GPIO without LUA since the Pixhawk cant run LUA?
I removed the distance setting to zero line.
Also with these cheap sensors (some others I have used with unos) read 1183 when no obstacle is there and I suspect mine to be doing the same
I increase the 67ms in some if line in the rangefinder code to 70 which allows 1183 in range
Now weirdly, it reads correctly on start and then reading stays stuck there until I reboot and then the new reading comes and stays there stuck what to do??
In a test flight it seems to be working weirdly:
It is not clear to me what you meant with “read 1183 when no obstacle is there”.
How is your measurement setup. You pointing with sensor in a complete free room with no walls or other things reflecting the waves?
Value 1183 you meant 1183cm?
On ardupilot the measurement calculation is triggered by the returning signal. If no echo is coming no update, so far I understood the code.
This is only answering part of my question.
Where you are pointing with your sensor in the test mentioned above? You are pointing to nowhere or to wall some meters away? How exact was your test?
Do you have the possibility to monitor the “Echo” pin on the module parallel to ardupilot.
If the the walls are 20-25m away they are far out of range. So the module didn’t trigger the ardupilot update routine. So the your above described behaviour is as expected
