-- PEZ |

I have observed, for a very long time, that my bots often fail to optimize the turn-angle. I don't understand why, but I have studied code from some OpenSource bots in the hopes of finding a GoToBot that succeeds in this. To my surprise I discovered that iiley's bots are goto-bots. Surprising because I have often studied the source of these bots without noticing this. Most of these bots are minis and they take quite a few turns in order to shrink codesize... Anyway, here's a translation of how iiley does it. (From comments in the code, credits should go to David Alves and Dummy here, but I'm not sure if they mainly contributed to the obfuscation, eh ... shrinkage ... or the algorithm as such).
You just pass the distance you want to travel and the bearing (in radians) to this function and it will sort out the shortest way to turn and what direction (forwards or backwards) to drive. The "atan(tan(angle))" stuff there does a sort of lossy normalization of any angle to the "-PI/2 -> +PI/2" space. It works much better than in my old goTo() functions. So here is the quite codesize-small goTo() of the development version of Tityus:
-- PEZ |

When moving your robot around you want it to respond as quickly as possible. Reversing your movement direction goes much faster if you drive backwards instead of forwards and turn the robot 180 degrees, right?

I have observed, for a very long time, that my bots often fail to optimize the turn-angle. I don't understand why, but I have studied code from some OpenSource bots in the hopes of finding a GoToBot that succeeds in this. To my surprise I discovered that iiley's bots are goto-bots. Surprising because I have often studied the source of these bots without noticing this. Most of these bots are minis and they take quite a few turns in order to shrink codesize... Anyway, here's a translation of how iiley does it. (From comments in the code, credits should go to David Alves and Dummy here, but I'm not sure if they mainly contributed to the obfuscation, eh ... shrinkage ... or the algorithm as such).

There are several methods to do this.

- Check Movement/CodeSnippetGoTo for one way of doing it.
- Also BlackWidow/Code has code for it, though slightly different. This code originated somewhere. I found it in Cigaret, which I think mentioned its source.

I have observed, for a very long time, that my bots often fail to optimize the turn-angle. I don't understand why, but I have studied code from some OpenSource bots in the hopes of finding a GoToBot that succeeds in this. To my surprise I discovered that iiley's bots are goto-bots. Surprising because I have often studied the source of these bots without noticing this. Most of these bots are minis and they take quite a few turns in order to shrink codesize... Anyway, here's a translation of how iiley does it. (From comments in the code, credits should go to David Alves and Dummy here, but I'm not sure if they mainly contributed to the obfuscation, eh ... shrinkage ... or the algorithm as such).

void moveWithBackAsFront(double distance, double bearing) { double angle = Utils.normalRelativeAngle(bearing - getHeadingRadians()); double turnAngle = Math.atan(Math.tan(angle)); setTurnRightRadians(turnAngle); int direction = angle == turnAngle ? 1 : -1; setAhead(distance * direction); }You just pass the distance you want to travel and the bearing (in radians) to this function and it will sort out the shortest way to turn and what direction (forwards or backwards) to drive. The "atan(tan(angle))" stuff there does a sort of lossy normalization of any angle to the "-PI/2 -> +PI/2" space. It works much better than in my old goTo() functions. So here is the quite codesize-small goTo() of the development version of Tityus:

void goTo(Point2D destination) { double angle = Utils.normalRelativeAngle(absoluteBearing(robotLocation, destination) - getHeadingRadians()); double turnAngle = Math.atan(Math.tan(angle)); setTurnRightRadians(turnAngle); setAhead(robotLocation.distance(destination) * (angle == turnAngle ? 1 : -1)); }-- PEZ