Fuzzy sonar spinner.

[NOOBinDistress]

I was wandering about fuzzy's top sonar for my 50 dollar robots. How does it rotate like that and should I have mine work like that ? Or should I just put on the very font of my robot? I am not even sure how to program or which sonar to get yet. But I was wandering when I do get it if I should get fuzzy's spinner sonar and if so how to do it. thanks.                                

[Somchaya]

Hmm, if I'm not wrong, Fuzzy's sonar spins because it is mounted on a servo that can do the rotation.

Putting a sonar on a servo like that helps in the sense that you don't need to turn the robot to scan around the area, and servos are a lot more precise that turning on wheels.

However, it makes the mapping (if you're doing that) and calculations a little more tricky since you have to take into account the direction that the sonar is in when you process the sonar data.

[Brandon121233]

A little more tricky is a bit of an understatement, there are a whole lot of angle and trig problems to solve, so unless you borrow someone elses code, it will be quite a task.

Edit- Sorry about that, I just scanned your post really fast, I thought you meant you wanted the robot itself to move back and forth, and as nanoBot said this is very difficult due to the trig involved ( I thought that is what you wanted to do, thats what I get for not thoroughly reading the post), but yes just mounting it on a revolving "turret" would be relatively easy (and it looks neat).

[nanob0t]

A little more tricky is a bit of an understatement, there are a whole lot of angle and trig problems to solve, so unless you borrow someone elses code, it will be quite a task.

Not necessarily.  I'm not quite sure if I understand the concept 100%, but all you would need to do is place an array in your code that stores the values each time you pulse out to the Ultrasonic sensor.  Then you send a pulse to move another few degrees and whatever.  Then you're able to compare the data within the array.

I did this for a robot I won the National Robotics Competition in.  I built a human finding robot.  It was a small robot with a turret, which was mounted an IRPD.  That scanned 13 places within 180 degrees and compared them in an array and moved based on the data.  Also was mounted another sensor (too early to remember), which picked up human body heat, which data was stored in another array as a 0 or a 1.  That was easily programmed also.

[Admin]

yeap, nanob0t is right.

i just command my servo to go to angle X, take a sensor reading, and then store that reading in an array. i'd say the hardest part is just understanding how to program an array . . . no trig was used

you could also fix the sensor on the robot, then just spin the robot . . . but it wont have that much desired evil robot look . . .

FYI - its sharp IR, not sonar, that is spinning on the servo

[nanob0t]

FYI - its sharp IR, not sonar, that is spinning on the servo

I don't know what you are refrencing.  On my robot I used IR, but it was still the same concept of an array.

Yes, and no trig is necessary.  The only math you will need to do is determine how many places you want to scan and divide 360 by it.  This will give you the degree the servo will need to rotate to take a measurement.  If I wanted to scan 4 times in a 360 degree array.  360/4 = 90, so I would have to find a pulse for the servo equal to rotating it 90 degrees whatever.  Then at each spot you have the robot pulse out to the sensor and wait for input, which goes through a calibration equation to output your distance. 

Fixing it to the robot requires lots of trig, though.  You need to find the radius of the wheel and do some stuff with funtacious radians, then compare it to the chassis of ther robot, and if your robot isn't a perfect square, you get to deal with ellipses!  What fun!        




Stick with the servo 

[Admin]

FYI - its sharp IR, not sonar, that is spinning on the servo

I don't know what you are refrencing.

sorry, that message wasnt meant for you but the others before you that called my three sharp IR on a servo 'fuzzy's spinner sonar'

Fixing it to the robot requires lots of trig, though.  You need to find the radius of the wheel and do some stuff with funtacious radians, then compare it to the chassis of ther robot, and if your robot isn't a perfect square, you get to deal with ellipses!  What fun!

i meant that the robot can stop, spin in a circle and map, choose a new heading, then move again. spinning while moving makes it much much harder i agree . . .

[nanob0t]

i meant that the robot can stop, spin in a circle and map, choose a new heading, then move again. spinning while moving makes it much much harder i agree . . .

Hmmm, I have not had good experience with sonar and such.  I don't understand how it could get accurate measurements while rotating in a circle, as the pulse would be sent at one point and be recieve at another point, although rather insignificant due to the speed of sound. 

I figured that you would calibrate it so it would momentarily stop in order to get accurate measurements.  If you wanted a precise map of the room, you would just increase the array and the amount of stops it takes in the room.  Instead of taking just 4 points, it could take 36 at each 10 degrees.  Then just maximize it's efficiency, so it can rotate as quick as possible.

Even when rotating, you have to do some trig, so you can calculate how long it takes the robot to move in a circle around the robot's radius.  Any more and it would be mapping two points twice, and it would get a repeated image.   

[ed1380]

Fuzzy? I though Admin's bot was called Stampy

[Admin]

Ive built 30+ something robots in the last 5 years, but only named like 15 of them (6 of those had the same name), and only documented about 10 of them . . .

http://www.societyofrobots.com/robots.shtml

Stampy
http://www.societyofrobots.com/robot_sumo.shtml

Fuzzy
http://www.societyofrobots.com/robot_omni_wheel.shtml

[Hal9000]

Ive built 30+ something robots in the last 5 years, but only named like 15 of them (6 of those had the same name), and only documented about 10 of them . . .

http://www.societyofrobots.com/robots.shtml

Stampy
http://www.societyofrobots.com/robot_sumo.shtml

Fuzzy
http://www.societyofrobots.com/robot_omni_wheel.shtml

Fairplay! I didn't realise it was that many!

[Brandon121233]

In reply to nanobot, I really dint think that rotating sonar would be any less accurate for three main reasons:
1.) Its not that accurate to begin with, the most precise hobby sonar device I have ever really seen is accurate up to a 1/4 inch resolution.
2.) The speed of sound at sea level is 13397.2441 inches / second (or 1116.43701 feet / second), and seeing that most sonar units can't measure distances over 25 feet that means it takes roughly .0448 seconds ( .0224 * 2) to get back, the turret or rotating robot would have to be traveling extremely fast to miss the signal.
3.) I'm fairly certain that sound waves spread out as they travel, so even if the sonar was moving, it would probably pick up the wide signal.
If I'm wrong in saying any of this someone please correct me

