Many alternatives are being discussed
You will like reading it.
You will be, like, reading it.
solutions competing over restricted resources
heard about that somewhere…
**Would **
Using sound rather than light be more accurate?
I.e the bot drives into a room, makes a sonar like click and then gets teh echo back, measures the difference int it and uses that as a finger print for the room.
In a large room the sound would take longer to return than a small room. If the room had a lot of soft furnishings (carpet, sofa, curtains, bed…) then these would absorb some of the sound and so the returned sound would be quieter. That would give you two variables to base the finger print on.
The advantage of this is that you dont have to worry about what time it is and you dont have to do any complex calculations to do with positioning of light, as long as the sensor was fixed all you would have to worry about is getting the bot in the right position in the room to make the sound without knowing which room it is in yet, maybe one meter into a room.
Acoustic fingerprinting would work a lot easier i think.
The disatvantages are that if the sound hits something in its way and there isnt a chance for a decent sample of the room then it could throw it totally off.
I hopt hat all made sense, ive only been awake 20 minutes and my coffee hasnt kicked in yet.
Great thread btw.
Snowflakes
Sorry, I’ve only skimmed this very long and interesting thread. Here’s a variant that I think Joe was reaching for.
Put snowflake codes onvertical edges that aren’t likely to get repositioned - eg door frames and cupboard corners. Snowflake codes are like bar codes but able to carry more information in a smaller area. You can print snowflake codes on sticky labels at home very easily, and there are (at least when I looked a year or so ago) cheap snowflake scannerson eBay. Like barcode readers, snowflake scanners can work at a distance.
The strategy is: mount the scanner on the bot at a fixed height from the ground - say six inches. It can face either forwards or sideways. Print zillions of unique labels and stick them around the environment where the bot “might” encounter them six inches from the ground. Bot wanders around, when the scanner finds and reads a code it interupts the main brain to update the location. if the bot needs to know where it is, it can either interpolate from the last position using data from distance encoders, or it can using some sort of machine vision to locate a likely looking vertical edge/surface and go look for a code. If it doesn’t find a code it looks for another edge.
This solution isn’t dependent on the quality of light. The storage requirement is determined by the number of codes/nodes in the map; what info you store about each node (eg you can get beer here, or you can fall downstairs here); and how you store the instructions to get from one node to another.
I’m using “Snowflake” generically to refer to 2D barcodes. There’s lots of variants, here’s just a few. If a snowflake reader is too difficult to come by, use barcodes. A sixteen digit barcode is enough to index every book ever written (new ISBN), and barcode scanners are ten a penny.Most readers read many types of barcode, so get a reader first, then choose your code style.
In general, I wouldn’t “teach” the bot, I’d let it explore and build its own map. But you will have to teach it the significance of some nodes (eg the fridge and the stairs).
I agree
Way back last week, I thought we were trying to suggest ways for a free range bot to understand/map its environment. As soon as we help it by leaving signs all over the palce its no-longer free range.
No matter, this problem is still interesting and perhaps more solvable.
perhaps
This design (oops, forgot airquotes) aims to be engineered in a very simple computer, using the cheapest possible sensors.
I won’t challenge you to prove cost effectiveness of your proposal, but for now I’m thinking it would require a lot more computing power, more complex programming and expensive sensors.
Man, I would love to get proved wrong here. Because the sound-print of a room is indeed much richer in information and less vulnerable to external distortions.
(Isn’t this a lovely thread to wake up to?)
**Ive never really **
played around with sound so im not entirely sure what would be required. If i can think of a way to build an example then i will, not sure if i have the right parts laying about, so im not sure if i can comment on cost efectiveness.
The programming wouldnt require a lot, a timer to measure the time it takes from making the sound to all of the echos comming back, maybe the spread of the echos fro mthe first one arriving to the last one arriving, and some way of measuring the change in pitch. I dont see the need for complex algorythums to work it out, just a simple comparison to the origional sound sent.
Its great to wake up to, gives me something to think about while i do the housework!
Ten for a penny?
Where are these barcode scanners you speak of? --And on that note, I gunna go out on a limb and say I am asking too much for a TTL serial or an i2c version?
Its been a year or so, but I
Its been a year or so, but I bought a pre-owned 1D scanner that read’s dozens of formats for £10 from someone in Hong Kong via eBay. It plugs into a serial port or a USB port on my PC and outputs 8 bit ASCII. It’s an ACAN FC-8100 - whatever that means. It’s a hand held, but can easily be taken apart - I have it in bits - to be remounted. There were loads for sale at that time.
Don’t think about buying a new one
Where am I? plus When am I?
What you are suggesting and what I am hearing are not always the same. We know this now. We are that much acquainted.
You are thinking "eliminate a few options from the search". I am thinking "enrich the pattern with a time stamp".
Think of the TOD (Time Of Day) as a ninth LDR. Add it to the existing pattern. Bring its value down by the same number of bits as the LDR values. Or close to it. Four bits means 16 different TODs. Five means 32 TODs.
As a result, in my brain anyway, the TOD will "enrich" the pattern. More info for your data. Increase info density. Make the pattern even more distinctive.
"Sure there is a big bright spot plus a not-so-bright spot on the left of it, but is it also noonish? Or else this would more likely be the kitchen rather than the living room!" Kind of thing. The enrichment is emphasised.
A similar pattern enrichment could be achieved by shoving in more available data THAT IS ALSO RELEVANT. Sound levels, echoes, wheel resistance, temperature, floor colour.
Let’s see if I follow this correctly, part 1
About the retrieving aneurysm.
We have the actual measured pattern from an unknown room stored in eight bytes b8 - b15. Let’s call the whole set “snapshot”.
Now we start reading in eeprom (or whatever the technology of choice). Start at the first archived pattern and work your way through all of them. Along the way you assign points (I’d say “evaluate fitness”) for each candidate. Always noting the highest ranking pattern as you go. After you’ve gone through the entire archive, the pattern that holds the title wins the prize. The winner gets to call the room we’re in.
Am I right so far? Because it’s getting tricky from here on. This is where I sprinkle doubt:
The fitness evaluation assures that we need to archive only a limited set of patterns per room. You propose ten per room. Let’s go with that number. The evaluation is an aneurysm in itself. You propose to calculate absolute differences between corresponding bytes. Here is a numerical example assuming a matching pattern.
snapshot b8 - b15 255 90 120 160 160 200 99 212
archived pattern 255 99 135 162 170 208 95 198
differences (abs) 0 9 15 2 10 8 4 14
total of those differences = 59
max difference in the set = 15
Did you also just notice that we do not need to store the first, brightest, LDR reading?! It will always be 255! Predictably so. We made it that way. Therefor no memory required! We can predict its value both in the snapshot and in the archive! The difference will always be zero. I’ll keep it in the examples for now.
I wonder how this rating (either 59 or 15) would be able to make a distinction with other archived patterns that are not for this room. I could imagine an archived pattern from a different room that would match the snapshot by the same amount of error.
snapshot b8 - b15 255 90 120 160 160 200 99 212
different pattern 255 91 121 161 159 201 47 211
differences (abs) 0 1 1 1 1 1 52 1
total of those differences = 59
max difference in the set = 52
This comparison will only give a wrong match (false positive) when we use the “total of differneces” as the rating to rank our candidates by. But for the “max difference in the set” exists an equally misleading candidate, I’m afraid.
Finished the Hardware…
Finished the Hardware… Starting code --And rik, this is what a 360 degree servo looks like.
360 degrees
Ahhh, the vex that keeps on vexing.
I have it working…
Well, it is working and taking readings at the (8) predertimined stops. One problem though, I can’t seem to get readings into the internal eeprom. It is one simple command, for cryin’ out loud! I will keep working on it, it has got to be some stupid thing I’m missing. I dunno.
In the meantime, I went back and gave my little IR beacon test another look. I’ll have a post up on that soon.
Got fed-up went to something else…
I am still stuck on this write command -again, I gotta be missing something stupid. In the meantime, I re-tested my IR Beacon system and well, it still works!
I started to do some math. $4 for a 08m, $.08 per IR led (needing 3-5 per “beacon”), $1 AA battery holder, some scrap PCB. I’m looking at about 7 bucks per “beacon”. With 2 per room (each set to a different output code number) you are looking at $15 or so. --With 2 in each room you can allow for some pretty good triangulation. Even if you add another couple IR led’s and a IR transistor, you would still only be up to about $20 bucks a room and with the extra LED and sensor, you could set a beam at the doorway to trigger the beacons to come on for 5 min’s or so. The rest of the time, they sleep -batteries would last a long time.
I dunno, guys (rik) are we entering KISS territory here?
not 360 but with 160 mm objective and targeting lazorrr
This is pretty much a robotic telescope. Unfortunately, I don't (yet) know how to store stuff in the on chip eeprom (scratchpad?). So I am using a pmw signal as a debugging tool. That way I do not need to haul my PC to where ever I set up this rig.
The lens proves useful actually. It makes the "angular sensitivity" a lot higher and the light reading really jumps up compaed to reading without lens. However, the eye must be staring exactly at the light source for that. The lazer helps me target the thing somewhat. The robot does not use it.
#picaxe 28x1
' test 20090413-1
' using multimeter as debug display
symbol ldr = 1 ' adc in #1
symbol display = 2 ' pwm out pinc #2
symbol scan = 2 ' servo pin #2
symbol voltage = w0
symbol duty = w1
symbol maxduty = w2
symbol period = w3
symbol azimuth = w4
maxduty = 255 ' 250 for 16 kHz, 25 for 160 kHz
period = maxduty / 4 - 1
azimuth = 150
servo scan, azimuth
pause 1500
main:
for azimuth = azimuth to 80 step -5
servopos scan, azimuth
pause 10
next azimuth
pause 500
for azimuth = azimuth to 220 step 2
servopos scan, azimuth
pause 200
readadc ldr, voltage
duty = voltage * maxduty / 255 ' normalize to 100% @ maxduty
duty = 255 - duty
pwmout display, period, duty
next azimuth
goto main
I like it, rik…
It seems the rik’s LDR vs. chris’ IR beacon competition is on now, yo! You are right about my idea of the points system… Each room is “off” about the same amount as the others -and this was with taking 2 sets of readings only about 20 min apart. I can’t wait to see the numbers coming out of your telescope here. One would assume bigger fluctuations and a more “directional” sensor is only going to spit-out better data. Mind you, I have nothing against your system here, actually I really want to see it work so I can forget about setting IR beacons all around the house. --Not to mention the ability to map any new location walter is in!
Gimme the data, yo!!!
any pointers on scratchpad?
I need a way to store them data first. Any pointers? Have no eeproms lying around.
rik --internal
rik -you have an internal eeprom
Commands: Write and Read… The problem I am having is that it appears you can only store one byte per address although the manual says differntly… Tell me if you have the same problem…
will read tfm
tomorrow. Thanks and nightnight.