#201 setMaxVelocity(lower than current) + reverse direction bug

[Positive]

Try a robot with the following code:

setAhead(Double.POSITIVE_INFINITY);
setMaxVelocity(1.0);
execute();
// robot has a positive velocity of 1.0
setMaxVelocity(0.5);
setAhead(Double.NEGATIVE_INFINITY);
execute();
// robot should have a negative velocity of -0.5

However, this code does not work. What happens is the velocity of the robot first becomes 0.5, then becomes -0.5.
This problem seems to be limited only to when your current velocity is higher than the max velocity set.

[Nat Pavasant]

I'm not sure, but I think this is fixed by r2983 that committed into SVN repository on Thu May 14 21:17:13 2009 UTC by Flemming

[Nobody/Anonymous]

This bug report is also valid for 1.7.1.2 Beta for the reverse direction part, where the max velocity is set. With the first part, the velocity is now correctly 1.0, but the second part end at -0.75. It is quite easy to fix, and I am working on that currently + a test unit that can test the reverse direction + setMaxVelocity().

[Flemming N. Larsen]

This bug has now been fixed. A test unit is on it's way.

[Flemming N. Larsen]

Fixed in Robocode 1.7.1.2. Please verify that this bug has been fixed properly.

[Nobody/Anonymous]

I've tested the code in the new version, and the specific code above has been fixed. Thank you. :-) There seems to be a new bug instead causing problems though; Try "setAhead(1.0); execute(); setBack(1.0); execute(); " Gives a velocity of 1.0, then -0.75, then -0.25, then 0. In the previous version it would go from 1.0 to -1.0.

[Flemming N. Larsen]

I have tried to reproduce your scenario using this run method:

public void run() {
for (int i = 0; i < 2; i++) {
setAhead(1.0);
execute();

  out.println(getVelocity());

  setBack(1.0);
  execute();

  out.println(getVelocity());
}

}

The result (in the robot console) is this:

1.0
-0.75
0.671875
-0.66668701171875

This is correct according to the new and corrected movement in Robocode. In previous versions, Robocode could go from 1.0 to -1.0, which is wrong. A robot can only decelerate 2 pixel per turn, and accelerate 1 pixel per turn. Going from 1.0 to -1.0 is a special case, where we cannot just use the deceleration or accelration constants separately. These must be combined. We must split it into two parts taking the time into account:

a) Decelerating from 1.0 down to 0.0 (half a turn)
b) Accelerating from 0.0 to X, which become -0.75 (half a turn)

The formula is like this:

-(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime)

decelTime = Math.abs(velocity) / Rules.DECELERATION
accelTime = (1 - decelTime)

So when our initial velocity is 1.0...

decelTime = 1.0 / 2.0 = 0.5
accelTime = (1 - 0.5) = 0.5

Hence we get:

-(2 * 0.5 * 0.5 + 1 * 0.5 * 0.5) = -0.75 for the next speed

---

I should like to see the code you used for getting the "1.0, then -0.75, then -0.25, then 0" when trying "setAhead(1.0); execute(); setBack(1.0); execute(); ".

[Positive]

Okay, with your formula it makes sense. In the comment I placed I forgot to add another "execute()". So, that's not a bug. :)

I couldn't find any discussion about velocity rules change before my previous post. Now I'm thinking about it, won't this affect the functionality of allmost all robots (concerning for example, the self-move predictions)? What exactly is the gain of adding this complexity (were bots abusing it?)

Thankyou for your time. :)

[Flemming N. Larsen]

There is lot's of discussions about the velocity / updateMovement. The bugreport was raised here:

"Bug [2077512] - Bug in RobotPeer.updateMovement":
http://sourceforge.net/tracker/index.php?func=detail&aid=2077512&group_id=37202&atid=419486

This bug report was created due to an discussion on the old RoboWiki under GamePhysics/Bootspeed: http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed

And lot's of discussions have been going on in the Robocode Developers group as mails etc.

The gain is first and foremost correctness so it is easier for a robot to estimate the velocity of a robot. In addition, in some situations the movement took one turn more than it had too, which is also a bug. In fact, we have not been adding complexity of the movement. Instead it was simplified (easier to understand and maintain) and made correct. The code is lesser lines big, and not so messy.

[Positive]

Okay, got it. :)

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).