Room mapping system, Any suggestions?

[cjwillms]

I should be getting my STK500 next week, so I can finally start work on my bot again.

In the mean time, I figured I'd start working on my room mapping system. I pretty much know how it'll work, but I'm just curious if there is anything I should watch out for (ie, if you've done something like this before, and ran into a problem or two, let me know).

Anyway, as of right now, I'm just writing a fixed mapping system. Basically, it's a 30x30 square. When the bot starts, its location will be 15x15. From there it'll walk forward, until it finds a barrier. Once it hits a barrier, it'll record its position, based on how far the barrier is. From there, the bot will randomly choose another direction (left or right), and follow the wall. After that, I can give it a destination, and it should be able to make its way there, based on the known barriers.

For debugging, I’ll probably just read my mapping system data from the Static RAM, and run it through a windows program, to draw the know barriers (see if it's accurate).

[cjwillms]

Well, I ran into the my first problem. Unfortunatly, since the microcontroller is 8 bit, I was pretty much limited to 159 bytes (out of 2024) of SRAM. So, I searched the net for about 5 hours, looking for a way to use 2 8 bit variables, as a 16 bit one.

Of course everything I found didn't help me at all. Every 16bit related thing I found, required you to hardcode the original 16bit value. After that, you really couldn't mess with it. From that number, you could extra it into the two 8 bit variables, but in order for all the math to work, it would take quite a bit of codeing.

Plus, since I'm setting up my starting offset to be flexiable, I really couldn't hard code it in. After I got rather mad at it, I finally found something that NO ONE has posted on the net (from what I could tell). Apparently, when you use the mul function in assembly, the avr will convert the number into a 16bit one, if needed, and then shove it into 2 8 bit variables. So after I found that out, I finally got my pointer to work like I wanted :s

5 hours for this formula (30x30 grid, starting at 122)...

Y Index variable = (30 * Current X Position) + Y Position + Starting address

[Admin]

What sensor are you using? How does your robot know which way it is going? What if a wheel slips just one degree every 5 feet and error builds up over time, how do you plan for the robot to correct itself?

Why do you need 16 bit?

[cjwillms]

What sensor are you using?

I'll just be using infrared sensors. There data will be read in through the analog -> digital converter, so I'll be able to get an estimate of the objects distance.

How does your robot know which way it is going?

What ever direction it starts off facing, will be considered "up". I'd love to add a digital compass/gps, but as of right now, I just don't want to do the extra work, and have to buy new hardware.

What if a wheel slips just one degree every 5 feet and error builds up over time, how do you plan for the robot to correct itself?

There is where one of my problems lies. Since my bots a walker, the distance that it does travel will be pretty accurate. Of course, this really only applies if it's on a level surface, and there isn't much debris. What I’ll do, is just add in some fuzzy logic. If the bot determines that its position is off (say 3 barriers stacked on top of each other), it'll try to find a know corner, and set its position based on its location.

Here's a simple picture to kind of show you what I mean.

000---------00000
00----------00000
00----------00000

0 = no barrier, and - = a known barrier

Why do you need 16 bit?

As of right now, I'm just writing a static mapping system. Currently it's set up as a 30x30 square.

since I don't have 900 registers to store data in, I have to use SRAM to store all of the mapping data. In order to access the data, I have to know which bytes the data is stored at (offset). From that, I can use a SRAM read/write functions (ie, read from byte 768). Since 255 is the max value for an 8bit variable, I couldn't access enough memory to store my data. This forces me to move on up to 16bit.

[Admin]

I'll just be using infrared sensors.

An Sharp IR Rangefinder, right?

What ever direction it starts off facing, will be considered "up". I'd love to add a digital compass/gps, but as of right now, I just don't want to do the extra work, and have to buy new hardware.

Unfortunately you will need a sensor or it wont work. Just because you tell your robot to turn 90 degrees doesnt mean it will turn exactly 90 every single time. You can also consider an encoder, but even that drifts over time. You can use a digital compass and your Sharp IR, and use software to reupdate to eliminate drift. If your 'robot world' is very organized (like the known corner you mentioned), reupdating to aviod drift is much easier.

But then again why do you need a map? To find things? Why not do beacons, that way your robot doesnt need to map, and can just use a very simple photovore algorithm. The beacons can be of different colors/wavelengths for different locations. Infrared, red, green, blue, etc. The rhooba, for example, uses beacons to find its charger.

[cjwillms]

Yea, Sharp IR.

I'll probably look into the digital compass later. I under stand what you mean, but I kinda need to get the basics out of the way...

The reason for the mapping system, is so that my bot can be fully autonomous. having beacons would greatly limit it's ability to move where it wants. Once I finalize my variable mapping system, all of it's mapping data will be stored in the EEPROM (doesn't erase when power is gone). Once I have that done, I should be able to tell the bot to go anywhere I want, via a wireless link.

possible implementations for mapping system
Moving object x to room x (coke?)
Mobile camera, giving me real-time images of what's going on in my apartment at any time
Notify person x in room x, via built in speaker.

Plus, a computer generated image of my room sound uber cool to me :p