Analog input - Not getting good readings

Community General Discussions
, ,
1

I am using a Sharp IR Analog Sensor (2 different ones, in fact) and the readings I'm getting on both are not 'correct'. I'm using a PICAXE 28 & a Sharp GP2D120XJ00F or GP2Y0A21YK.

The problem initially was that Mr. First Robot (the beginner robot) was not moving forward. Or, not very often, even when in front was clear. So, I put a debug program on to read all the analog inputs. When I did this, the sensor would read '60'-ish until I put something in front of it and it would go up/down depending on the distance. So, it's 'default' value, when there is NOTHING in front of it is in the 60s, but when there is really something there the sensor then starts reading correctly, descending & ascending as expected.

Any ideas? I have jumpers to ground (I have tried jumpers the other way as well, like shown in the beginner robot walkthrough) on the other 3 analog inputs.

I think it might be the connectors, I used 3 female jumper wires to the JST wires. I just snipped in half and stripped and soldered em to the JST connecter, then electrical taped over em. I have a servo connector, so I'm gonna take off the jumper wires and replace and see if I get better results. Gonna try that now, but any other suggestions will be greatly accepted.

On a side note, I had made changes to the Start Here Robot program to take 3 readings and then average them to hopefully make a better decision, i.e. clean up the numbers a bit. I just wonder if that's a good way to try and cleanup the readings (once it's working correctly, that is)?

Thanks, Happy Holidays

2

its not going to read zero.
its not going to read zero. 60 is right. And the number should get higher when something is near.

3

OK… Didn’t expect that.

I had figured it would read lower, at least. If I put my hand in front of the sensor at about 4 inches, it will read 110-ish, and I can then move my hand away and see the numbers go down to in the 30s-40s at 20 inches.

Since I have the threshold at 40, it would never go forward when NOTHING is in front… That will have to change.

BTW, the put the servo connector on and it didn’t change the input. We were pretty sure when we had it up and running day 1 that the input was not defaulting at 60, but we didn’t take detailed notes. Lesson learned there.

We are going to continue to test out the analog input, we’ve got a speaker setup so while it’s running we will have audible debugging.

Adapt and overcome.

4

I don’t want to disagree, but

I am starting to feel skeptical that the ‘default’ reading for the analog sensor sitting at 60-ish is right. If this is the case, then I cannot see how the program written for the Start Here robot would work.

Example:

When the robot looks right then left, it then decides which way to go based on which value is less, that just would not work. Since if something is 20 inches out to the right and the sensor reads 30 (which it does) while there is nothing to the left and the sensor reads 60 (ditto), using that logic the robot would turn the robot right into the object (again, ditto)…

I’m guessing there is something else wrong, should there be some kind of ‘filter’ in the wiring? I will continue to investigate, but any leads I can get would be great!

Happy Holidays!

5

high

I think 60 is a bit high for the SHARPS. I usually get a reading of 2 or 3 when there is nothing in front and somewhere around 120 when something is rather close. Higher readings with closer objects.

A high nul-reading can also mean there is something near the sensor that reflects the IR light, which can be a part of the bot sticking out or something.

You can try the setup using a multimeter instead of the picaxe. just connect the ground/black and V/red wires to a battery and measure the voltage difference between ground and the signal/white wire. You should read between 0V (nothing in front of the sensor) and whatever voltage your battery is supplying (when something is very close).

 

 

 

 

 

6

Distroy those stupid friggin’ sharps!!!

Ok, I’m better now. I personally have had many, many problems using sharp sensors. That being said, I can honestly say that they will work just fine in the “start here” bot and many others. The bad numbers coming out was indeed one of the problems I had.

My vote is that the 35-50ish numbers at infinity are correct. I always had this and it seemed that the numbers grew as I added more sharps to the same bot. I would also say that no amount of caps fixed this problem or the problem of electrical noise on the ground line.

To fix this:

A sensor

Debug command

Tape or yardstick (or meter stick)

nice smooth, flat white book

Use this little set up to get some good, solid data to use and well… Use it. Just find the “too close” point you want to use, figure out the numer and zjink it into your code. Done.

7

SO are you saying the
SO are you saying the numbers get smaller? If there is nothing then it will read about 60 and if there is something then it should be higher than 60. You can get readings up to 500. I use about a reading of 470 on my hexapod which is about 4 inches. So you have it look right and there is nothing so its a reading of 60 and store that in B1, you have it look left and there is something so lets say a reading of 200 and store that in B2. If B1<B2 then go right else go left. I dont see this as a big deal, my sensor is the same. Maybe in a dark room you can get 0 but i never get a reading of 0 in a room with light.

8

I have a clue…

