To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.org.ca.rtltorontoOpen lugnet.org.ca.rtltoronto in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Organizations / Canada / rtlToronto / 15264
15263  |  15265
Subject: 
Re: [rtlToronto] rtlToronto20 Draft Rules Posted
Newsgroups: 
lugnet.org.ca.rtltoronto
Date: 
Wed, 23 Nov 2005 23:44:28 GMT
Viewed: 
694 times
  
In lugnet.org.ca.rtltoronto, Derek Raycraft wrote:
Never answer an email when you're pissed off.
Hey Calum, hows it going?

Doing just fine, in fact.  I'm actually getting MORE interested in this contest
day by day.

I'm not saying you have to, I'm just saying if you can it improves your
chances of transferring blocks to more robots.

I don't see this, but I'm going to move on to the crux of the issue below.

Ok, but what I'm saying is your rule to make things "easier" does little
to actually make it easier for everyone, and excludes what is otherwise
a valid strategy.  It's my position that you are limiting the game with
a rule that adds little or no value to making the game easier to play.

I hear where you're coming from, but I am not convinced it doesn't mean anything
to the most basic robots.  But I will read on...

If you believe Chris, he thinks we'll have ten robots in the field.  Assuming
you are surrounded by ten light sources, your method listed above would result
in a robot spasming in the middle of the field, unsure of which "moved" light
source to track.


Could you explain why this would happen.  Even Chris's sample robots
wouldn't do this.

From how I understand Chris' robots actions:

Search:
-Spin the sensor around
-Look for the brightest spot
-Turn towards it and drive for a unit of time
-Is the touch bumper active?  No?  Repeat Search.

Now, if there are ten moving spots, varying in brightness and location, what
could happen is:

Search:
-Spin the sensor around
-Look for the brightest spot (It's at 45 degrees!)
-Turn towards it and drive for a unit of time  (I'll go Northeast)
-Is the touch bumper active?  No?  Repeat Search.

Search:
-Spin the sensor around
-Look for the brightest spot (This time it's at 79 degrees!)
-Turn towards it and drive for a unit of time (I'll go East)
-Is the touch bumper active?  No?  Repeat Search.

Search:
-Spin the sensor around
-Look for the brightest spot (This time it's at 180 degrees, behind me!)
-Turn towards it and drive for a unit of time (Better go West)
-Is the touch bumper active?  No?  Repeat Search.

Search:
-Spin the sensor around
-Look for the brightest spot (Wait, I think it's 145 degrees, behind me again!)
-Turn towards it and drive for a unit of time (Let's go back East again)
-Is the touch bumper active?  No?  Repeat Search.

Search:
-Spin the sensor around
-Look for the brightest spot (This time it's at 192 degrees, behind me again!)
-Turn towards it and drive for a unit of time (Let's go back West again)
-Is the touch bumper active?  No?  Repeat Search.

So the robot keeps going around in the middle, never really getting anywhere.
Because assuming ten points, coming in and out of view, you there's a very good
possibility they will form a ring around your robot.

Now, someone clever could write some code to intelligently filter those
reflections/moving spots.  But I'm not sure how feasible that is.  For example,
one of the harder contests at your typical hobby robot games is the fire
fighting robot game, and you only need to find ONE light source, the flame.

but I thought that was obvious, so I left it out.

It is obvious, but your cases only add one extra possibility.

No change for the non light follow robot, one additional opportunity for
the light following robot if the light is left on all the time.

That's the part I disgaree with.  I don't think (see above example) that the non
light following robot has no change.  I believe (and I can't say for certain)
that the presence of ten lights always on, moving or not, means noise for the
system to deal with.

What exactly is going to confuse the "dumb" robot.  Give me the scenario
and why it's confusing.  I've run through a full set of example cases
showing no difference for the "dumb" robot whether you turn the light
off or leave it on all the time.

For you to use the example cases makes the assumption one would agree that no
difference exists for a dumb robot to deal with a multitude of moving lights.

-spin around and stop when your light reading crosses a threshold.
-head towards that light.
-if you find the robot in a reasonable distance do your transfer thing
-if not spin again.

Now the transfer thing is way more complex then this, but at least you
can find the robot regardless of whether the light is turned off when
moving or not.

Now there is a greater chance of false positives if the light is on all
the time.  But I don't believe it's going to be significant.

The scenario I fear is like the vacuuming robot in a room with a cat.  The cat
jumps in front of the robot wherever it goes, and the robot assumes a wall is
there.  By the end of the afternoon, the robot is stuck in the middle of the
room, having walled itself off because the cat keeps bounding it in.

The halo of lights from multiple robots, constantly changing, I think will bound
the robot in.

Also don't forget there is going to be at least one light sensor on
every robot.  And every light sensor has a nice red light perfectly
tuned for the sensor to pick up.  You are going to have to account for
moving lights whether you like it or not.

That's a good point.


Let me propose a different solution:  If you believe in Chris' social
experiment, how about you propose your own "moving robot beacon" light, eg, on
the bottom of the robot near the ground?  Anyone who wanted to find you and
feels they can track you satisfactorily, should watch there and also keep a
light on down there.

You can post it on this newsgroup and see if anyone bites.  Those of us people
who find it "to" hard, won't use it, and continue with the light as specified to
be on when stopped.

Calum



Message is in Reply To:
  Re: [rtlToronto] rtlToronto20 Draft Rules Posted
 
Never answer an email when you're pissed off. Hey Calum, hows it going? (...) I'm not saying you have to, I'm just saying if you can it improves your chances of transferring blocks to more robots. (...) Ok, but what I'm saying is your rule to make (...) (19 years ago, 23-Nov-05, to lugnet.org.ca.rtltoronto)

30 Messages in This Thread:









Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR