Optimum Goto Driver

From RoboWiki
Jump to: navigation, search

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.

You can view and copy the source of this page:

Return to Thread:Talk:GoTo/Optimum Goto Driver.

Goto code is crucial for goto surfing and melee movement, however the code listed in this page is not optimal, there are cases that all these methods give wired behavior.

I did some numerical analysis on some simplified model of goto driver, and the result indicates some boundary with shape like r = tan(b θ), -π/2 < θ < π/2, 0 < b < 1, where all destinations within this area is best turning with full speed & going with full speed afterwards, and all destination outside this area is best going with full speed from start & turning at the same time. Destinations near the boundary (the margin is narrow, though) is best turning with max speed at first while accelerating at the same time (and reducing turning rate as a result, per robocode physics), being an intermediate of the both extreme.

Edit: As the robot moves, points inside the area should be quickly falling into the boundary region, then being outside of the area. This behavior indicates that even for points inside the area, an optimal way is turning with full speed at the start, then starts accelerating, and move with full speed finally.


The graph shows the relationship between optimal initial turning radius and initial state where d is the distance to destination, θ is the bearing to destination relative to heading. The result is obtained via numerical analysis on a model that ignores velocity changing rules.

I made a goto driver with some approximation of the above result, it does behave much better, but doesn't look optimal as the approximation is rough.

Then I think we may find an optimum goto driver via calculus of variations, any ideas?

Origin (talk)23:10, 16 August 2019
Personal tools