Angular Momentum Dilemma

[EricL]

Bots can possess angular momentum I.e. spinning inertia that is not necessarily a consequence of the bot's own actions but due rather to external torque forces acting upon the bot.  The primary source of this (today) is torque due to external forces acting upon fixed and hardened ties, forces such as the bot on the other end of the tie moving or impacting something, or drag on the tied bot or the tie itself.  All of these result in torque today. It's important to realize that having to deal with angular momentum is an unavoidable consequence of allowing ties to have fixed angles.

The surface of a bot is also presumedly somewhat deformable and not frictionless.  I say deformable because the cyclic nature of the phsycis simualtion allows for bots to interpenetrate to some degree even when the coeffecient of elasticity is maxed.

Off center bot-bot collisions, bot-shape collisions, collisions with the edges of the field and so on should also result in torque being applied to a bot and result in rotational movement.  Since bots have mass, this means angular momentum and inertia.  That the code doesn't do this today is a shortcoming of the physics simulation.  It should.  It will not be too hard to add.  

Even without the collision code, it is possible today for bots without ties to possess and maintain angular momentum.  Bots have mass.  When a tie breaks, the bots keep any angular momentum they had when tied, as they should.

But since there is no code to deal with roational momentum due to collisions or to reduce this rotation momentum as a fuction of surface or fluid friction, bots today that have some angular momentum will keep it forever until they get tied again.  To address this, I've added some fricitonal degredation for rotational inertia for 2.42.9, but it will need tweaking.   We will also really need to add collision-based rotational momentum to make this whole thing work well.

But the delimma I refer to is in regard to the way .aimsx and .aimdx behave.   They do not take into account a bot's mass and rotational inertia.  They accelerate and decelerate the bot instantly, in a single cycle, turning it a specified amount and then stopping it again without regard to mass or more preciesly, without regard to rotational momentum and inertia.

What should the result be if a bot that is already spinning clockwise due to roational inertia stores a value into one of the .aim sysvars?  Should all the rotational momentum just go away or should the bot keep it?  Having it just disappear isn't realistic.  Keeping it has results bots don't expect - they keep turning....  What if the bot is spinning in the same direction as it wants to turn only it's spinning at a rate faster than the turn the bot requested?  Whoa.

Bascially, the way .aimsx and .aimdx work today is incompatable with realistic physcis.  They should be  torque impulse forces that take into consideration bot mass and angular inertia, not absolute degree operations.   Turning a more massive bot should take more nrg and result in more angular inertia.  Storing a low value into .aimsx should mean "apply a low amount of counter-clockwise torque".  If the bot is stationary, this will start it turning slowly counterclockwise and keep it turning slowly counter-clockwise until friction or an impact or a hardened tie's torque or a .aimdx operation stop it.  If the bot has some clockwise rotational momentum, the torque should serve to slow the rotation.  If it has counter-clockwise momentum, this should speed it up some.  You see where I'm going with this?

I'm interested in whether people see a way out of this without changing the behaviour of .aimsx and .aimdx...

[Numsgil]

I had the same issue a while ago.  Basically what I decided is that .aimsx, .aimdx, and .setaim are requests for angular velocity instead of impulses.

If a bot is currently spinning at a rate w, and .aimsx is set to something other than w, the resulting change in angular velocity is requested to be (w - aimsx).  You can then feed this into angular equations to find the resulting nrg cost needed to arrive at this angular velocty, and charge the bot that amount.

Here's the C++ code, should give you an idea of what I did:

Code: [Select]

void Robot::UpdateAim()
{
    float W, NewW, Aim, DeltaW;
    float Force;
    float I;
    float Cost;

    if ((*this)[SetAim] == (*this)[Aimsys])
    {
        Aim = this->aim * 200.0f + (*this)[aimleft] - (*this)[aimright];
    }
    else
    {
        Aim = (*this)[SetAim];
    }

    Aim /= 200.0f;
    
    I = this->mass * this->radius * this->radius * 2.0f/5.0f;
    W = AngularMomentum / I; //in bot angles
    
    NewW = Aim - this->aim;

    DeltaW = (NewW - W);
    DeltaW = (float)fmod(DeltaW, 2.0f * PI);
    Force = I * (float)fabs(DeltaW) / this->radius;
    Cost = Force * SimOpts.Costs[TURNCOST];
    
    Aim = (float)fmod(Aim, 2.0f * PI);
    
    if(Aim < 0)
        Aim += 2.0f * PI;

    this->aim = Aim;
    this->AngularMomentum = NewW * I;

    //I'm not sure if costs are being done right
    //for cases when it going in the oposite direction
    //would be cheaper
    if(Cost > 0)
        this->ChargeNRG(Cost);
    
    aimvector.set(cosf(aim), sinf(aim));

    (*this)[aimright] = 0;
    (*this)[aimleft] = 0;
    (*this)[Aimsys] = iceil(this->aim * 200);
    (*this)[SetAim] = iceil((*this)[Aimsys]);
}

[EricL]

We have reached the same conclusion.  I'm not sure people are ready for me to do this in the VB version though as it is a profound change in bot movement.

It will be weeks before I get to this anyway, so there is time...

[Jez]

It's an interesting idea.

I am all for keeping the physics of the bots fairly realistic, don't seem to remember that bots have a way to detect their spinning inertia and therefore calculate the associated costs with making the turn they want. If I spin round in a circle and want to stop at a particular point then, as long as I am not to dizzy, I know how much counter momentum to apply and I am a little worried if you apply costs without a way to detect the cost or compenstation that bots need they would become hopelessly inaccurate.

Then again I don't always agree with the way they can be, sometimes, so digitally accurate.

In essence I am all for this plan TBH.

[Numsgil]

It's an interesting idea.

I am all for keeping the physics of the bots fairly realistic, don't seem to remember that bots have a way to detect their spinning inertia and therefore calculate the associated costs with making the turn they want. If I spin round in a circle and want to stop at a particular point then, as long as I am not to dizzy, I know how much counter momentum to apply and I am a little worried if you apply costs without a way to detect the cost or compenstation that bots need they would become hopelessly inaccurate.

I agree full heartedly.  But it seems the best of several bad solutions.  It has the benefit that it's backwards compatible, spinning is basically free (as it is now), etc.  But as you say bots really don't know how much they're going to be charged for their turning.  That's a potentially dangerous black box.

On the plus side, setting Turning Cost to 0 basically gives you the current rules with the benefit that you're calculating and maintaining angular momentum.

[Testlund]

I agree too, if it doesn't slow down the program.