Line follower sensor and ultrasonic sensor

#1

I tried using the line follower sensor and ultrasonic sensor to create a line follower car which will display the red LED light, and stop (see the code in pic1) or run backward (see the code in pic2) when there is an obstacle in front of the car within 3 cm. I found that the car sometimes (or even often) displayed the red LED light, and stop or run backward while there is no obstacle in front of the car within 3 cm, and sometimes I have to put my hand in front the car and move my hand more than 3 cm in front of it to make it move forward again, but then it will display do such action again though there is no obstacle in front of the card. Is the ultrasonic sensor out of order? Or any coding skills/technique about the ultrasonic sensor thatt could help to resolve such problem?

pic1.
Uploading…

pic2
Uploading…

#2

pic 1.

l_u_01.png585x608 36.5 KB

pic 2.
l_u_02.png643x771 55.9 KB

#3

@Chi_Man,

Your code looks fine, I don’t think this is the problem. Both of your examples use the same logic, but control the motors differently.

What is the size of the object that you are putting in front of your mBot. If it is too small, it may not be returning a strong enough signal for the ultrasonic sensor to pick up. If the sensor does not detect a signal, I believe it return a zero. I would suggest something flat, like a book or a box maybe, about the size for the mBot or your hand should be fine.

Good Luck,

Mike

#4

Thanks for your opinions!

But my problem is that the mbot car sometimes (or even often) displayed the red LED light, and stop or run backward while there is no any obstacle in front of the car within 3 cm. The mbot car seems doing the logic of meeting an obstacle while there is really no obstacle in front of it. How should we resolve these problem?

#5

3 cm seems a bit close to me to get reliable distance readings. Maybe try 10cm.

Also, I read from the forum that the sensor sometimes returns zero if it is read very often. The advice was to repeat the reading until you get a non-zero result.

#6

Dear all,

Thank you for your opinions!

I have tried to amend the contraint that when the mbot car detect an obstacle, where it’s distance is greater than 0cm and less than 10cm (refer to pic1), then take action such as run backward, to cater for the case where the ultrasonic sensor reading is 0. But still when I remove the obstacles, the car run along the black line as the line follower does, then it take such action (run backward) again when there is no obstacle in front of the mbot car. I am very frustated about the ultrasonic sensor, how should I resolve such problem? Can anyone help? Thank you!

l_u_03.png711x743 57.6 KB

#7

Drop the “and” and just check to see if you are within 10cm. I’d also suggest creating a “detectObject” block that reads the ultrasonic sensor, and immediately re-reads it if you get a zero. Also, pausing for 0.02 seconds will give the ultrasonic sensor time to take a more solid reading. I have a chapter in the eBook I recently published (link) that discusses these details if you are interested.

#8

Also, run the code native in C on the device and not from wireless/Bluetooth. You’ll get much better I/O response

#9

The ultrasonic sensor is a repackaged HC-SR04 sensor. When you trigger it, if it does not detect anything, it returns a value of zero[1]. Therefore the check for “dis > 0” is needed. Added a delay would help.

[1] I’m pretty sure that under the covers, the “pulseIn” function is being called, and it returns zero if a pulse is not detected in the allotted time, see https://www.arduino.cc/en/Reference/PulseIn.

#10

I guess my understanding of what he wants to do is to back up if the robot is within 10cm of an obstacle. Since there is no other action for being at zero cm, I wouldn’t bother adding extra code to check for it. However, your mileage may vary. :slight_smile:

#11

Amen, over-the-air lag times are damning.

#12

I should mention that you can simplify your code further. If you are using the mBot as you mentioned, there is a block that is essentially doing the same thing as the code in your custom blocks.

The block is [run forward/turn right/turn left/run backward] at [speed]. Under the covers it takes care of negating the motor speeds for you which will help eliminate any errors that might be caused by a typo. You can also isolate the speeds into a parameter of the custom block or declare variables and set the values so that you only have to change them in one place.

You might also ask yourself about the value of setting dis to zero and then immediately doing a read on the ultrasonic sensor. sense the read will immediately overwrite the value of dis.

Here are the edits I’d make:

mBotHelp.jpg639x587 109 KB

Note that I keep the custom blocks for readability, but given that there is only a single instruction in each one, you might want to opt for just embedding the blocks directly into your if statements.

Regards,

Chuck

#13

Dear all,

Thanks for your information!

I amended the code to handle such problem by re-reading the distance from ultrasonic sensor when it is 0 reading after 0.02 seconds of the first reading, besides, I set the constraints as the dis>5cm and dis <9cm for checking any obstacle within 5 to 9 cm, and I found that it works, the mbot robot won’t do take any unnecessary action (backward) while there is no obstacle in front of it. For the take action part, running backward is just only for checking, the ultimate goal is to avoid the obstacle and run passing it without touching the obstacle and the mbot robot return to the black line and do the line following again, which I am still thinking (and testing) how to code it. Thank you for all your help!

#14

The trouble is that the read ultrasonic sensor returns a zero if the distance is beyond the range of the sensor (i.e. the pulseIn timed out). I did confirm that the underlying code is using the Arduino pulseIn function, check line 165 at https://github.com/Makeblock-official/Makeblock-Libraries/blob/master/makeblock/src/MeUltrasonicSensor.cpp.

Regards,
Aram

How to know distance mBot travels?
#15

Yeah, it might be better to create a detect block that factors all of that out, possibly setting a obstacle detected flag if not zero and saving the value in a variable. Then other blocks can make decisions based on that information.

Ultrasonic_Detect_Object.jpg744x370 82.1 KB

#16

Minor update. It seems the ultrasonic sensor block as of 3.4.5 returns 400 if nothing is detected within its range.

#17