I went back and looked at the data sheet on the sensor and found that Sharp recommends using a bypass capacitor of 10 uF or more between Vcc and GND near this sensor to stabilize your power supply line. I don’t know if this will address the issue I am having, but perhaps… I am not holding a lot of expertise with electronics, I know what a capacitor is, and generally, what it does.

Now I’ve got to get a bypass capacitor and install, though I’m not sure where. If anyone can lead me in the right direction on where to install, I think I’m going to be making a trip to The Shack.

If others with experience do not think this will help, please let me know. Thanks in advance.

9

8bit or 10bit
Right! 50 or 60 sounds about right if you are taking 10bit readings. I always use 8bit readings on the sharps which will give a value between 0 and 255.

10

Just saw the latest posts

I am only getting readings from 30 - 110-ish when there is an object in front of the sensor, depending on distance (closer the object, higher the number). BUT, when there isn’t anything, that is when I get 60.

If this is how the sensor works for most, how do you accommodate that? Do you throw out anything lower than 60? If there is an object at 16 inches to the right with a reading of b1 = 50 and no object to the left with a reading of b2 = 60, if b1 < b2 then turn right, else left… Most times the robot is turning into the object.

I am also going to debug while the robot is using motors, I am guessing that it making noise that is affecting the sensor as well. Would a bypass capacitor help with that?

More to come… hopefully good results.

11

any way we can have a
any way we can have a picture of your setup or maybe a video and code and the debugging your doing.

12

Sure, here is a photo and the code…

First, here is a photo of the bot:

This photo shows the sensor, but I’m not using a servo connector to plug into analog channel 0, the others have jumpers (in this shot I was using jumper wires). Otherwise, the sensor is in the same place, etc.

Here is the debug code I’m using to look at the values of all the analog channels while measuring distance:

main:

readadc 0, b0

readadc 1, b1

readadc 2, b2

readadc 3, b3

debug

goto main

 

And here is the code I’m using for main operation of the robot:

Symbol dangerlevel = 90 ’ sensor distance value to check for turn

symbol turn = 400 ’ how many milliseconds the body of Mr First Robot turns

symbol servo_turn = 1400 ’ This sets for how long time we should wait for the servo to turn before we measure distance

symbol cycles = 3 ’ number of times the distance is checked before calculating

 

main: ’ the main loop

let w13 = 0

for b10 = 1 to cycles

readadc 0, b0 ’ read distance

let w13 = w13 + b0 ’ sum up the multiple readings into one variable

Sound 1, (b0,5)

next b10

let b0 = w13 / cycles ’ now divide the sum by the number of readings

if b0 < dangerlevel then

gosub nodanger ’ if nothing ahead, drive forward

else

gosub whichway ’ check for a better way

end if

goto main ’ this ends the loop, the rest are only sub-routines

 

nodanger:’ this makes Mr First Robot drive forward

high 7 : high 4 : low 6 : low 5

return

 

whichway:

gosub totalhalt ’ first stop!

 

gosub lturn ’ look left

pause servo_turn ’ wait for the servo to be finished turning

let w13 = 0

for b10 = 1 to cycles

readadc 0, b1

let w13 = w13 + b1

Sound 1, (b2,5)

next b10

let b1 = w13 / cycles

gosub totalhalt

 

gosub rturn ’ look right

pause servo_turn ’ wait for the servo to be finished turning

let w13 = 0

for b10 = 1 to cycles

readadc 0, b2

let w13 = w13 +b2

Sound 1, (b2,5)

next b10

let b2 = w13 / cycles

gosub totalhalt

 

’ Decide which is the better way:

if b1<b2 then

gosub body_lturn

else

gosub body_rturn

end if

return

 

rturn:

servo 0, 75 ’ look right

return

 

lturn:

servo 0, 225 ’ look left

return

 

body_lturn:

high 6 : high 4 : low 7 : low 5 ’ should make Mr First Robot turn LEFT!

pause turn : gosub totalhalt

goto main

 

body_rturn:

high 7 : high 5 : low 6 : low 4 ’ should make Mr First Robot turn RIGHT!

pause turn : gosub totalhalt

goto main

 

totalhalt: ’ low on all 4 makes Mr Robot STOP!

low 4 : low 5 : low 6 : low 7

servo 0, 150 wait 1 ’ hold for one second

return

 

That’s about it… As I had said earlier, I was pretty sure when I first put the robot together that the sensor default value was about 20-ish, Perhaps soldering header pins onto the board did it? I may switch over to another PICAXE 28X Starter Board and see if I get the same results. I don’t currently have a multi-meter, but it’s next on the list.

13

1. try debugging using just

1. try debugging using just the input for your sensor and not the others

2. i see you are using a 3 battery pack and the start here robot uses a 4 battery pack, which most use.

 

14

On comment #2 It would be

On comment #2

It would be within the operating supply voltage with 3(4.5+v) unless he was using rechargables(3.6v)…then there might be an issue.