attempting to use sonar to make maps

@tfmccarthy 

I'm not sure what this means. A single pulse won't produce a second source, but the echo will come back over time.

Sorry I digressed from the use of the simple HC-SR04 ultrasonic sensor which has a limited use as it cannot exploit the full range of information carried by sonar echoes, not "pulses of data", a mistaken description of multiple echoes. Been reading too much about bat sonar and some of the more advanced sonar systems!

Posted by: @robotbuilder

↑

Been reading too much about bat sonar and some of the more advanced sonar systems!

Curiosity is a disease, isn't it? I've been diverted, sidetracked, and enchanted by "blinking lights" so often in the past I wondered how I got anything finished. It's how the acronym, YAGNI ("You ain't gonna need it") entered the software lexicon, I think.

OK, back to the task at hand ... I'm gonna flesh out the pan-tilt demo code to complete the hardware shake-out and then work on fixed point test development (resolution and origin). Then work on the plan of action.

@tfmccarthy 

Just a quick post to let you know I am using the hardware setup from the "how to mechatronics project" link you posted which I will put on top of my robot base.

There is the issue of code to move the base around autonomously while it collects data to create a map. In the meantime I can use remote control to move the robot base around.

I've managed to complete the Model #1 hardware demo to shows how the scanning operation works. I've posted the demo here HC SR04 Model 1 Demo

A few notes:

From Wikipedia

The pan servo performs the Yaw motion, and the tilt servo performs the Pitch motion

