I wouldn't say I want to avoid then, I want to keep the system as simple as possible to produce a usable system. I hoping that this can be done with out a lot of additional hardware, but at this point it's all theoretical. when you look at the HB555 Compass it is quite coarse for accurate navigation. my bot doesn't have a 0 deg turning radius (yet) so just making a turn will throw off the position. adding all this together I'm not sure if the results will be usable, but I would prefer not building a system that relies on way points to function I want to push the concept as far as I can with out them, however, not to talk in circles, but when you consider all of the real world issues I think that way points will be required. or at very least desired to add additional functionality. I appreciate the suggestions tho. keep them coming, RFID tags were discussed in this thread, I'd love to have one every square foot. wow what you could do with that!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I was pointed over to this post because I want to do the same thing with my bot that you all wish to do. I am working on wheel encoder’s next week and needed to get some input on the logic behind deciding what a better place to travel is. I am using an IR sensor and I can read from 2” to 3’. I need some help addressing this logic - how do I find the lowest number out of five numbers ( a low number means safer to travel towards). Take a look at the picture
If I sweep the head on the bot from right (A) to left (E) and get the values (distance) from 5 specific spots during the sweep how am I to mathematically or logically determine the lowest number. (low number means safe to travel in that direction)
I have an array I am tweaking with but so many if then statements it is out of control.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
lots of input, that is good. Hope that there will be a more participants to join the project.
I tried to collect the concepts for the project in a couple of statements. What I did is just copied DG's keypoint.
So no big deal but I like to have things clear before we take off.
What we should add to the specification is the purpose of the robot to which the mapping system will be added.
Of course one could say that the mapping system should fit any application (robot) requiring mapping capabilities but that is not fair.
As mentioned before: position data should "be at least as accurate as it takes for the system to function reliably".
This implies that we must agree what applications we have in mind and as a result which accuracy is needed for those applications.
To be honest, I'm not clear yet about what is possible or what application I have in mind.
I also want to do some "dry-tests" (calculations) first to avoid mismatch between expections and deliverables.
In the meantime, let's refine the specs.
I intend to order my Propeller in 3 weeks because regardless our plans with thhis project, I want to lay hands on a Prop.!
Maybe you remember that the Dutch distributor did say he didn't sell the Proto board. Mightor (Dutch Parallax forum guest) told me that he had an offer from
the same distributor! I contacted them again and YES .. they sell the board at a price compatible to the Parallax price. Sometimes "magic" happens.
Flood I'll PM you come code. I do exactly the thing your looking for you don't need to use an array you can calculate the highest as you go very easily. set your variable to 0, then as you turn your servo to each position you you say if new distance > than longest distance then new distance = longest distance. look at the code if that doesn't make sense. also you need to check your center position last or your bot will always turn when all. I'm working on some code that uses the compass to get the directions I'll post it when I get it finished.
I'll be ordering my prop Monday or Tuesday. from some dry runs I can tell that we'll need to use the multi tasking function of the prop or multiple processors if we didn't use the prop.
I'm going to do a "dry run", having my bot drive in a square or some set path repeatedly, using the encoders for distance and the compass for direction. to get an idea of what to expect as far as drift while turning. in my experiments with the compass I'm worried that it might be far too coarse for practical use in this application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
A question about terminology - forgive me if this is a dumb question.
Bot One - Say I build a robot that I can put down in a completely unknown space. It looks, pings, smells or feels by bumping into things and keeps it self out of trouble. If it does this, but never learns what it is doing - is this considered mapping? or is this just responding to what is there? Call this level 1 "thinking."
Bot Two - Say I build a bot that I can put in myliving room. I put it down at a start point. I have "told it where the walls are, the chairs and bookcases are. It can stay in the clear floor space, but I still want it to do what the bot above can do - just to be safe and in case something changes. Is this mapping? Call this level 2 "thinking."
Bot Three - O.K. I build the same bot as bot One, it does the same thing, but this time as it explores, it "learns" or remembers were things are. It now "knows" that if it goes a particular direction, it will run into the bookcase (though it doesn't know it is a bookcase, of course ). Is this mapping? I would say so. Call this level 3 "thinking."
Bot Three advanced - Now if my son comes in and parks his tricycle in the area. The bot runs into that - learns it as a new obstacle and does't go there again - a least for a while - but it might check there on occaision - if the tricylce moves, it remembers now that this area is open and will use it again. This would be very advanced mapping in my mind. Call this level 4 "thinking." This bot would be able to be put down anywhere, learn its way around an remember it.
Is this what we are talking about? How advaced are we aiming for?·How do others define this problem? Thanks for your time. Just want to be sure I undersand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I am not sure how far to take it but I wanted to do the following:
1) Map into memory the surroundings and remember this
2) If a new obstacle is present remember it
3) If I succeed with 1-2 I will try to check the map for updates or changes on a given day of the week or an event that triggers a refresher of the map.
I also wanted to use my PC via a wireless connection to help out. Like for dates and mapping on a hard drive.
After all this, I wish to integrate a program I designed while in college for the PC that obeys my voice, i.e. executing a program (one that I create depending on the thing/s I want executed) who is to say that I could not send my voice command through the bot to have my PC tell my bot to do something.
Get me a beer!
Yes Sir!
So mapping is important to me so that I can have my bot running around effectively and get that beer quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
Whit,
thanks for the write-up. That helps to refine our thinking!
I would say we go for level 3 but with a base map of the area on board as for your Bot Two.
FH, I like your 3 level approach. That is what we have in mind too.
Hopefully, the PC is not necessary to operate the Robot or the Mapping system. Can be helpfull for analysis but should not be for operation.
User interface is not (yet) part of the project and neither are the tools required to bring a beer :<)).
FH, I like your 3 level approach. That is what we have in mind too.
Hopefully, the PC is not necessary to operate the Robot or the Mapping system. Can be helpfull for analysis but should not be for operation.
User interface is not (yet) part of the project and neither are the tools required to bring a beer :<)).
Ed
True lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
Just to chime in my opinion, I would like to plan for the Bot 3 advanced. I call a bot 1 IR wall bouncers because that's all they can do. and it's hard to give a bot that just wanders in the dark a purpose. I want to give the bot a map, and a way to know where it is in the map. I think that if the bot can calculate/ figure out where it is on that map then making it a bot 3 advanced won't be that hard. before I mentioned how I wanted to handle that but I'll summarize again. the bot would have 2 maps. the user defined static map. and the bot's, generated on the fly map. as soon as the bot knew where it was it would start mapping.
If the static map was a big open room, with a newly placed trike in it, the bot wouldn't avoid the trike based on the static map and when the bot headed toward it, it would see it with it's sonic range finders first. and mark the area with a 1 on it's dynamic map, with every pass of the sonar "seeing" the trike it will increment that area to a certain level. and remember the location, if the trike moves then every pass with the sonar not seeing the trike will decrement the level of that area until it's no longer remembers its there.
kinda like I mentioned before also. I think we need to start at bot 1 and work up to level 3+. I think we are all past level 1.
I think we need to break this down into a set of mile stones and focus on one aspect at a time and then go from one mile stone to another. knowing that we'll have to adjust the milestones as we go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
If the static map was a big open room, with a newly placed trike in it, the bot wouldn't avoid the trike based on the static map and when the bot headed toward it, it would see it with it's sonic range finders first. and mark the area with a 1 on it's dynamic map, with every pass of the sonar "seeing" the trike it will increment that area to a certain level. and remember the location, if the trike moves then every pass with the sonar not seeing the trike will decrement the level of that area until it's no longer remembers its there.
·Well said. This would be a more advanced trait that simply marking the area off-limits for a certain or fixed·period of time and then at·a later·time verifying that the object remained present.·Your idea would constantly be updating the dynamic map.
I also really like the terms static map and dynamic map.
As I have said,·muxh of this is over my head - especially how exactly to go about coding this behavior, but I have thought about·the problem·itself a·bit. I am willing to help you·all however I can. I learn so much from the discussion and the method of addressing a problem.
I wonder, if it might be useful to set up a small model·enviornment, that·everyone could recreate. That way each·person could know the test enviornment parameters·and better understand the map,·code, conditions, etc. Everyone would be able to understand the exact static map conditions - so to speak. "Random objects,"·like the tricycle·could even be inserted at a fixed point (in·everyone's model)·so that everyones solution or code (the dynamic mapping process and its updating method) could be evaluated against a standard problem.·With this idea, individuals might be able to work on peices of the project and that info could be shared in an easily accesible way. Just a thought.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Whit, I can assure you that this is way over my head also, but I'm committed and I love a challenge. I usually focus on "the next step" after a while I find that I can climb mountains, some times that involves going back to square 1 and climbing the mountain several time before I actually make it to the top. but it's all in the name of progress.
a scaled down environment could come in handy, I don't have a Boe bot, quite the opposite. my bot weighs a ton and is 1' dia, and 2' tall. so it's hard for me to do scaled tests.
I think the week link in the system at this point is the Compass module. my bot moves about a foot per second and turns about 140 deg in a second. and just of the top of my head I think the compass module has a 10ms cycle. Add calcs and everything else and that really cuts down the amount of reading i can make in a turn. the servo used to pan while looking for obstacles turn slower but even it's a little too fast. so I've been doing some coding to see if I can get my bot to turn to a specific direction reliably or not. I should have a conclusion tonight. and I'll post my findings.
I had an epiphany about wheel encoders last night, unfortunately it only applies to my bot. I have 2 #25" sprockets that drive the wheels, and the tooth depth is enough that I'm pretty sure it can double as a encoder.... I'll find out.
so my goal in prep for this project are, Test the compass, get shaft encoders working, and get the RF link up for remote communication.
Whit you've already been a help I plan on this being open source so help with what you can learn where can and we'll get everyone to the finish line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I just sketched this Model Space idea. After reading DG's post it may be too small, but I didn't want to make something so big that everyone couldn't use it. It is attched.
Some points -·A hole in the floor seemed a good test condition (open stairs down etc). I put in a simulated window (like a sliding glass door - would some sensors be oblivous to this - especially with a hard surface just behind it?). I have hard and carpeted flooring. I have one obect in a corner and an insertion point for the "ramdom object" - I suggest a softball. I did not know how high to make the walls. I know some of you have pan an tilt heads - would you map above objects or just to the objects in the bot path of travel - or might you "landmark" off tall or unusually shaped larger objects in an enviornment?
Lastly, I gave designations to each side so that we could converse about the space more easliy.
Let me know if this helps or is even something we think we need. I can refine it in whatever way we might think best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
mostly because I look for any excuse to use sketchup but I'll draw it in Sketchup when I get a sec. that will give a 3d view of the room. I highly recommend all of you get sketchup you could learn it in a day if you took the time. and it's Free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Dgswaner said...
mostly because I look for any excuse to use sketchup but I'll draw it in Sketchup when I get a sec. that will give a 3d view of the room. I highly recommend all of you get sketchup you could learn it in a day if you took the time. and it's Free.
Thanks! I will get it! Can't wait to see the 3D version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I finally made some nice code that allows the robot to decide from 5 angles and 5 thresholds as to witch is the most likely to be obstacle free. I tried to use the code examples you all sent me but I am hard headed and needed to figure this out.
Here it is:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
I finally made some nice code that allows the robot to decide from 5 angles and 5 thresholds as to witch is the most likely to be obstacle free. I tried to use the code examples you all sent me but I am hard headed and needed to figure this out.
One step closer to getting that beer!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Here is the model in Sketchup. this does bring up a point. scale could be an issue. I don't really seeing it be a huge obstacle but definitely something to consider. I choose a 1'x1' grid in my thoughts about this. but that may be to coarse for a Boe bot, or too fine for a larger bot. the smaller the squares the more data but higher accuracy. anyway here is the model.
SkyWalker, this was mentioned in a similar thread. but it's good info and I'm not sure if you've seen it.
Mike Green said...
dgswaner,
If you were using a Prop, I'd suggest an SD card with a cache for the current section of the map in hub ram. You could certainly use EEPROM, but an SD card would allow you to have a LOT of storage and it would be readable and writable on a PC. The SD card has internal buffering, so it would allow you to dump a block and let the SD card controller do the actual writing and any "wear leveling" of physical sectors. You could pre-allocate a file so the blocks are contiguous which would simplify and speed up access since you would only need to look up the file information once during initialization and could use absolute block numbers from then on.
also floodhound in that same thread you mentioned doing this with a BS2SX, that's what I'm using right now and I can say quite comfortably that it won't be able to handle this project. that's why we are planning on using a Propeller the language will be a barrier but I think we can over come it. my plan is to have my bs2sx handling all of the sensor inputs and locomotion and have a serial link to a prop. communicating the sensor data from the sensors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Dgswaner said...
Here is the model in Sketchup. this does bring up a point. scale could be an issue. I don't really seeing it be a huge obstacle but definitely something to consider. I choose a 1'x1' grid in my thoughts about this. but that may be to coarse for a Boe bot, or too fine for a larger bot. the smaller the squares the more data but higher accuracy. anyway here is the model.
DG,
Nice sketch! The software is unbelievable. I will play with it more later. Thanks for the tip. I'll get back to you on the scale questions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I'm not sure I fully understand where you are heading with the "Space Model"
Let me try to explain what I get out of it, please comment.
Basically the Space Model is the static map. In the drawing that Whit made, there is a new element to the map which
we didn't discuss before: the floor coverage.
Agreed that this might impact the performance of the bot but may I suggest that we leave that variable out the
equation. (for the time being) We have to rely heavily on the performance of the odometers. If we can't, the logic is down the drain.
Once we have a very good functioning level 3+ system, we might be able to deal with the floor issue.
Now suppose we all have the (same) map to start with. In the example there is a space of 6'x6'defined.
I assume that we then reserve a similar space of 6'x6' in the real world and let the robot operate in that environment.
Of course, there are no walls and there is no hole in the floor but the bot should move around as if these elements exist.
What is tested is this set-up is the accuracy of the positioning systems based on the odometers and compass.
Other sensors do not contribute to the navigation.
Characteristics such as a glass wall or a window and the height of the walls are not relevant.
The next step is to add well defined objects at defined coordinates within the 6'x6' world.
The bot should be able to detect the objects and update the dynamic map.
Since we all use the same mapping system and hopefully similar or identical bot operating software,
the differences between the behaviour of the bots is a result of the mechanical differences.
Actually Ed I was proposing that we each build a small test enviornment. It would not have to be overly compicated and maybe my idea is. I was thinking that a standardized space might let us all work together more easily than each one mapping a space in their own house or apartment. Your idea of a "virtual static map" in which the bot moved·is interesting. If the bot believed it was in such a space, we could see how it did? This might be step one in this journey.
But, if we also need direction measurements (compass), and want to rely on Ping and IR sensors and encoders - we need to move toward talking and incorporating their input (the dynamic mapping) and integrating/confirming with the static map. I thought that might be the purpose of a standardized test enviornment. (It occured to me that we would have to have the enviornment oriented the same compass direction, if we·are using a compass).
As far as the floor type, I agree we might best start with a smooth floor. I still like the idea of a hole in the floor, but this could be dealt with later also (I was thinking that the test enviornment would be on blocks with the hole in the floor as an obstacle). The same is true of Glass openings. Floor surface changes, low glass openings (sliding Glass doors) and the possiblity of heading off a cliff (so to speak) or down a set of stairs are so common in the real world, that they will need to be addressed - but these could all be done later.
For simplicity, we could use a 6' X 6' - 12" high box of plywood. It could be just 4 sides and set on any hard surface we have. We could orient it in a similar direction by compass. We could aggree on one standardized obstacle placed wherever we wanted. This would allow us to make a standardized static map, plus still have the bot taking readings within the space itself.
Later we could add the complexity of different floor types, unknown drop offs, glass (ping would catch this, but would IR?) and movable changes in the space.
Hope this clarifies my proposal. I will take the lead from you guys (I have no Prop experience and may not have one for a bit). Happy to help in any way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
to me the model is jumping the gun a little but I think we are all anxious to get our hands dirty on this project.
the model provides a common space for trouble shooting and considering code. for the most part it has every typical condition we can expect to find in an average home.
first, I feel that all of our bots need to be able to navigate that space. then when we add the navigation system we won't have to worry about our bots running into walls or what ever.
when we get to the point of trying this it's a common point of reference. my bot heads toward a wall similar to wall A then turns to wall B.......
I didn't have too much free time last night but I was going to build a numerical map representing that space so we could define a stander ranking system for the grid. hazards, safe areas etc.
that's how I see the model being used.
Sky, I think you made a point that I might not have focused on as much. our bots can be different as night and day, but I would like the Prop that we do this on to be running the same code (in the end) and work for all our bots. so it's more of an Add on, then a custom piece of software/hardware for each bot, if that's possible. so at some point we need we should adopt a standard for what data gets sent to this module and the format. but let's wait until we have a better idea of what we need.
My main goal is still testing the compass and the shaft encoders. my battery died mid testing last night [noparse]:([/noparse]
added:
whit we must have been posting at the same time. As for the drop off I'm going to rely on a virtual cliff for testing. my bot fell once and my ping was damaged beyond repair so I can't chance another fall. ledge sensing is always a good idea when letting a bot roam at random, but part of the reason for this project, for me, is so my bot will never get close to stairs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I will be away a few days on vacation. I will check in when I get back.
DG, I think trying a grid that was 1 foot square would be o.k. It an adjustment is size needed to be made, it could for a smaller or larger bot. The 1 foot square is still pretty fine. If you stood at a grid point and looked our (as floodhound is imagining), you would only be blind in about a 1/2 a square foot (at worst about 8 and 1/2 inches wide. But assuming what your looking at had some width, this blind spon would be even smaller. See the attached sketch. Chance are if you looked around North South East West from any grid point - you would see almost everthing worth seeing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Can I just add a few ideas for the purpose of this device. again just trying to make sure we are all on the same path.
PURPOSE:
to allow a bot to:
travel throught an area avoid hazards
know what area it is in.
be able to travel from one area to another
be able to return to where it started.
return, or navigate to a recharging station.
travel a predetermined path avoiding new obstacles if necessary.
I didn't include things like have a secondary map, and specifics because I feel that's more of how not what. please add if needed.
regarding the memory stick reader. I think that's an excellent solution.
not sure if I've mentioned this or not but I'm in the process of moving so my involvement on the site will be hit and miss for about 2 weeks, but after that I plan to hit that project hard.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Sorry I missed that! I went back an re-read. At least I know it wasn't a dumb idea now!
As far, as having one every square foot or so -·I guess that would do it - wouldn't it?
Thanks for all you guys add to this forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I was pointed over to this post because I want to do the same thing with my bot that you all wish to do. I am working on wheel encoder’s next week and needed to get some input on the logic behind deciding what a better place to travel is. I am using an IR sensor and I can read from 2” to 3’. I need some help addressing this logic - how do I find the lowest number out of five numbers ( a low number means safer to travel towards). Take a look at the picture
If I sweep the head on the bot from right (A) to left (E) and get the values (distance) from 5 specific spots during the sweep how am I to mathematically or logically determine the lowest number. (low number means safe to travel in that direction)
I have an array I am tweaking with but so many if then statements it is out of control.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
lots of input, that is good. Hope that there will be a more participants to join the project.
I tried to collect the concepts for the project in a couple of statements. What I did is just copied DG's keypoint.
So no big deal but I like to have things clear before we take off.
What we should add to the specification is the purpose of the robot to which the mapping system will be added.
Of course one could say that the mapping system should fit any application (robot) requiring mapping capabilities but that is not fair.
As mentioned before: position data should "be at least as accurate as it takes for the system to function reliably".
This implies that we must agree what applications we have in mind and as a result which accuracy is needed for those applications.
To be honest, I'm not clear yet about what is possible or what application I have in mind.
I also want to do some "dry-tests" (calculations) first to avoid mismatch between expections and deliverables.
In the meantime, let's refine the specs.
I intend to order my Propeller in 3 weeks because regardless our plans with thhis project, I want to lay hands on a Prop.!
Maybe you remember that the Dutch distributor did say he didn't sell the Proto board. Mightor (Dutch Parallax forum guest) told me that he had an offer from
the same distributor! I contacted them again and YES .. they sell the board at a price compatible to the Parallax price. Sometimes "magic" happens.
Ed
have a look at this page by Tracy Allen.
This seems to be what you are looking for.
http://www.emesystems.com/BS2math5.htm#Statistics
Post Edited (Skywalker49) : 7/15/2007 5:58:21 PM GMT
Flood I'll PM you come code. I do exactly the thing your looking for you don't need to use an array you can calculate the highest as you go very easily. set your variable to 0, then as you turn your servo to each position you you say if new distance > than longest distance then new distance = longest distance. look at the code if that doesn't make sense. also you need to check your center position last or your bot will always turn when all. I'm working on some code that uses the compass to get the directions I'll post it when I get it finished.
I'll be ordering my prop Monday or Tuesday. from some dry runs I can tell that we'll need to use the multi tasking function of the prop or multiple processors if we didn't use the prop.
I'm going to do a "dry run", having my bot drive in a square or some set path repeatedly, using the encoders for distance and the compass for direction. to get an idea of what to expect as far as drift while turning. in my experiments with the compass I'm worried that it might be far too coarse for practical use in this application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Please send me the code i am drowning in [noparse][[/noparse] bull Kaa ka ]
The link skywalker sent is nice also thanks fellas i am programming today and testing the results ill be sure to post my findings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
Bot One - Say I build a robot that I can put down in a completely unknown space. It looks, pings, smells or feels by bumping into things and keeps it self out of trouble. If it does this, but never learns what it is doing - is this considered mapping? or is this just responding to what is there? Call this level 1 "thinking."
Bot Two - Say I build a bot that I can put in my living room. I put it down at a start point. I have "told it where the walls are, the chairs and bookcases are. It can stay in the clear floor space, but I still want it to do what the bot above can do - just to be safe and in case something changes. Is this mapping? Call this level 2 "thinking."
Bot Three - O.K. I build the same bot as bot One, it does the same thing, but this time as it explores, it "learns" or remembers were things are. It now "knows" that if it goes a particular direction, it will run into the bookcase (though it doesn't know it is a bookcase, of course
Bot Three advanced - Now if my son comes in and parks his tricycle in the area. The bot runs into that - learns it as a new obstacle and does't go there again - a least for a while - but it might check there on occaision - if the tricylce moves, it remembers now that this area is open and will use it again. This would be very advanced mapping in my mind. Call this level 4 "thinking." This bot would be able to be put down anywhere, learn its way around an remember it.
Is this what we are talking about? How advaced are we aiming for?·How do others define this problem? Thanks for your time. Just want to be sure I undersand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 7/16/2007 1:09:12 AM GMT
1) Map into memory the surroundings and remember this
2) If a new obstacle is present remember it
3) If I succeed with 1-2 I will try to check the map for updates or changes on a given day of the week or an event that triggers a refresher of the map.
I also wanted to use my PC via a wireless connection to help out. Like for dates and mapping on a hard drive.
After all this, I wish to integrate a program I designed while in college for the PC that obeys my voice, i.e. executing a program (one that I create depending on the thing/s I want executed) who is to say that I could not send my voice command through the bot to have my PC tell my bot to do something.
Get me a beer!
Yes Sir!
So mapping is important to me so that I can have my bot running around effectively and get that beer quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
thanks for the write-up. That helps to refine our thinking!
I would say we go for level 3 but with a base map of the area on board as for your Bot Two.
FH, I like your 3 level approach. That is what we have in mind too.
Hopefully, the PC is not necessary to operate the Robot or the Mapping system. Can be helpfull for analysis but should not be for operation.
User interface is not (yet) part of the project and neither are the tools required to bring a beer :<)).
Ed
True lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
If the static map was a big open room, with a newly placed trike in it, the bot wouldn't avoid the trike based on the static map and when the bot headed toward it, it would see it with it's sonic range finders first. and mark the area with a 1 on it's dynamic map, with every pass of the sonar "seeing" the trike it will increment that area to a certain level. and remember the location, if the trike moves then every pass with the sonar not seeing the trike will decrement the level of that area until it's no longer remembers its there.
kinda like I mentioned before also. I think we need to start at bot 1 and work up to level 3+. I think we are all past level 1.
I think we need to break this down into a set of mile stones and focus on one aspect at a time and then go from one mile stone to another. knowing that we'll have to adjust the milestones as we go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I also really like the terms static map and dynamic map.
As I have said,·muxh of this is over my head - especially how exactly to go about coding this behavior, but I have thought about·the problem·itself a·bit. I am willing to help you·all however I can. I learn so much from the discussion and the method of addressing a problem.
I wonder, if it might be useful to set up a small model·enviornment, that·everyone could recreate. That way each·person could know the test enviornment parameters·and better understand the map,·code, conditions, etc. Everyone would be able to understand the exact static map conditions - so to speak. "Random objects,"·like the tricycle·could even be inserted at a fixed point (in·everyone's model)·so that everyones solution or code (the dynamic mapping process and its updating method) could be evaluated against a standard problem.·With this idea, individuals might be able to work on peices of the project and that info could be shared in an easily accesible way. Just a thought.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
a scaled down environment could come in handy, I don't have a Boe bot, quite the opposite. my bot weighs a ton and is 1' dia, and 2' tall. so it's hard for me to do scaled tests.
I think the week link in the system at this point is the Compass module. my bot moves about a foot per second and turns about 140 deg in a second. and just of the top of my head I think the compass module has a 10ms cycle. Add calcs and everything else and that really cuts down the amount of reading i can make in a turn. the servo used to pan while looking for obstacles turn slower but even it's a little too fast. so I've been doing some coding to see if I can get my bot to turn to a specific direction reliably or not. I should have a conclusion tonight. and I'll post my findings.
I had an epiphany about wheel encoders last night, unfortunately it only applies to my bot. I have 2 #25" sprockets that drive the wheels, and the tooth depth is enough that I'm pretty sure it can double as a encoder.... I'll find out.
so my goal in prep for this project are, Test the compass, get shaft encoders working, and get the RF link up for remote communication.
Whit you've already been a help I plan on this being open source so help with what you can learn where can and we'll get everyone to the finish line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I just sketched this Model Space idea. After reading DG's post it may be too small, but I didn't want to make something so big that everyone couldn't use it. It is attched.
Some points -·A hole in the floor seemed a good test condition (open stairs down etc). I put in a simulated window (like a sliding glass door - would some sensors be oblivous to this - especially with a hard surface just behind it?). I have hard and carpeted flooring. I have one obect in a corner and an insertion point for the "ramdom object" - I suggest a softball. I did not know how high to make the walls. I know some of you have pan an tilt heads - would you map above objects or just to the objects in the bot path of travel - or might you "landmark" off tall or unusually shaped larger objects in an enviornment?
Lastly, I gave designations to each side so that we could converse about the space more easliy.
Let me know if this helps or is even something we think we need. I can refine it in whatever way we might think best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Post Edited (Dgswaner) : 7/16/2007 9:07:43 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I finally made some nice code that allows the robot to decide from 5 angles and 5 thresholds as to witch is the most likely to be obstacle free. I tried to use the code examples you all sent me but I am hard headed and needed to figure this out.
Here it is:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
Ill be here for answers if needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My web site -- > www.floodhound.com <-- take a look if you like
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
SkyWalker, this was mentioned in a similar thread. but it's good info and I'm not sure if you've seen it.
also floodhound in that same thread you mentioned doing this with a BS2SX, that's what I'm using right now and I can say quite comfortably that it won't be able to handle this project. that's why we are planning on using a Propeller the language will be a barrier but I think we can over come it. my plan is to have my bs2sx handling all of the sensor inputs and locomotion and have a serial link to a prop. communicating the sensor data from the sensors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Nice sketch! The software is unbelievable. I will play with it more later. Thanks for the tip. I'll get back to you on the scale questions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
I'm not sure I fully understand where you are heading with the "Space Model"
Let me try to explain what I get out of it, please comment.
Basically the Space Model is the static map. In the drawing that Whit made, there is a new element to the map which
we didn't discuss before: the floor coverage.
Agreed that this might impact the performance of the bot but may I suggest that we leave that variable out the
equation. (for the time being) We have to rely heavily on the performance of the odometers. If we can't, the logic is down the drain.
Once we have a very good functioning level 3+ system, we might be able to deal with the floor issue.
Now suppose we all have the (same) map to start with. In the example there is a space of 6'x6'defined.
I assume that we then reserve a similar space of 6'x6' in the real world and let the robot operate in that environment.
Of course, there are no walls and there is no hole in the floor but the bot should move around as if these elements exist.
What is tested is this set-up is the accuracy of the positioning systems based on the odometers and compass.
Other sensors do not contribute to the navigation.
Characteristics such as a glass wall or a window and the height of the walls are not relevant.
The next step is to add well defined objects at defined coordinates within the 6'x6' world.
The bot should be able to detect the objects and update the dynamic map.
Since we all use the same mapping system and hopefully similar or identical bot operating software,
the differences between the behaviour of the bots is a result of the mechanical differences.
Did I get it right?
Thx, Ed
Actually Ed I was proposing that we each build a small test enviornment. It would not have to be overly compicated and maybe my idea is. I was thinking that a standardized space might let us all work together more easily than each one mapping a space in their own house or apartment. Your idea of a "virtual static map" in which the bot moved·is interesting. If the bot believed it was in such a space, we could see how it did? This might be step one in this journey.
But, if we also need direction measurements (compass), and want to rely on Ping and IR sensors and encoders - we need to move toward talking and incorporating their input (the dynamic mapping) and integrating/confirming with the static map. I thought that might be the purpose of a standardized test enviornment. (It occured to me that we would have to have the enviornment oriented the same compass direction, if we·are using a compass).
As far as the floor type, I agree we might best start with a smooth floor. I still like the idea of a hole in the floor, but this could be dealt with later also (I was thinking that the test enviornment would be on blocks with the hole in the floor as an obstacle). The same is true of Glass openings. Floor surface changes, low glass openings (sliding Glass doors) and the possiblity of heading off a cliff (so to speak) or down a set of stairs are so common in the real world, that they will need to be addressed - but these could all be done later.
For simplicity, we could use a 6' X 6' - 12" high box of plywood. It could be just 4 sides and set on any hard surface we have. We could orient it in a similar direction by compass. We could aggree on one standardized obstacle placed wherever we wanted. This would allow us to make a standardized static map, plus still have the bot taking readings within the space itself.
Later we could add the complexity of different floor types, unknown drop offs, glass (ping would catch this, but would IR?) and movable changes in the space.
Hope this clarifies my proposal. I will take the lead from you guys (I have no Prop experience and may not have one for a bit). Happy to help in any way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 7/17/2007 1:17:15 PM GMT
the model provides a common space for trouble shooting and considering code. for the most part it has every typical condition we can expect to find in an average home.
first, I feel that all of our bots need to be able to navigate that space. then when we add the navigation system we won't have to worry about our bots running into walls or what ever.
when we get to the point of trying this it's a common point of reference. my bot heads toward a wall similar to wall A then turns to wall B.......
I didn't have too much free time last night but I was going to build a numerical map representing that space so we could define a stander ranking system for the grid. hazards, safe areas etc.
that's how I see the model being used.
Sky, I think you made a point that I might not have focused on as much. our bots can be different as night and day, but I would like the Prop that we do this on to be running the same code (in the end) and work for all our bots. so it's more of an Add on, then a custom piece of software/hardware for each bot, if that's possible. so at some point we need we should adopt a standard for what data gets sent to this module and the format. but let's wait until we have a better idea of what we need.
My main goal is still testing the compass and the shaft encoders. my battery died mid testing last night [noparse]:([/noparse]
added:
whit we must have been posting at the same time. As for the drop off I'm going to rely on a virtual cliff for testing. my bot fell once and my ping was damaged beyond repair so I can't chance another fall. ledge sensing is always a good idea when letting a bot roam at random, but part of the reason for this project, for me, is so my bot will never get close to stairs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
Post Edited (Dgswaner) : 7/17/2007 1:46:51 PM GMT
DG, I think trying a grid that was 1 foot square would be o.k. It an adjustment is size needed to be made, it could for a smaller or larger bot. The 1 foot square is still pretty fine. If you stood at a grid point and looked our (as floodhound is imagining), you would only be blind in about a 1/2 a square foot (at worst about 8 and 1/2 inches wide. But assuming what your looking at had some width, this blind spon would be even smaller. See the attached sketch. Chance are if you looked around North South East West from any grid point - you would see almost everthing worth seeing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 7/18/2007 4:43:40 AM GMT
just to clear my head I captured the inputs and thoughts in two docs.
Not final, just working docs.
All input is welcome.
Ed
Thanks, I will download and read.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Looks good to me. I really don't know how much more I can help though. I will follow the progress and add comments if I see something.
http://www.parallax.com/detail.asp?product_id=27937 - would the new memory stick datalogger be a way we could record info onboard (and later transfer for analysis)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 7/23/2007 9:32:52 PM GMT
PURPOSE:
to allow a bot to:
travel throught an area avoid hazards
know what area it is in.
be able to travel from one area to another
be able to return to where it started.
return, or navigate to a recharging station.
travel a predetermined path avoiding new obstacles if necessary.
I didn't include things like have a secondary map, and specifics because I feel that's more of how not what. please add if needed.
regarding the memory stick reader. I think that's an excellent solution.
not sure if I've mentioned this or not but I'm in the process of moving so my involvement on the site will be hit and miss for about 2 weeks, but after that I plan to hit that project hard.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster