Talk:Radar

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)

//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.

Hi mate I'm not sure how you calclulate the 20% fail rate, but to me it looks the whole radar needs a second thought. If you change the direction every time you have collected all opponents you end up with a very bad average scan rate. Imagine your first and last scan target are very close together, that would mean you have an average scan of 8 turns till you see them again. I guess you need some sort of tick counter and if this counter is greater 4 and you have not seen all targets, clear the set and don't change direction. Another problem is, if you scan the last target and it moves the next turn out of the scan arc, your radar needs a whole circle to find this last target again, because it was cleared. Maybe i'm not very good in explaining it, but hopefully it can give you the idea.

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.