2
$\begingroup$

Been working on a robot recently which uses ultrasonic sensors for an integral part of the navigation. While testing the sensors I noticed a strange behaviour, the sensors seem to frequently stop functioning and bring the entire Arduino Mega I'm working with to a stop. The strange part is that these stops seem to be entirely random, on some occasions the sensor will read values consistently (at maybe 20 vals per second) for 10+ seconds, then all of a sudden the sensor will slow to reading only 2-3 values per second with stalls between.

I have tested several sensors and different codes for pinging distances yet the problem has persisted.

This leads me to believe the issue is with the arduino mega itself, but I am unsure how to verify this. Any advice? Thanks in advance!

PS: other pins on the Mega seem to be working fine, i.e. analog pins for IR reflectance sensors and PWM pins for driving 2 DC motors.

Improve this question
$\endgroup$
3
  • $\begingroup$ Just tested the sensors using the PWM pins on the mega and problem is persisting, although this pins do work fine for driving motors... Maybe the issue is with the sensors after all. $\endgroup$
    – Nolan Rempe
    Mar 22, 2015 at 5:32
  • $\begingroup$ Can you post the code that you are using? $\endgroup$
    – jrcatbagan
    Mar 22, 2015 at 18:59
  • $\begingroup$ Using this library: playground.arduino.cc/Code/NewPing More specifically the median() and convert_cm() functions in the following statement: Serial.println(frontUS.convert_cm(frontUS.ping_median(3))); Where frontUS stands for the ultrasonic sensor at the front of my robot. $\endgroup$
    – Nolan Rempe
    Mar 23, 2015 at 7:49

4 Answers 4

Reset to default
4
$\begingroup$

You said, "on some occasions the sensor will read values consistently (at maybe 20 vals per second)".

20 values per second is 20Hz. This means that you are polling every 50ms. In the datasheet linked in the other response, it says,

"we suggest to use over 60ms measurement cycle, in order to prevent trigger signal to the echo signal"

In the operation discussion it says the your 10$\mu$s pulse starts the "sonic burst", after which the sensor raises the echo bit. You are watching for that echo bit to return to zero; time raised determines distance. What it appears that you are doing is polling the sensor too frequently. The trigger signal causes another sonic burst, which raises the echo pulse a second time. This could overlap the first pulse, resulting in a signal that stays high.

Your "maybe 20 vals per second" could also be the reason for your intermittent issue; if you're not using a dedicated timer (interrupt) to initiate the polling, then you're at the mercy of whatever other logic you have running on the microcontroller.

You could (good solution) use an interrupt to trigger the polling and to measure the signal length, or you could (bad solution) add some meaningless math calculations in your code in an attempt to increase the time between sensor function calls. Bad solution is bad, but it could be handy to help troubleshoot. You're looking for a value of about 10Hz; 15Hz is right on the border of instability for the sensor. Of course, if you could reliably count on polling to go off at a precise interval cough interrupt cough then borderline cases are very manageable.

Improve this answer
$\endgroup$
2
  • $\begingroup$ The project's over now but thanks for the help, if I continue to fool around with robotics using these sensors I'll try and implement some sort of interrupt method so that the bursts don't interfere with each other. Cheers $\endgroup$
    – Nolan Rempe
    May 22, 2015 at 20:52
  • $\begingroup$ Sorry, hadn't noticed the date on the question. I was browsing through unanswered questions and figured I'd offer my two cents. I've had issues in the past with clock/polling timing that caused erratic behavior like you describe. Anyways, best of luck in the future. Hope your project went well! $\endgroup$
    – Chuck ♦
    May 24, 2015 at 16:54
1
$\begingroup$

I think that the strange behaviour that you are experiencing comes from lost echoes. The HC-SR04 is at it's best performance with obstacles of 0.5 square meters (you can check this in the data sheet). With smaller obstacles some of the echoes at random wont be detected. The sensor waits for echoes to return up to about 182 mS no matter how fast you trigger it. Only then the echo signal goes low if no echo is detected. I have checked this behaviour by free triggering the sensor at different rates and watching the echo signal at the same time with an oscilloscope.

Improve this answer
$\endgroup$
0
$\begingroup$

Looking at the signal waveform in the datasheet of the HC-SR04 ultrasonic sensor, we can see that measuring the "echo back" pulse is proportional to the distance between the sensor and the object in front. enter image description here

To be able to time this "echo back" pulse, this would require the use of an interrupt and a timer which is ubiquitously found in many microcontrollers. That is an interrupt will be used to detect the rising edge of the signal to start the timer and the falling edge of the signal to stop the timer.

Assuming that you are using the Arduino Mega 2560 (the concepts can also apply to the Arduino Mega as well), browsing through the datasheet of the ATmega2560 microcontroller found on the board, the Input Capture Unit elaborated on page 140 will be able to achieve this task.

It is very critical that you time this pulse with an interrupt. The microcontroller can only execute one instruction at a time, so using a regular input/output pin and polling the pins to time this pulse could introduce latency into the system. For example the code could be executing at some other place in the program and at the same time there is a change in the pulse signal, thus effectively missing the measurement and producing an incorrect result.

What you need to do is figure out whether the code you are using is employing the Input Capture Unit. If not,then see how the Input Capture Unit maps to the header pins of the Arduino Mega 2560 and how to enable the feature in the code (e.g. using an Arduino library, statements, etc.)

Improve this answer
$\endgroup$
1
  • $\begingroup$ Hey @jrcatbagan, thanks for the help. The code I'm using is a simple function called PulseIn which uses a timer to measure the time between a HIGH and LOW reading on the same pin (details here: arduino.cc/en/Reference/pulseIn). The strange part is that this function allows for a timeout value, which should theoretically break the timer if we exceed the given timeout value. When playing around with this value I found that irregardless of how large or small this value was, the sporadic behaviour persisted. At this point I'm just very confused, and I appreciate the help. $\endgroup$
    – Nolan Rempe
    Mar 22, 2015 at 18:14
0
$\begingroup$

I had similar issue recently and it looks it's rather hardware related problem (power of input source???). As you see on pictures below the width of the echo pulse has been sent inconsistently across measurements. I had it powered from Arduino Mega 2560 board (digital +5v and gnd), but it shouldn't cause such issue by me. When I was trying to connect external 12V to the board it got fired :( so I have to order new one board and then to repair the first one unit...)

The shorter one pulse is below (see measurement values on the right side of the picture). The upper wave is Trigger line, the lower line (channel 1) is Echo line...

enter image description here

This is the longer one pulse: enter image description here

The test has been done against normal wall. The interesting point to notice here is it contains (more or less) two values only when the second one is almost twice as the first one value...

Edit after receiving the new one board:
I have connected regulated power source to vcc ofhc-sr04 with values equal to 5.0V and 5.1V and it didn't change the behavior of echo line. It looks this chip doesn't know how to deal with reflections or something similar so it can work on very short distances only (up to 30 cm?) or maybe less :(

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.