# Thread:Talk:GoTo/Optimum Goto Driver

m |
m |
||

Line 3: | Line 3: | ||

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. | 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 | + | 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 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. And for points outside, going with full speed at the start is preferred. |

[[Image:Optimum-goto-1.png|469x643px]] | [[Image:Optimum-goto-1.png|469x643px]] |

## Latest revision as of 04:03, 15 August 2019

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 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. And for points outside, going with full speed at the start is preferred.

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?