View source for Talk:Radar

Noobish Question

Hi im trying to implement the wide lock in my robot and it locks but how do i get the gun to point at the robot? --Dec101 10:41, 9 March 2011 (UTC)

You'd want something like this in your onScannedRobotEvent(ScannedRobotEvent e):

  double absBearingToEnemy = e.getBearingRadians() + getHeadingRadians();
  double gunHeading = getGunHeadingRadians();
  double turnAmount = robocode.util.Utils.normalRelativeAngle(absBearingToEnemy - gunHeading);
  setTurnGunRightRadians(turnAmount);

That should get you started. :-) We call this Head-On Targeting. --Voidious 13:25, 9 March 2011 (UTC)

Thanks!--Dec101 23:51, 10 March 2011 (UTC)

Zoom Radar

I just posted a melee radar called Zoom Radar. What would be the best method to link this to the radar page? This is certainly theory/code heavy, and may not fit well with the little code snippets. --Frolicking Zombie 17:58, 26 February 2010 (UTC)

Mind if I work on this after I get my page put togeather? --Chase-san

Not a problem. It is a wiki, after all. --AaronR 07:46, 12 November 2007 (UTC)

I fixed some spelling / grammar stuff as well as did some revising of stuff that was a bit verbose or just seemed a little off (like mixing turnRadarRight and turnRadarRightRadians in the same code snippet). I'd never heard of a "Perfect Lock" as a proper name like that, so I edited that part a little, too. The "wide radar" code could be a lot shorter, but I don't have time to make sure I get it right at the moment. Nice job with the page, Chase, it looks great. --Voidious 14:30, 12 November 2007 (UTC)

