There is another "factor" which had driven some away over the last couple of months or so, but that's cleared up now and a few have started coming back now, hopefully more to follow. I wont go into specifics, I don't want to turn any subject on to that really.

Also, as @moviemaker said, some really only post and ask more questions when they are building. But also, a lot of answers are already here now, searching brings up answers to most questions so there's no real need for discussions on some aspects. Other aspects of building will trigger bigger discussions, look at the auto charging docking station discussion for instance (one which I plan on reviving shortly).

And thanks for the kind words.

Hi @moviemaker, this is a good idea, did you ever read "How to design and build your own custom robot" (book from the Eighties), I still have a copy here in the lab, the book has some similar ideas to what you are proposing.

In the Nineties, I did a lot of work on these kind of algorithms and my testbed was my cybernetic animal ELF http://cyberneticzoo.com/?p=3984

My work culminated in tech that I named "Volume Occupancy Mapping"

It works like video memory (an X/Y grid)

Each grid point (X/Y location) is a byte, which is broken up into 2 x 4bit nibbles of (learnt) data about that grid point. The lower nibble is the probability of that grid point being blocked or free to move across. The system is totally dynamic and self adjusting, here is how it works.

When you start every grid (X/Y) location is set to 0, from this point the algorithm starts to learn about the area (or room) that it is in. With a matrix map filled with zero's it has no idea yet how to plan the best path across the room, so the first job of the algorithm is to get an idea of where all the fixed (stationary) objects are like tables, armchairs etc. It first starts with a wall following algorithm that gives it a idea of the area its trying to map, if armchairs etc are against the wall then it builds that into the map. From the wall following, it goes into a crisscross following pattern across the area to map this part out. Now say that at grid point 5,9 it senses an obstacle then it increments that locations nibble, so it now has a value of "1". Now if this was a piece of fixed furniture then grid point 5,9 would always be impassable so after some more exploring of the area over time then its location nibble would soon fill up to F (decimal 15). Now if it was say a dog or something transient at that location then at some point the grid point clears (now passable), when the algorithm finds this it decrements the location nibble, so in the first example above, the "1" would return to "0".

What this gives the robot is a method for it to compute a high probability route that will give it a clear path across the room. This is done by looking at all the X/Y grid locations, and it knows that any with a zero (or very low value) has a high probability of being clear and any grid locations with high values have a high probability of being blocked, from this the best route can be computed.

This concept needs seriously good odometry, the AIMEC motor drive encoders, give 64000 "clicks" per single drive wheel revolution so the resolution is amazing. The next problem to overcome is wheel slippage which can introduce errors, and any major errors obviously have a exponential effect on the map accuracy, on our robots we limit wheel slippage by a special design of our tires.

The upper nibble is used to tell the robot what is at that location in the ELF and AIMEC robots the highest bit denotes danger and a "don't go there" mechanism, this is useful for things like fireplaces or tops of staircases where clearly you do not want your robot wandering into. So if the robot see's a grid location of >127 then it will just never go there or plot a path through that location. The lower three bits of the upper nibble gives info on things like "entry door", "exit door", "docking charger" position etc, so the map not only has a method for the robot to find a clear path (with high probability), but also knows where to find certain things that is useful to its operation. Using a map for each room and knowing where the doors are located means that the robot can navigate by itself around the home.

Here is simple volume occupancy map from the AIMEC:3 robot

@Rich Could you give a few pointers please This is part of the code I am using to monitor digital inputs (ir beacon ) and drive two servos ,it works very well but because of an issue between ir beacon and the digital inputs I need to use the ADC so I need to change the script to read ADC, tried to adapt "scaredy cat" but got lost along the way. Any help would be appreciated Pat

code: :forward SLEEP(10) IF (GETDIGITAL(D11)=0) servo(d0, 48) GOTO(forward) ELSEIF (GETDIGITAL(D11)=1) SERVO(D0, 54) ENDIF :reverse IF (GETDIGITAL(D13)=0) SERVO(D0, 62) GOTO(REVERSE) ELSEIF (GETDIGITAL(D13)=1) SERVO(D0, 54) SLEEP(10) ENDIF :Turnleft SLEEP(10) IF (GETDIGITAL(D12)=0) SERVO(D1, 50) GOTO(TURNLEFT) ELSEIF (GETDIGITAL(D12)=1) SERVO(D1, 45) SLEEP(10) ENDIF :TURNRIGHT IF (GETDIGITAL(D14)=0) SERVO(D1, 38) GOTO(TURNRIGHT) ELSEIF (GETDIGITAL(D14)=1) SERVO(D1,45) ENDIF GOTO(FORWARD)

Quickly (since my tea is cooking and I'm starving!)

Change all GetDigital(port)=1 to GetADC(port)=255 hopefully that'll work, if not you may need to play with the =255, maybe >0 will work better.

Edit: and GetDigital(port)=0 to GetADC(port)=0

A digital on/off sensor on the ADC should report 0 and 255, 0 being off, 255 being on, in theory.

Thank you Rich Wonderful smooth transition to ADC will list details in seperate thread to assist others,while the ir beacon worked fine on digital ,if I lost connection with EZ-B the result was flashing led's on ir beacon until I re made connection. Having blown my first beacon ( not sure if this was actuall cause ) I decided to change over to ADC Pat

@Toymaker

I am really interested in the idea of "Volume Occupancy Mapping" to use with the Auto Docking Project. I would much rather use something like this instead of IR beacons to help the robot navigate from room to room. Having the robot understand what room it is in so that it can make the right decision on what route to take to find his battery charger has been a challenge. I am still saving up to purchase more parts for the IR beacons and the detection system I was planning to build. However, I would much rather use some type of mapping system. I hope this topic will blossom into a simpler answer to my problem. Problem is, I have no experience with programming or scripting....yet.

Rich has been such a big help to a lot of people for script help and now with this topic maybe we could advance our Auto Docking Project forward. I look forward to more discussion on this and I plan on visiting your website to learn more about your robots. Hope you will have the time to help and guide us in utilizing this mapping concept.

So much talent here on this forum. I am proud to be associated with all of you and my life is better for it.

Rex Automatic Battery Charger Docking

Battery Charger Docking Project

@Rex, I will be looking to bring those topics back to life as soon as I have the time.

I have to admit, Tony's volume occupancy map is a little overwhelming but I only scanned over it, I'm sure once it's broken down bit by bit it'll become simpler. A great idea none the less. However encoders are used which I have halted on looking in to further purely due to a comment DJ said the other day about a new feature which will be better than encoders.

I'm confident that between us all we will come up with a great solution

The idea came from one of David Heiserman's other books: HOW TO BUILD YOUR OWN SELF PROGRAMMING ROBOT. It was a good book. But, it is based around the 8080A cpu. But, the Concepts are still good.

And, yes, I also have his book "How to design and build your own custom robot" and , also "Build your own working robot".

There was another author that had part of this idea too. He wrote "How to build your own working robot pet". It had the confidence levels.

These were some of my favorite books on building robots.