Subject:
|
Re: Rover Programming
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 24 Jun 2002 19:30:09 GMT
|
Original-From:
|
Simon Brooke <SIMON@JASMINE.nomorespamORG.UK>
|
Reply-To:
|
simon@jasmine=NoSpam=.org.uk
|
Viewed:
|
907 times
|
| |
|
|
On Tuesday 11 Jun 2002 2:35 pm, Jason Hensler wrote:
> I Like your idea and mine was a lot like
> http://news.lugnet.com/robotics/?n=11951. I thought of using the rcx
> as a scout and finding the path. It would relay the data back to the
> pc and the pc would create and download a program that would drive
> the rcx to end of it's map.
OK, why does it need to communicate with the PC?
The primary problem is dead reckoning navigation - which is hard on the
'out of the box' RIS because it's very hard to make a robot that can
turn a controlled amount or travel a controlled distance.
With two rotation sensors you can build a robot which can do dead
reckoning in the same way as a LOGO turtle, although of course if it
hits an obstacle that causes a wheel to slip it will lose track (I'm
currently working on a design which has two undriven wheels connected
to rotation sensors 'underneath' the driven wheels, which may help
correct this).
The alternatives would be to use a compass for heading information (but
this is not very precise, and in any case hard to do) and just timing
for distance, or - best but hardest of all - hook up a GPS.
Actually mapping the domain is not hard and can be done in any decet
programming languages. There are two fundamental possiblities:
(1) Create a two dimensional array of bits. Treat each bit as a square
unit of floor. The size of the unit is up to you. If the robot is able
to traverse the square, it leaves the bit clear; if it hits anything,
it sets the bit. It can build up its map either by doing a box search
of the domain (i.e. trundling up and down like a lawnmower) or just by
random walking it.
From any point it can then plot the shortest route home which does not
pass through any marked square.
A subtler version of this algortight which can cope with a domain in
which there are moving objects is to use a two dimensional array of
nibbles or bytes, and to increment a square's value each time you
encounter an obstacle in that square.
(2) Create a linked list of linked lists. Each time you hit an
obstacle, create a new linked list with one item, the x/y coords of the
point at which you hit it. Then follow the perimeter of the obstacle
round recording your position on the linked list every so often. When
you return to the starting point of this linked list, end that linked
list and go and look for the next obstacle. You can then again
calculate a route to any point which doesn't pass through any of the
obstacles you've mapped.
This takes a lot more processing but is good for domains in which
obstacles are sparse. The advantage of the bitmap is that it's easy to
process; the disadvantage (particularly in 32k of RAM) is that you
can't map an area in very great resolution.
--
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; Semper in faecibus sumus, sole profundum variat.
|
|
Message has 1 Reply:
 | | Re: Rover Programming
|
| (...) Yep - VERY difficult. (...) It's *really* hard with any of the Lego Firmware options (eg NQC) because you can't access really large amounts of RAM. However, you could stand a chance with LegOS and GCC. (...) Unfortunately, you need THREE (...) (22 years ago, 26-Jun-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Rover Programming
|
| I Like your idea and mine was a lot like (URL) I thought of using the rcx as a scout and finding the path. It would relay the data back to the pc and the pc would create and download a program that would drive the rcx to end of it's map. I was (...) (22 years ago, 11-Jun-02, to lugnet.robotics)
|
24 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
