Subject:
|
THOUGHTS on mapping with Lego Robot ( added to searching walls)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 27 May 2003 16:38:09 GMT
|
Original-From:
|
Bill Blackmer <bill@bbccd.org*Spamless*>
|
Viewed:
|
1110 times
|
| |
|
|
Hello,
What I want to do is take a five foot by five foot square, put random items
in the square, MAP THE SQUARE AND OBSTACLES and run our dog robot around the
course and never have it stop. I do not want to do obstacle avoidance (that
is much easier) I want to build a map and work from it.
This is very HARD problem (for us). My son and I have worked on this for
several months or years or lifetimes. So we are looking for help. Is this
possible? Are we asking too much?
We have many, many pages of notes on this subject however a short version:
How well does a Lego sensor measure a distance? (Poorly) If the
sensor readout says 10.5 inches - is it really?? (Not usually) IF you
measured the same distance with the same sensor from the exact same spot
would you get the same answer? (Usually not) ((Especially hours or days
later - power drain issues among many others)) (((Yes, a difference of 1/2
inch is massive)))
If the obstacles are truly random can a Lego sensor find the next
random item and build a compass heading to that item? What if the sensor
notices multiple obstacles which one does he map and how does he know which
obstacles have been mapped?
What are the sizes of the obstacles and what is the size of the
robot doing the mapping?
Does the sensor measure to the middle of each side of each
obstacle it sensors or just the edge closest to the sensor?
No wires from the robot to the PC. The PC maintains a real-time picture of
the map and the location of the dog to provide instructions to the dog. (The
dog has two RCX's and line-of-sight to the PC.)
The initial idea was a mapping robot and then the robot dog.
To do this, we have acquired several HiTechnic Sensors (these sensors are
much more accurate then the Lego sensors - Compass, Ultrasonic and Infrared
Range Sensors); and we have created several statistical averaging and
correction algorithms, etc.
So we have this working some of the time. We cheat a bunch. We always place
the mapping robot in the same starting position with a known distance to a
point and the known compass heading to the point. We then have the robot
find and measure this point 10 times so that we can gather the statistics to
build our correcting algorithm input. (Why 10? That's all the fingers I
have!) Just the math averaging and correction algorithms run several pages.
Lastly we use Robolab for this. We can use Labview for Robolab.
Any thoughts OR HELP!!!
Thanks,
Bill and Daniel
PS Anybody who wants to sale a HiTechnic Color Sensor please eMail me. I
have several high tech stock options you can have in trade!
-----Original Message-----
From: Steve Baker [mailto:sjbaker1@airmail.net]
Sent: Tuesday, May 27, 2003 5:03 AM
Cc: lego-robotics@crynwr.com
Subject: Re: searching walls
> > The start position/orientation don't have any restriction.
> > I'm working with 2 rotation sensors(each per left/right motor-wheel) and • 1
> > ultrasonic sensor(technicstuff) that can rotate(but without rotation • sensor
> > because are 1 RCX), with leJOS.
If you use an adder/subtractor mechanism for driving the robot then
you can have one rotation sensor measuring how much you are turning
and the other measuring how far forwards you are driving.
Then, you can have the ultrasonic sensor driven from the same output
of the adder subtractor mechanism as the 'forward/backward' rotation
sensor. As the robot drives along, the sensor will be rotatated and
your software can continuously measure the distance out in any direction.
Alternatively, you could remove the forward/backward rotation sensor
and use the ultrasonic detector (pointing forwards) to figure out how
fast you are moving by measuring how rapidly the distance to the next
wall decreases. That frees up an RCX input that you can use to measure
the direction the ultrasonics are pointing.
However, through all of this, beware. The lego rotation sensor has
a tendancy to lose or gain counts when it's rotated very slowly.
This can result in a cumulative error that would mean that your
idea of which way you are steering (or pointing the sensor) would
gradually get less and less accurate.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V--
PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: searching walls
|
| (...) If you use an adder/subtractor mechanism for driving the robot then you can have one rotation sensor measuring how much you are turning and the other measuring how far forwards you are driving. Then, you can have the ultrasonic sensor driven (...) (21 years ago, 27-May-03, to lugnet.robotics)
|
12 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
