Let's Make Robots!

"LoMoR" - Lets Orientate & Map Our Robots (Sonar Based)

"LoMoR" - Lets Orientate & Map Our Robots (Sonar Based)

 Also Blogged as Mystery Object Here

My System Uses a LCD display to Map an area which is scanned by an Ultrasonic or IR Distance_ing transducer.

The Angle of the Probe is converted from polar Coordinate to Cartesian Coords and then displayed X,Y fashion on the LCD Display.

The System works pretty well i must say, however the "Extra" echos of Ultrasonic signal can be miss-leading.

What is super cool is being able to see what the Ultrasonic or IR sensor sees - it sees a lot more than you would think, or should i say Too much more!!

I am not sure what the overshot areas on the plot are yet. (maybe i have to mount the transducers sideways).

I mounted the Ultrasonic Transducer Vertically and it gave slightly better result - the plus point is the transducer can pivot better around itself.

Basic system is so:-

  1. Arduino - LCD walkthrough
  2. GLCD based display
  3. Data Sheet for KSO108B
  4. Ultrasonic or IR Distance Transducer connected to a servo.

My code_ing works this way :-

  1. Servo scans with attached Ultrasonic or IR sensor taking distance measurments
  2. From this you have the angle of the servo with distance to object
  3. Convert the Angle of the servos Polar Coordinates to (cartesian coordinates)
  4. ie x=cos(angle)*distance, y=sin(angle)*distance
  5. then you can plot direct to the display x,y
  6. Result is a visual map of your scanned area.

Video (1)  URL :- LoMoR with URM37 Ultrasonic Sensor (Film was made by my Son, voice over by me)
Video (2)  URL :- LoMoR with Sharp GP2Y0A02YK0F Infra Red Long Range Sensor

Video (3)  URL :- LoMoR with Maxbotix LV-EZ1 - Ultrasonic Long Range Sonar

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Not sure of the delay yet - will try and code a milli in to check.

(i have only one forced delay after the servo.write and is delay(75ms)  i have not measured the delay of the maths code)

I am planning to use a millisecond pwm signal instead of the servo library (which requires degrees) - as far as i know you can get a better stepping of the servo .... 

...... as i have now installed a Digital Servo with metal gears on the system now which is capable of 0.13 sec/45°

My son came up with the idea of attaching two sharps to each other either at 180° (backtoback) for 360° coverage (one 180° scan yielding 360° - using 2 analog ports)..... or  90° (handinhand) for half speed 180° scan .....cool idea...

Oh, more than 75 ms, perhaps 100??? OMG! and I thought it can be done faster than 39 ms/measurement+math... Oh well, I guess 2 sensors mounted on a 90 deg angle can scan twice that fast. Hmm, I'll see how it works soon.

About the servo precision, there is a library called ServoTimeTimer1 that will give you the possibility to write the time for the ON pulse in microseconds (1500 for center). That can improve the scanning a lot, but it will add more time for a complete scan. The new Servo library also uses Timer1 and you can set the time or degrees, but I had problems with that lib when running other stuf like SoftwareSerial, Wire, Sound, basically anything that uses interrupts can mess with the pulses, especially if more than 2 servos are used (I have 8).

What about a 3D scan where you can also tilt the sensor(s), is there a way to build a 3D map and show it on the screen? That would be SO cool! 

After a bit of experimentation now with a Maxbotix LV-EZ1 i am coming to the conclusion that its the speed of the servo that is the limiting factor and not the sensors!!

The good news is that 75ms (10ms) is still conservative and there is quite a bit of room to tweak it down, i will have to experiment with each sensor to see how much it can be trimmed. 

Using two servos and building up a slice-by-slice map of the field of view would be easy enough, all you need to do is extend the original design so that the vertical servo starts at the bottom and moves up one position every time a horizontal sweep is completed. The data storage requirement for a single mapped 'image' would go up by a power of 2, but I'd imagine it still wouldn't be too huge.

Displaying the 3D data on the screen, now that would be difficult. You could have the screen just display one 'slice' and basically sweep up and down through the 3D data, but it wouldn't be the same as seeing the whole map at once.

Only if you want one measurement at every degree of the scan. RC servos hooked to microcontrollers receive a signal ranging from value 80 to value 220. That's 140 steps in your code, if you decide to use them all. Gareth's video shows 14 seconds for a full scan. I'm guessing he is using 100 ms between scans.
Hey, that's looking pretty sharp if you ask me.
I wonder if there's an easy way to code in a filter to 'clean up' the edges slightly? It might make the map a bit easier to interpret for a bot.

From the scans i can see that transitions after finding or lose_ing an edge happen quickly, so even a simple average_ing filter would do the trick i Guess - i am totally new to this so any strategies would be welcome.

I will have to invest in a digital servo too, (wait a momment , a stepper motor would work also hehehe - oh man looks like i have more work to do).

I also thought to try to work out some kind of selective scan - ie fast-scan ounce then backtrack and slow-scan just the interesting bits in more detail .Hmmm needs a bit more thought.

Try mounting the sensor vertically, emitter above detector or vice-versa. There was a Sharp app note (page 4) that recommended the sensor be mounted parallel to estimated moving edges, to limit parallax errors from the reflected beam.  Give it a shot to see if it helps.
Here you can see some nice pictures made with a Sharp IR Sensor, mounted in different orientations.

Wow that is a neat scanning rig - however 50 minutes for a scan would need a lot of patience.

Its good to see that an approximation of a picture is possible.