I made the first and last bits of the page. AaronR added the first set of snippets, I just added the wide radar and information on the Melee radars (as I don't know a great deal about them). The wide radar could indeed be a lot shorter. I can probably fix that after class. --Chase-san 14:33, 12 November 2007 (UTC)

Code location/turn skip

In robots that do a lot of processing, it is best to place the radar code near the beginning of the processing loop for each tick, as this will allow the radar to avoid slipping if the robot skips a turn due to too much processing.

While I realize I was the one that wrote this originally, this was before we discovered that a robot, that went it goes over the time allowed, skipped the next turn, and did not get tis current turn simply cut short. So I suggest removing this entire paragraph. --Chase 23:40, 22 April 2009 (UTC)

So anyone agree/disagree with this, has this been changed in the code or what? --Chase 19:06, 21 July 2009 (UTC)

Yeah, I say remove it, as it won't help with skipped turns. (I misunderstood how skipped turns worked for the longest time!) --Voidious 19:15, 21 July 2009 (UTC)

Hi, I have a strange problem. I was playing around with linear and circular targeting. I always used (earlier on, but also last week) the narrow lock described here. It works fine alone, but as soon as I add some other code, like for example the linear targeting code from here, to the onScannedRobot method, it's slipping all the time! Does anyone have an idea why this could be the case? I thought of those mysterious "skipped turns", but even if I multiply it with a factor 2 as described, it slips quite often.
Plus, last week I had a robot who used 2 guns at once in that method with the narrow lock (without factor) and it worked fine. I'm kind of depressed right now, hope you can help me. It has to be something rather trivial that I'm not getting right now. Greetings, --Kenran 17:37, 29 November 2009 (UTC)

If the only thing you changed is your targeting, which now is causing your radar to not work, it sounds like somehow that's changing your radar system. Do you have setAdjustRadarForGunTurn(true)? if you don't have that, then whenever you turn your gun, it will cause your radar to move a bit too, possibly causing the radar to fail. Spinnercat 17:46, 29 November 2009 (UTC)

Hi, too bad you answered, I was just about to delete my posting, since I found out that I really forgot to write that *g* As always with stupid things, I solve them just after having asked. Very embarassing indeed... Thanks for your answer! --Kenran 17:58, 29 November 2009 (UTC)

Renaming 1v1 Perfect Locks

I suggest the two perfect 1v1 radar locks be renamed in the following way:

• Narrow lock ⇒ Factor lock. The code behaves rather differently depending on what factor you multiply by. Narrow lock is just a special case when you multiply by 1. We could also move all the explanation about slippage and calling scan() further down, since most people will just choose a factor of 2.0 and never think about their radar again.

• Wide lock ⇒ Area lock. This code ensures a certain "area" (as in a certain distance to either side of the robot) is covered by the radar whenever possible. You could choose any distance to either side, the value used in the sample code is just the most common. This lock isn't necessarily "wider" than the narrow lock—you could choose a factor of 2.1 to get a really wide "narrow" lock. It also creates a nice effect of widening the scan area as the enemy gets closer—which looks cool if nothing else.

—Duyn 13:12, 25 January 2010 (UTC)

I object the change.

• From what I understand, Narrow lock get its name for two reasons:
  1. The scan arc is narrow, of course.
  2. If the target is still, the are will get narrower as the time passed.
• I agree with "which looks cool if nothing else." But the name "Area lock" make me think of pointing radar to just one point on the battlefield. It reminds me about "Area Targeting". And I think it get its name because it move radar "wide" enough to cover enemy's full robot.

--Nat Pavasant 13:44, 25 January 2010 (UTC)

• For many possible factors, narrow lock is not that narrow:
  1. The scan arc for a narrow lock is only narrow if you choose factor 1.0 or you choose factor 2.0 and the enemy is not close to exactly half way between whole multiples of the radar turn rate when you pick them up (which admittedly is most of the time). It is possible (though rare) for a factor 2.0 lock to result in a wide scan arc. In practice, factor 2.0 lock often produces locks which are narrower or about as wide as a Wide lock which scans one robot width to either side.
  2. If the target is still, narrow lock will only get narrower over time if you choose 1 < factor < 2. If you choose factor 2, it will always scan the same amount. If you choose factor ~ 2.1, the scan will gradually grow to cover the maximum scan area. If the target is moving, it actually snaps back down to a narrower scan every now and then—I haven't looked into why this happens. The point is, a narrow scan arc is just one of the outcomes you can get using this code.
• Perhaps Distance lock would be a more appropriate name. I think we should re-name the locks to better reflect the essential characteristics of each method—factor lock scans by a factor to either side, while distance lock keeps a certain distance to either side of the robot highlighted.
• "Wide lock" makes one think the area it covers is wide. This is often not the case. Also, Infinity lock covers the widest area. You could use a distance of 1 instead of getWidth() and you would get behaviour m uch like a factor 1.0 narrow lock. In fact, if you wanted behaviour like a factor 1.0 narrow lock, this would be the preferable way to implement it since you wouldn't need to call scan() manually.

—Duyn 02:14, 26 January 2010 (UTC)

I'd agree that 'wide' and 'narrow' are not great terms for them, but I'm not sure I care for 'distance', 'factor', or 'area' either. For "narrow lock" I'd suggest something more like "turn multiplier lock" (since it's a multiplier on the radar turn) and "width lock" (since it's a fixed width at any particular distance). One semi-related note is I plan to soon document what I call an "uncertainty lock" which is what Glacier uses for melee but also makes a nifty 1v1 lock with nice accounting for skipped turns and such. --Rednaxela 02:36, 26 January 2010 (UTC)

I still prefer the old narrow and wide, but I think I am just used to them being called that regardless of how descriptive the names are. --Chase 21:02, 13 April 2010 (UTC)

As a note however, out of name alternatives, I like yours the best. However for wide lock, perhaps 'Overscan Lock' might be better for wide, since it is scanning more then it needs to, to assure a perfect lock. --Chase 17:53, 14 April 2010 (UTC)

Questions

Um quick question... I am using a narrow lock radar, and I was wandering, if it does slip is there a way for it to go back to scanning so it can lock again, or if it is used in melee, is there a way for it to scan for new bots after the original target was killed? Thanks :) --Exauge 02:36, 13 May 2010 (UTC)

All you do is spin the radar when the current target is not locked on to. If your 'narrow lock radar' is implemented in the onScannedRobot handler, the simplest way to accomplish this would be do what the 'infinity lock' example on the page does: Set radar turn in both onScannedRobot and in the robot's main loop. That make sense? --Rednaxela 05:01, 13 May 2010 (UTC)

yep that helps - i got it to work. thanks :) --Exauge

