Difference between revisions of "Talk:Zoom Radar"

From Robowiki
Jump to navigation Jump to search
(Created page with 'There seems to be a lot of errors regarding rendering LaTeX. Is there a way to resolve this? --~~~~')
 
(→‎Some comments: new section)
Line 1: Line 1:
 
There seems to be a lot of errors regarding rendering LaTeX. Is there a way to resolve this?
 
There seems to be a lot of errors regarding rendering LaTeX. Is there a way to resolve this?
 
--[[User:Frolicking Zombie|Frolicking Zombie]] 17:53, 26 February 2010 (UTC)
 
--[[User:Frolicking Zombie|Frolicking Zombie]] 17:53, 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 [http://homepages.ucalgary.ca/~agschult/robocode/ags.Glacier_0.2.7.jar 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:
 +
<pre>
 +
            double maxMoved = rules.MAX_VELOCITY*bot.getDataAge();
 +
            double uncertainty;
 +
            if (distance * 2 > maxMoved) {
 +
                uncertainty = 2*Math.asin(maxMoved/(2*distance));
 +
            }
 +
            else {
 +
                uncertainty = Math.PI;
 +
            }
 +
</pre> 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". --[[User:Rednaxela|Rednaxela]] 17:54, 26 February 2010 (UTC)

Revision as of 19:54, 26 February 2010

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)

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)