Talk:Zoom Radar

There seems to be a lot of errors regarding rendering LaTeX. Is there a way to resolve this? --Frolicking Zombie 17:53, 26 February 2010 (UTC)

Ok, I'm looking into it... --Voidious 18:08, 26 February 2010 (UTC)

Some comments

Heh, actually, inspired by what you had on your talk page, though doing the math a bit different, I've already implemented something along these lines in Glaicer. Take a look at Glacier's "ags.muse.radar.MeleeRadar" class, which IMO is much cleaner. It also looks really spiffy in action. Also, the math here is wrong, in that one gets the most change in angle by moving along a chord of the circle created by the distance to the enemy bot, and that fact also simplifies the math to calculate the uncertainty in angle to the following:

            double maxMoved = rules.MAX_VELOCITY*bot.getDataAge();
            double uncertainty;
            if (distance * 2 > maxMoved) {
                uncertainty = 2*Math.asin(maxMoved/(2*distance));
            }
            else {
                uncertainty = Math.PI;
            }

Essentially a single arcsine with a special condition for when they haven't been seen in so long that their angle is completely unknown (i.e. could be PI radians different in either direction).

Another note, is that in order to be accurate enough to ensure you don't slip when being this precise, it's also necessary to count the change in radar origin position caused by one's own movement.

Also, why the name "Zoom Radar"? I don't see any "zooming". --Rednaxela 17:54, 26 February 2010 (UTC)

The triangle formed in your equation would be the equivalent as if the robot traveled along the tangent created by the targetDistance circle. This creates slightly less of an angle (which promotes slip) than if you calculate the intercept of the targetError and targetDistance circles. BTW, why would you use (2*distance) as the hypotenuse of your triangle? --Frolicking Zombie 18:13, 26 February 2010 (UTC)