[nanob0t]

I realize what you mean.  Just me being a perfectionist, I have to have everything as precise as possible.  It's just my opinion 

I know that sonar isn't very accurate to begin with, but why mess with messing up that value even more?  If you would like me to do the math and show you how much of the signal will be lost, I can    I realize it's not much, but the odds of it spinning slowly is low.  If you have one motor going foreward and one backward, unless you developed a slow moving robot, the thing is going to fly.

Sound does dispurse when it enters a medium, but the sensor is looking for the centralized point.  When you move a fraction over that time period, you get off center.  It would be fine if accuracy wasn't a big factor.  I don't know, I'm one for being precise.

The biggest factor, is you're going to play with lots of radians and trig.  Your sensor wont want to pick up two similar images.  Reason:  If your robot wants to go to the area of furthest distance and it moves 400 degrees, and the furthest distance was withing the first 40 degrees, you know have captured the furthest distance twice.  Between 0-40 and 360-400 degrees.  Then your robot has to choose.  Then if it decides to go 40 degrees to the CW, it already is 40 degrees CW, and will rotate another 40 degrees, which sets everything off.  It's more issues with math and motors

[Admin]

actually, you can mathematically account for the robot moving while you scan . . . it requires knowing robot velocity and comparing that to the sensor update rate.

as for precision, ideally you want the lowest precision possible without causing your robot to fail, not highest. higher precision slows your robot down, and makes algorithms take much longer to process (floating point, for example).

in the manufacturing world, every decimal point of precision your robot has is an extra decimal point in price
If you can manufacture something with less precision, it could save loads of money . . .

[nanob0t]

actually, you can mathematically account for the robot moving while you scan . . . it requires knowing robot velocity and comparing that to the sensor update rate.

as for precision, ideally you want the lowest precision possible without causing your robot to fail, not highest. higher precision slows your robot down, and makes algorithms take much longer to process (floating point, for example).

in the manufacturing world, every decimal point of precision your robot has is an extra decimal point in price
If you can manufacture something with less precision, it could save loads of money . . .

Very true. 

I guess what I mean, is having the robot do what it needs to do the best it possibly can.  You want to work everything out of the robot, so it lacks flaw.

By precision, I didn't mean numbers after a decimal.  It doesn't need to know if something is 13.48273475 far away, or needs to rotate 30 degrees and 15' 57'', unless you need to have that much accuracy.  I just meant, that if you fail to take the time to do the math and think up everything, your robot may spin around and think it's taking a distance measurement every 20 degrees, when it's actually spinning 25 because you were lazy.  Then it adds up and it's completely flawed. 

It would be better working out everything before hand and having a working robot that is accurate to your requirements of it.  I have to have everything as precise as possible to my requirements of it.

[Admin]

Your robot will always have some error, this is impossible to avoid.

The point of precision right before failure is best, no more precise, no less . . .

For example, your robot could fail at .01, work at 0.001, and just cost a lot more but not function much better at .0001.

I personally try to design my robots to work at 10.0 cause its the easiest and is acceptable error for my particular applications