is it possible to keep turn the radar (as in infinity lock) even while waiting for a condition? I need a way to keep the infinity lock working while waiting for conditions for my SuperSample.SuperBoxBot --Exauge ◊ talk 21:59, 12 August 2010 (UTC)

If you are using waitFor, I don't think so, but you can emulate this in a non-blocking fashion using a custom event. — Chase-san 22:04, 12 August 2010 (UTC)

You can only use custom events in AdvancedRobot. Not sure if you guys are sticking with Robot for the Super Sample Bots... --Voidious 22:19, 12 August 2010 (UTC)

As long as you didn't do waitFor() in onScannedRobot(), it should work fine, assuming that you have setTurnRadarRight(Double.POSITIVE_INFINITY) before the waitFor() line. (actually it should work with waitFor() inside the onScanendRobot too, but not sure) --Nat Pavasant 03:24, 13 August 2010 (UTC)

Well i have a method called from onScannedRobot after the lock that uses waitFor() it seems to just pause all execution until it returns. I'll try with the custom condition and if that doesnt work ill try to come up with some sort of conditional statement. --Exauge ◊ talk 03:35, 13 August 2010 (UTC)

Narrow lock vs Wide Lock

I was wondering which is better to use for one on one. I was also wondering if 1.9 is better corrective factor than 2.0 in 1 on 1 narrow locks or does 1.9 slip more often. And why do most programmers us the corrective factor of 2.0 if it ends up wider than a wide lock most of the time? And does a wide lock slip more often than a narrow lock? --Moyamo 20:25, 23 December 2010 (UTC)

It does not matter what factor you use, as long it is more or equal to one. A perfect lock should not slip at all. It depends more on the programmer how he wants to show the radarbeam (read: intimidate the viewer). Some bots calculate each tick the angle of the sweep, for instance to cover precisely the botwidth of the opponent. --GrubbmGait 00:40, 24 December 2010 (UTC)

I found that any factor over 1.5 nearly never slip. 1.9+ never slip at all. But I use 2 because it work just the same as save me time to type extra two characters. (Really, most programmer are lazy) --Nat Pavasant 12:44, 24 December 2010 (UTC)

Thanks I'll continue to use 1.9 as a corrective factor on one on one --Moyamo 05:54, 4 January 2011 (UTC)

//code size 81, failure rate 20% (at start of match)
static HashSet<String> scanned = new HashSet<String>();
static double direction = Double.POSITIVE_INFINITY;
static int others = 9;
public void run() {
	turnRadarRightRadians(direction);
}
public void onScannedRobot(ScannedRobotEvent e) {
	scanned.add(e.getName());
	if(scanned.size() >= others) {
		scanned.clear();
		setTurnRadarRightRadians(direction = -direction);
	}
}
public void onRobotDeath(RobotDeathEvent e) {
	--others;
}

I was poking around trying to come up with a small but smart melee radar. This is the best I have come up with and it still fails 20% of the time to find an optimal scanning path when one exists (at the start of the round). An optimal path doesn't exist approximately 12% of the time. Anyone else have anything better? I don't like that failure rate or the inoptimal scanning when an unfavorable position exists.

The sample size was fairly small since I did it by hand. But the key point is, "when one exists."

But know of the problem you mentioned and it does happen. But when one exists means generally means one of two things. Either you are in a corner, or you are on an edge. In a perfect world, the first means you have a 75% chance of pointing away from all opponents, where as the other you have about a 50% chance (the actual percentages are much different since you are not perfectly on the edge, etc). The other cases were where such an arc did not exist.

I know the radar isn't perfect, which is why I am not claiming it as a solution. I did have a tick counter of sorts, but it was to help it find a better distribution. Which had about the same failure rate, which is why I omitted it. As for the last part, that is possible, and it could very likely happen. I will see if I can improve it any based on a revision of the tick idea.

Looks like it will miss locks on 2 occasions.

- When a bot gets out of range, making the radar do a full spin.

- And when a bot is in an angle too close to where the radar ends. When the radar reverses direction, it might miss that bot and then do a full spin. It would be better to keep turning the radar in the same direction a bit more. Only it will require a lot more trigonometry and codesize to calculate how much.