Subject:
|
Re: maze solving algorithm
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 10 Jun 2003 02:25:12 GMT
|
Original-From:
|
scott davis <rcx2man@hotmail.com#AntiSpam#>
|
Viewed:
|
2268 times
|
| |
|
|
Tomorrow I'm going to test it and see if it works so I'll let you know what
the results are. As to if I scaled back, I didn't. My original intent was
to have the robot search the whole maze and be able to start at the
beginning and take the shortest path to the finish. Hopefully this program
succeeds in doing this. I might be able to post a video clip of it, if it
works and I get a chance to put it on my website. While I'm at it, I'll
probably post the code there too if I works.
Scott
----- Original Message -----
From: "Steve Hassenplug" <hassenplug@mail.com>
To: "scott davis" <rcx2man@hotmail.com>
Sent: Monday, June 09, 2003 12:04 AM
Subject: Re: maze solving algorithm
> Scott,
>
> Did you come up with a way to actually solve the maze using NQC, or did • you scale back your goals?
>
> I was working on a maze robot for a contest this past weekend. I ran out
of time, but I think I have it working in BrickOS. Why did you give up on
BrickOS? I assume it's because you couldn't get it set-up. I think that's
common. It's pretty tough to get working.
>
> I'm very interested to hear what you've ended up doing.
>
> Thanks
> Steve Hassenplug
>
> ----- Original Message -----
> From: lego-robotics@crynwr.com (scott davis)
> Date: Sun, 8 Jun 2003 06:11:14 GMT
> To: lugnet.robotics@lugnet.com
> Subject: Re: maze solving algorithm
>
> > I'm back to working with NQC. I gave up on brickos. I think I have a
> > program that works, I just need to find some time to test it.
> > Thank you for your help.
> > Scott
> >
> > ----- Original Message -----
> > From: "Bluey" <Wolf_and_eagle@spamblock.yahoo.com>
> > To: <lego-robotics@crynwr.com>
> > Sent: Saturday, June 07, 2003 10:32 PM
> > Subject: Re: maze solving algorithm
> >
> >
> > > Ok, so did you get the idea about using the Binary system to identify • the
> > > "cell"?
> > >
> > > Now, the next choice is what type of variable to use:
> > >
> > > You can use a small 16 bit variable for each "cell" which will take up • 400
> > > bits=50 bytes. This was will conserve less memory, but it will make it • easier
> > > for the robot to uncompress the data.
> > >
> > > Or, you can use a larger 32 bit variable to hold more info efficiently • at
> > 32 *
> > > 5=120 bits=20 bytes. This down side to this is, it will take more time • to
> > > uncompress this, and it won't fit in a an array as well (since each • variable
> > > would hold 5 of the "cells"; therefore needing an extra subroutine to • extract
> > > the number.)
> > >
> > > I'm going to assume you chose the 16 bits per cell in an array option.
> > > Instead of wrapping our cell info into a 2 digit number, we can leave • the
> > raw
> > > binary info in the 5 digit variable. So, if our "cell" has no walls, • we
> > can just
> > > enter the number 00000 into the variable.
> > >
> > > Now for the next problem. The robot now has the ability to maneuver • and
> > map a
> > > 5x5 maze, but one thing that might not come to mind is the robot • doesn't
> > know
> > > where it is in the map when you start it out. For all it knows, when • it
> > enters
> > > the maze it could be in the middle of the bottom of the maze, or to • the
> > left or
> > > the right. Unless it know where the entrance is, it won't know where • to
> > place
> > > the map info it gathers. Make sense?
> > > The only two options I can think of are, 1. Have the entrance of the • maze
> > at a
> > > standard point in the maze (I.E. 3 "cells" from the right")
> > > (provided you are going to start the robot on the outside of the maze • going in
> > > through an entrance), or 2. Have the robot construct a temporary map • that
> > is
> > > [(2*5)-1]x[(2*5)-1]=9x9 so that no matter where you put it to enter • the
> > maze, it
> > > start its mapping in the middle of the maze in it memory (I.E. • coordinates
> > 5,5),
> > > and will have space to fit.
> > >
> > > I don't know how you would create "temporary" variables in BrickOS • unless
> > you
> > > used disposable inline variables or classes (if those can be • deconstructed
> > at an
> > > earlier time). The problem is that the temporary map would need to be • used
> > as
> > > the main map until it figured out where it was......
> > >
> > > Or here is another idea, have the robot use a 5x5 memory map, and have • it
> > think
> > > it starts at (3,3). Then as it finds that a passage is actually the • edge
> > of the
> > > map, have it move the known map over one "cell" to accommodate the new • info. In
> > > other-words, if you start the robot actually at the bottom middle of • the
> > maze,
> > > and the robot starts at (3,3) (in its map) and then it moves • "up/north" 2
> > > "cells" (physically and in its map) then in its map, it will reach the • top,
> > > middle "cell" of the "map in memory". Therefore, when it moves "north" • one
> > more
> > > space, it will be off the map, it could then see if there is an empty • row
> > at the
> > > bottom of the map. If there is an empty row, it could move all the • cells
> > down
> > > one space knowing that the map was oriented too far "north" compared • to
> > the
> > > actual maze.
> > > Do you understand? if not, I'll try explaining it again.
> > >
> > > I'm sorry if this is complicated or confusing. I'll try to elaborate • on
> > anything
> > > I didn't make clear.
> > >
> > > Timothy
>
> --
> _______________________________________________
> Get your free Verizonmail at www.verizonmail.com
>
>
|
|
Message has 1 Reply:
4 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
