[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Playing Field configuration?
On Sat, Jan 29, 2000 at 03:31:18PM -0500, Joyce Poon wrote:
> Interference system may be a total waste of time since the comp will have
> to pulse the signal(time wasted?) & given most grps are going to use high
> pass filters anyway, we'll probably enhance their chances of picking
> us/a signal up rather than diminish them.
This is a completely separate topic that should be in a separate
thread. However, 1) time wasted is not a problem. 2) my
understanding is that the chance of our being detected by the enemy is
a function of _their_ _sensors_, not their emittors, 3) we've
discussed this before and the only thing we agreed on was that it is
worth testing, which is something that was _always_ true.
If you want to go through the complete discussion again, let's do it
in person, since email won't work too well for this particular topic.
Suffice it to say that how effective it is quite depends on what type
of output signal their emittor gives (eg. square, or much longer with
a short duty cycle), and that a high-pass filter will filter-out
any signal that appears to be a long signal, while short spikes have a
greater chance of being interpreted as noise. It's all about the
Fourier transform. :) These signals will sometimes do one thing on
paper when you draw them as simple square waves but when you put it
through a filter and factors such as capacitance, attenuation, and
such come into play, less expected things can happen. This,
incidentally, is why I can say it does work (to some extent) on paper,
but may or may not work in reality.
A high pass filter works by only passing high frequency signals. If
you accidentally turn every third emission by the enemy's beacon into
a low frequency signal with a short spike in the middle, they will lose
(somewhat less than) a third of their signal. The low frequency will
be filtered out, and the short spike will be interpreted as noise.
There is also the side question of how much free time the computer has
to devote to the interference, but for now that's not an issue.
> I am thinking that bandpass filters may also be yet another waste of time.
> With so few obstacles & such a small play area, if 1 of them is
> reflective, hopefully we'll bump into it/run away from it a few times and
> then pick up the actual signal.
Agreed, mostly. Although, don't forget that a simple band-pass filter
is pretty easy to build. Unless there a __major__ changes in the playing
field from last year, I would be very surpised if reflected signals
were a problem at all.
> Forget toggle switches -- I don't want to be DQed. The robot will be
> checked before competition no doubt & Malone is not stupid.
Joyce, I would not have suggested it if I believed it was cheating.
First of all, it would not be hard to prevent Malone from noticing the
toggle switches if we wanted to, and I'm sure even he will admit that.
Moreover, I wouldn't have suggested it if I thought it was cheating.
Go reread the RFP if you think it's cheating. The RFP says absolutely
nothing about not being allowed to make adjustments to your robot on
the day of the competition. In fact, during his last lecture, Malone
even indicated that this is allowed --- his example was reconnecting a
wire that had been disconnected.
I'll admit there is some ambiguity, and if you're worried, we can ask
him for his considered opinion.
> Possibilty: Can we somehow write the map into the ROM after each run &
> upload to the RAM during play time?
> Or give the comp a separate power
> supply which switches on after each run to maintain the map in the RAM. It
Yes, this is possible. Remember that we need to use a common ground,
though. It's not hard to pull this off, provided we're careful, of
course. There are a number of little "gotchas", but I think they can
> of play. (Of course we don't know the original orientation of the robot
> either... can something be done in the program so the robot can eventually
> place itself in the original map?)
I think you overestimate the accuracy with which we can construct a
map. Maybe not, though. By the end of the week, I should be able
to make reasonable calculations on how accurate we can draw the
map, provided I know how often the opto-couples will be turning
Placing oneself back into the original map is difficult. Storing two
maps also increases memory requirements. I don't know if your idea as
stated is feasible for Qubit, however, it certainly is possible to
store basic parameters of the map --- dimensions being one example.
> Maybe we should ask Malone if the play area will reamin the same for the
> duration of the competition & whehter the start positions for the
> pursuer/evader will always be the same.
It would be difficult for him to change the playing area --- it's
surrounded by a crowd of people. It's certainly not something he
would do unless somebody suggested it to him. :) From the videos,
it looks like attacker and defender are always placed in the same
> The obstacles were all weighed down. Hence it might be difficult to to
> just push them around. If we really want to move it, consider ramming hte
> obstacle at high speed. (Big strain on motor circuitry & batteries).
Yes, the obstacles looked like they were heavily weighed down. I
don't think we'll be able to move them fast enough (if at all).
> However, with only 2 obstacles & shoddy software (I'm talking about the
> other grps here), one has to wonder how much confusion can moving one of
> the obstacles cause.
Agreed. Of course, we're not worried about the many groups with shoddy
software, we're worried about the few with good software. Nonetheless,
I think it would be difficult to move an obstacle in such a manner as
to benefit yourself.
> One last thought: fast robot is definitely a must for pursuing purposes.
> A not so fast, but way smarter robot is key to successful evasion.
I think you have it backwards. Recall the videos: when a robot fell
victim to its own stupidity, it was usually acting as the persuer.
Signature withheld by request of author.