The Adafruit Mini PanTilt kit is pre-assembled (the unassembled kit wasn't available) and I didn't modify the orientation of the tilt servo from the "out of box" set-up. The result is the range of the tilt servo isn't optimal and will need to be adjusted. AFAICT, the servo doesn't cover the full 180 degree and ranges over 90-180 degrees.

Even with the kit screwed to a plywood board, it has considerable shake and oscillation. I was initially alarmed by this but when I looked at the output it doesn't seem as chaotic as it appears. I choose to use a horizontal major sweep, and I think that helps to damp down the vibration. Of course, slowing down the scan cycle would help as well.

Damn it's noisy.

The code feels flexible and should be easy to adapt for test repeatability and programming.
The next pase is test to determine the orgin and accuracy. FYI, I can't get a reading beyonf 70cm even thought he sensor claims to measure up to 4 meters. 20-30cm seems like the the reliablity limit, but that needs further tests.

@tfmccarthy 

With sonar I was originally interested in using it for obstacle avoidance and exploration.  It may be simpler and faster to collect data from sonar sensors fixed around the robot to create a map while it is executing obstacle avoidance using some exploration algorithm.

So I think I will continue with an old goal of using fixed sonar sensors for making a 2d map.

The reason I like to use a simulator is to test and trial algorithms faster than on a real robot. Of course when applied to real hardware the difference between the ideal simulator data and the real hardware data has to be reconciled with software modifications.

@tfmccarthy 

This is an example using a setup like yours to create a 3d point map.

Posted by: @robotbuilder

↑

This is an example using a setup like yours to create a 3d point map.

Ahhhh! Information overload!

This was unexpected although I should have known it has been done before. It's discouraging in that it seriously dampens my enthusiasm for the project. There seems to be hours of videos to go through to see the prior work. Of course, while watching this video I noticed a few things that I thought were odd or missing but I can't comment on them yet as I need to watch this one a few times. He only provides the music links, so I have little to work with there. But there are a lot of papers to read as well. I may never get through all of this.

dang.

If I see this same image of the "radar"

I may lose the will to live. This is the same project, over-and-over. And nobody mentions that the sensor is consistently reporting less then 25% of the specified range! It's like the range finder by Mr. Magoo. And here I felt my build precision was under par and they're using hot glue to hold everything together. And of course, any distance sensor should automatically detect "holes."

I think it's time for my meds.

@tfmccarthy 

Ahhhh! Information overload!

And also data overload!!

The point cloud isn't of much use to a robot without a human visual system to use it.

I realise your end goal was a 3d point map but why not go for the more doable challenge of a 2d map that a robot can create while moving through the environment in real time?

Fixed sonar sensors around the robot base can be used for obstacle avoidance and at the same time as the robot moves all the points will be scanned to create a 2d map that it can use for localization and navigation.

I lost interest in the sonar radar scanner link when I realised it was too slow but the code example will be useful to connect the arduino board to the computer to display, store and process the data from the fixed sonar array.

@tfmccarthy 

In another thread and post you wrote:

"You're wearing your software developer's hat while I'm wearing my test engineering hat."

And it made me think and the truth is I have always been much more interested in solving coding problems for the robots I have already built and I need to get back to where I started here six years ago and not get distracted.

Posted by: @robotbuilder

↑

And it made me think and the truth is I have always been much more interested in solving coding problems for the robots I have already built

I can only speak from my experience, which is bias to a degree towards testing as it's where I cut my teeth. You really need both hats. I confess that I enjoy the "development" of software solutions to a greater degree than testing software. However, I've learned (the really hard way) that testing software has benefits that equal or surpass those of development. The insights you gain, the effort you save, and the surprises you find, are very satisfying. If you can learn to treat testing just like development, you'll be well rewarded. I've found that the more I test my code in development the less time I spend debugging my code. (That's another hat you need: the debugger hat. It's a must have.)

Posted by: @robotbuilder

↑

I need to get back to where I started here six years ago and not get distracted.

Unless (sez me) you're having fun exploring and spelunking. This is a hobby, meant to be enjoyed. So do what you find enjoyable. Naturally, I presume you enjoy building circuits and devices, like your wandering bedside table bot. it may take some time, but we should make progress.

You did mean you want to be a bit more "hands-on", right? Or do I misunderstand you?

I'm working on a rant of the 3d point map. After re-watching it I think it's all messed up.

@tfmccarthy 

I confess that I enjoy the "development" of software solutions to a greater degree than testing software.

It was about a preference for software vs hardware testing. I am not a chip maker or board designer and it is up to them to properly provide the specs for their hardware not the poor sods that spend days trying to find out what they need to know. My robots use the Mega board and a laptop which is all that is needed for the control software. The main sensor is a camera with obstacle sensors to let the robot know it has hit something.

From the point of view of robotics the sonar scanner is too slow to be practical. It is a novelty item only to generate a point cloud. Notice you can't really see the 3d shape unless you are rotating the point cloud. The human visual system can generate a 3d image from movement. Perhaps you could color code the points for depth. Or write a routine to use the point coordinates to produce two views for a stereo viewer.

You might add a lens and color sensor to the sonar to add color to the point,. That would show up the red guitar points in the utube example maybe the shading as well that produces depth.

The only time I played with point clouds was when I was interested in coding 3d displays. 3d points are simpler than polygons to code. I wrote code to generate a sphere of points and wrapped an image of the around it. Did the Moon, Mars and Saturn as well. You could just rotate them with the cursor keys.

I may go mad; I may already have.

After watching the "3D Sonar with Arduino\MATLAB and Point Cloud Filtering" video I'm persuaded that the author is confused about the properties of the sonic device or physics of the problem. The first red flag comes with the construction of the test model.

There's no polite way for me to describe this construction. "MacGyver-ed" ? Clearly, any sort of accuracy or precision has been throw off the roof and we're left with "it's all a wash!" The expectations for this model are: "Wow! It runs!" and that all.

He does properly identify the angles yaw (theta) and pitch (phi) but makes the fatal error of assuming they may be set to any arbitrary value. They're constrained by the servo device and have a fixed accuracy and precision; specifically, there are no fractional degrees. So the attempt at increasing the resolution by adding fractional degrees is a wasted effort. 15.5 and 15 degrees are the same angle to the servo. This means that 50% of his sampling effort is wasted time. He says that each angle sample is repeated 15 times to eliminate noise (what he wants is the mean of the 15 samples) which increases the scan rate. The NewPing library claims it can perform 30 samples per second but I suspect he's not using that feature. Honestly, I stopped thinking about it by this point. The full field-of-vison and the practical one are probably significantly different and would reduce the scan time proportionally. The post processing of the data is not much better. The data is essentially a topological map; meaning, it a closed surface. He never shows this and so his models don't show any patterns.

What is clear is that a sonar range finder device is not appropriate for a real-time surface scan. It should be able to produce a usable, partial topological map in a reasonable amount of time, i.e., minutes, not hours.

Changing the device may improve the speed but I think a lag is inherent.

I saw you post with,

The human visual system can generate a 3d image from movement. Perhaps you could color code the points for depth. Or write a routine to use the point coordinates to produce two views for a stereo viewer.

My current feeling is that if sonar is slow, visual is going to disappoint; like 2 orders of magnitude in complexity and storage.

I'm gonna continue on for a while more. I still have ideas for incorporating the camera into the pipeline.

@tfmccarthy 

I'm gonna continue on for a while more. I still have ideas for incorporating the camera into the pipeline.

Will see what you come up with.

The VK53L1X(TOF) may be much faster (speed of light) thus can scan faster and with a higher resolution (less spread) although it has some spread according to one video where the experimenter viewed the light hitting a surface using a digital camera without the IR filter on the lens. My digital camera doesn't have an IR filter and I have used it to check if an IR led is on or off.

I have been working on testing the math to implement ideas I have had over many years to use beacons and/or lidar data to make maps and then use them to locate the robot and allow it to generate a path to some goal position. The proof will be on testing them on the physical robot not just on the simulation.

Ultimately I think the video camera will turn out to be the best solution even if it is a bit more complicated and computionally intensive to make use of the data. The latest cars use vision to monitor the driver and watch the white lines on the road.

@tfmccarthy 

My current feeling is that if sonar is slow ...

If you are trying to make a sonar version of a 3d scanning lidar to create a pretty point cloud to admire then it is indeed slow but so what? Once it is done you can admire it like a 3d painting as you rotate it around. Researches might fly a drone around some archeology site for hours to create a detailed 3d point cloud map that they can then study and explore later.

My personal interest is how such data can be used by a robot in real time.

Sonar or LOF sensors can have an immediate function of obstacle avoidance. While wandering about under the control of some explorative algorithm it can build up a map over time. A moving robot base is actually scanning points as it moves even if using a fixed set of sonar or TOF sensors. Knowing its ongoing current position and direction this point data can be stored for later use in a binary grid map for location and navigation. The trick is knowing exactly where the robot is in absolute space with each scan which is of course what all these SLAM algorithms solve!

1. Determing position and direction is where recognition of unique configuration of features might help. Seeing a corner feature doesn't tell us what corner it is seeing in the global map however a set of corner features in some configuration might. Much like recognizing a constellation of stars.

2. If a at least two features (or visual patterns) are recognized and their global positions are known it can be combined with the observed angle between them to compute the actual position of the robot in the global map. Can't remember if I posted this topic and code in some other post?