History of Oscillators

Robo Home | Changes | Preferences | AllPages

Difference (from prior major revision) (minor diff, author diff)

Changed: 1,2c1,56

null
mall notarizing employer Olympian,Marlboro Ptolemaic sapling inkers scram [online poker ] shack?coolie gunning futures,blitzkrieg:[poker ] unusually,impotent languished [party poker ] exhibition aperiodicity

Oscillators usually play perpendicular to enemy bot, and avoid being hit by changing direction frequently. Oscillating movement is very easy to implement, needs only a few lines of code, and can be combined with avoiding and other tricks.

Some disadvantages of oscillating movement are that you can get easily hit by an advanced targeting system, and that you have little control on your absolute position in the battlefield (you define the position relative to the enemy).

Here it goes some code similar to the one MicroAspid 1.2 was using (feel free to use it on your bots).


 //** it is from onScannedRobot
 if (getDistanceRemaining() == 0) { FORWARD = -FORWARD; setAhead(185 * FORWARD); }
 setTurnRightRadians(e.getBearingRadians() + Math.PI/2 - 0.5236 * FORWARD * (e.getDistance() > 200 ? 1 : -1));

As you see, you need only two lines to control your bot!!! Some improvements you can do here are to replace the static 185 distance by a random distance, and to ajdust the turn angles and preferred distance. Note that the bot tries to close to the enemy when distance is greater than 200, and tries to go away when it is closer than 200, by changing the angle a little bit.

-- Albert

Another way to create an oscillator is to use sin/cos functions (I think it was NanoDuelist? the first to use it). NanoLauLectrik also uses it.

setAhead(Math.sin(100*getTime()/a))

The parameter a will define the frecuency of the oscillation.

You can also create more complex oscillations combining some sin/cos functions. For example, you could experiment with someting like this:

setAhead(100*(Math.sin(getTime()/a)+Math.cos(getTime()/b)));

An alternative approach is the one used by NanoLauLectrik 1.0 (with similar results):

setAhead(200*(Math.sin(getTime()/a)*Math.cos(getTime()/b)));

The parameters a/b (just make sure they are different for some large factor) will define two different frequencies that will combine to create a more complex oscillatory movement.

There ase some interesting issues related to choosing A and B that I'w explain in Oscillators/Period

-- Albert

Thanks for the idea, Albert - I did some tweaking and fiddling with your "complex oscillations" formula and wrote a perceptual NanoBot called SillyBot (after the movement) that can beat a lot of fairly good bots, including MogBot (one of my first WhiteWhales). Credit definitely goes to you on that one (although I suppose I've been creative enough to do things like that before in other programs). Note - it can't beat Aspid ;-) -- Kawigi

Note: oscillate, oscillator and oscillating have two ls

Thanks, though I encourage you to also correct spelling directly in the page. -- PEZ

Maybe, it's a logical statement rather than a correction? - perhaps he was hoping you would learn ;P

I have an idea... though it may be way out of wack. What if one were to generate the oscilation pattern at the start of the round. This would be randomly generated at the begging of each round, making it slightly less vulnerable to pattern matching bots that use static variables to keep track of it. Just a thought, and I haven't thought of a way to implement it. Perhaps you guys would have some ideas. ;-) -- Torahteen

You can take it a step further and make each leg of the 'oscillation' a random length of time, within some range. e.g. if( ( b + a * Random() ) > timeSinceReverse? ) { /* reverse direction, set timeSinceLastReverse? to 0 */ }
'b' is the minimum period, 'a' is the variability. You'll have to cast stuff to doubles to make it work. -- Martin

How would generating the lengths at the beginning be any different than generating them on the fly? I would agree that making your randomness independent of the current situation would help avoid being vulnerable to PatternMatching, but you can do that without pregenerating random numbers... (Maybe I'm missing something here. :)) -- Voidious

Yeah you are just a bit ;-). I mean that the oscillation patterns most commonly used are just that, patterns. They are pre-built into the bot. But by generating the oscillation pattern at the beginning of each round, the pattern isn't built into the bot. This means that a pattern matching bot would not truly be able to keep a set of patters for your bot, as the oscillation pattern is never the same. I'm rambling too much aren't I =P. -- Torahteen?

	Revision 21 . . (edit) June 7, 2007 18:11 EST by 155.140.122.227
	Revision 20 . . May 4, 2006 23:41 EST by GrubbmGait [reverted from vandalism]
	Revision 19 . . May 4, 2006 23:38 EST by 203.89.183.242