Mapping Using Sensor

I am working on a project to map a room…I eventually want the robot to detect changes around an area.
I’ve been banking on the sensor but I am not getting the results I was expecting. I bailed on my project and stripped the Ultrasonic Sensor project down so it would scan the same area 5 times via the servo. The results are raw (I removed the scaling) & the robot doesn’t move.

RobotMaze.jpg is what the robot was scanning
RobotLidar.png is what came back

Is this typically what I should expect (curvature since the formula is sin/cos)

Is there anything else I can do/options either via sensor(I’m using the out of the box sensor) &/or calculation to have the sensor match more of the real-world?

The output does not look great. It should look much more like what the actual place is. We have tried something similar a long time back: https://github.com/DexterInd/GoPiGo/blob/master/Software/Python/Examples/Ultrasonic_Servo/us_servo_scan.py. If you are careful enough with the angles and conversion, you can get better output out of it.

There is an actual LIDAR availble here: http://www.seeedstudio.com/depot/RPLIDAR-360-degree-Laser-Scanner-Development-Kit-p-1823.html?cPath=14 if you are interested in getting great readings out of it. Though we haven’t tried it out yet with the GoPiGo.

-Karan

us_servo_scan is what I started with but I removed the grid & the scaling. Is the curvature coming from the calculation (sin/cos) even though the room is rectangular? Any recommendations on what I can do to improve?

I am pretty sure that it would be the calculations. There is one thing that you can do on paper. Keep the GoPiGo centered and manually give commands from the basic_test all to move the servo in increments of 5 degree and find what the ultrasonic sensor reads. Then use the formulas to find the distance and plot it on a paper for each of the servo angles, this way you;'ll be able to find if there is any problem in the calculations or something else.

-Karan

So before I went to paper & did the calculations manually, I went back and compared measurements via the GoPiGo to a ruler. I’m seeing anywhere from a ~5cm to ~10cm difference for the distance returned (not even calculating the x/y). Is there anyway to calibrate the sensor?

Update…
I was thinking maybe it was the servo (little bit of wiggle) so I ran a test in 10cm increments (capturing 5 distances per run) from the wall (no angles)
I also ran this experiment twice and roughly got the same results…

Is there anything I can do to calibrate or is this consistency something I can account for within my code?

10cm from the wall: ~0cm difference
[10, 10, 10, 10, 10]

20cm from the wall: ~2cm difference
[22, 23, 22, 22, 23]

30cm from the wall: ~5cm difference
[35, 35, 35, 35, 35]

40cm from the wall: ~8cm difference
[48, 48, 47, 49, 49]

Hey Kirk,
I haven;t seen this kind of behavior before. It data looks like it is pretty precise but from your experiments it is not very accurate. We don;t have any calibration for this kind of error. Can you send a picture of how how you are doing this and can you try out a distance of 1m from targets made of different materials.

-Karan

I am seeing the same kinds of distances returned as ksuscella reports.

The reported distance is 1.30 times the true distance. (Actually, if I add 2.75cm to the reading first, and then divide by 1.30, it’s a great fit to reality. I assume the 2cm adjustment has to do with the effective origin point of the sensor.)

I am wondering the reason for the difference. I see the firmware uses “pulseIn” to measure the data pulse length. Is there any chance a clock speed change or something has affected its accuracy? The issue seems so specific, off by a set multiple. I see mentions of the clock originally being at 16 MHz and now at 2 MHz. Although F_CPU was changed, maybe this still changes the loop timing somehow?

These are complete guesses of course, and it’s easy enough to adjust in code anyway.

(Note: I adjusted my numbers above in a subsquent edit, after finding an error in my spreadsheet.)

@ken, @ksuscella,
We’ll try it out at our end and get back to you.