An RPM-monitoring AI

[apanx]

Corollary: the 1/30 second limit also means that apanx's FBS.py uses an unnecessarily low tick interval.  It should be able to be increased from 0.001 to 0.0333 with no loss in performance, thus decreasing lag.

Short version: There is no 1/30th second limit for the game.

Long version: While the getTimeElapsed() only have a resolution of about 1/30th second. The game tries to execute code as fast as the specified tickInterval. When tickInterval is set too low, stuttering occurs as there are not enough processing resources to excecute all instructions fast enough to finish them before the tickInterval is over in the real world. In order to get a higher limit for the RPM measurement, you would have to write your own time measurement code as the resolution of getTimeElapsed() is not enough. Something like the example below.

Code: [Select]

        #Measure RPM
        if (self.GetMotorAngle(self.motorID) > math.pi/3 or self.GetMotorAngle(self.motorID) < 0) and self.measuring == 0:
              self.revolution += self.tickInterval
            self.measuring = 1
         
        if self.measuring == 1:
            self.revolution += self.tickInterval
       
        if 0 < self.GetMotorAngle(self.motorID) < math.pi/3 and self.measuring == 1:
            self.RPM = 50 / self.revolution
            self.revolution = 0
            if self.display != 0:
                self.RPMhist.append(self.RPM)
                if self.RPM > self.max_RPM:
                    self.max_RPM = self.RPM
            self.measuring = 0


[Somebody]

apanx :D

[Serge]

Code: [Select]

self.revolution += plus.AI.__getattr__tickInterval__(self)

Why would you do such a horrible thing? Provided self is actually a plus.AI instance:

Code: [Select]

self.revolution += self.tickInterval

[Badnik96]

apanx :D

[Clickbeetle]

*downloads*

I'm going to try and implement a RPM-measuring thing in Omni.py

Edit: lol it already is in NAR AI :P

SpinupOmni2 already has all the capabilities of Omni.  Adding RPM measurement to Omni would just be basically reinventing the wheel. :P


@apanx: Awesome!  Why didn't I think of doing that?  Such a simple solution...


Now maybe I can make the RPM calculator more accurate.


On a side note, although the 1/30 second cap seems not to apply to apanx's FBS.py, a tick interval of 1/30 second does seem to work just as well as 1/1000.  However, just in case, I implemented some code into my reduced-lag version that lets you set the tick interval in Bindings.  Just add 'Ticks':x to the bot's AI, where x is how much to divide the default tick interval.  So 'Ticks':2 halves the tick interval to 1/16 second, and 'Ticks':3.75 makes it 1/30 second.

[apanx]

Code: [Select]

self.revolution += plus.AI.__getattr__tickInterval__(self)

Why would you do such a horrible thing? Provided self is actually a plus.AI instance:

Code: [Select]

self.revolution += self.tickInterval

Nice, that works too, I figure this is a more elegant way to do this. Used the old code because the tickInterval attribute did not show up when doing a dir() on plus.AI.

[Serge]

Used the old code because the tickInterval attribute did not show up when doing a dir() on plus.AI.

Protip: do someObject.__dict__ next time :P.

[GroudonRobotWars]

Would this work for Hypno-Disc?

[Clickbeetle]

It will work for any spinner.  You only need to know the ID of the spin motor.

[Clickbeetle]

So, I've tried to improve the RPM calculator.  And it still seems to have a resolution of only 1/30 second.  I've tried this:

Code: [Select]


        #Measure RPM
        if (self.GetMotorAngle(self.motorID) > math.pi/3 or self.GetMotorAngle(self.motorID) < 0) and self.measuring == 0:
            self.revolution = 0
            self.measuring = 1
           
        if self.measuring == 1:
            self.revolution += self.tickInterval
           
        if 0 < self.GetMotorAngle(self.motorID) < math.pi/3 and self.measuring == 1:
            self.RPM = 50/self.revolution
            if self.display != 0:
                self.RPMhist.append(self.RPM)
                if self.RPM > self.max_RPM:
                    self.max_RPM = self.RPM
            self.measuring = 0


Basically what apanx posted.  But it has the same problem as the old code.  It only goes up to about 1500 RPM, and the accuracy decreases the faster the motor goes.


So then I tried totally rewriting it.  Rather than measure the number of ticks it takes to make a revolution, I measured how far the motor turns in one tick.  In theory, this should be much more precise than the way I had it before, especially at high speeds.

Code: [Select]


        #Measure RPM
        #looping timer for RPM calculation
        self.measuring += 1
        if self.measuring > 1:
            self.measuring = 0
           
        if self.measuring == 1:
            self.angle2 = self.GetMotorAngle(self.motorID)
            #correct for pi/-pi transition area
            if self.angle1 > 0 and self.angle2 < 0 and self.spindir == 1:
                self.angle2 += math.pi*2
            if self.angle1 < 0 and self.angle2 > 0 and self.spindir == 0:
                self.angle1 += math.pi*2
            self.RPM = (abs(self.angle2 - self.angle1)/(math.pi*2))*(60/self.tickInterval)
            if self.display != 0:
                self.RPMhist.append(self.RPM)
                if self.RPM > self.max_RPM:
                    self.max_RPM = self.RPM
           
        if self.measuring == 0:
            self.angle1 = self.GetMotorAngle(self.motorID)


But now, if the tick interval is any shorter than 1/30 second, the calculator frequently returns 0.0 RPM, meaning that it thinks angle1 and angle2 are exactly the same.  (Interestingly, it sometimes returns 0.0 RPM and also double of normal RPM when the tick interval is longer than 1/30 second, though much less frequently).  The only explanation I can think of for this is that RA2 only moves at a frame rate of 30 FPS, so if you try to measure the motor angle more than once in the same frame, you get the same angle and thus an RPM of 0.


So it appears there is no way to overcome the 1/30 second limit, unless I'm missing something here.  Still, this new RPM calculator should be more accurate for speeds closer to 1500 RPM, if I can only get it to work consistently.  As I said, it periodically returns 0 or double RPM's, and the RPM also seems dependent on the tick interval (it returns slightly higher RPM's with shorter tick intervals on the same bot).

[Madiaba]

This looks very interesting, CB.  I wish I could dabble here, but my fast comp is still in boxes...somewhere.  But for now I was thinking of a few more possible uses of this code:
-Rev limiter (use?)
-Rev reducer (in case of loss of weapon/stability)
-Motor 'stall' checker (if stall, then have bot disengage, spin up and then re-engage enemy)
-Rev 'failure' checker (if 'chronically' not able to get weapon motor up to certain attack-parameter rpm, then change tactic [i.e. to 'Ram'])
 
 

[Clickbeetle]

-Rev reducer (in case of loss of weapon/stability)

Great idea!  I already have a stall checker, but I didn't think of this.


Oh wait... that would actually be possible to do without the RPM calculator.  Just use an analog and tell it to input at half power when it loses weapons or something.  Still a good idea though.

[Madiaba]

-Rev reducer (in case of loss of weapon/stability)

Great idea!  I already have a stall checker, but I didn't think of this.


Oh wait... that would actually be possible to do without the RPM calculator.  Just use an analog and tell it to input at half power when it loses weapons or something.  Still a good idea though.

Ok, but reducing motor input to 50% doesn't guarantee it's even turning, when this coding would check and could ensure that factor.
 
This is one thing I really like about this coding- you know what the motor is 'actually' doing. It could be set like a 'governor' on a Briggs and Stratton small motor, that adds or removes throttle in an effort to both maintain rotation, and at a certain rate.
 
*Finds self plowing through boxes...*
 
 
 
BTW: I'm tempted to start a "Python" thread where the code could be put in one place for Tutelage and Reference.  Maybe a whole board...  I think Trov wouldn't mind Moderating it...
 
 
 
 
 

[Serge]

To get a higher resolution time delta:

http://docs.python.org/library/time.html#time.clock

"The resolution is typically better than one microsecond."

[Clickbeetle]

To get a higher resolution time delta:

http://docs.python.org/library/time.html#time.clock

"The resolution is typically better than one microsecond."

But if the issue is the 30FPS frame rate of the game (as I suspect), then a more accurate clock won't help...


But I will try this.  Maybe I'm wrong and it will work.

[Gigafrost]

I too agree, this code is pretty revolutionary. I can see this being used in the following ways:

• If bot with implemented code loses more than half of its weapons, slow down RPM in order to save battery life.
• If bot with implemented code loses more than half of its weapons, slow down RPM in order to prevent it from spinning offbalance.

I think, if possible, that this could be applied to other bot types as well.

• If flipper loses all "weapons" on its motors used for flipping, ignore trying to flip when enemy touches its smartzone and resort to trying to pin. Saving battery.
• If popup loses the "flipping components", ignore those motors and only use the weapons. Vise versa for the "weapon components".

Though I do believe that the later might not be possible atm.

[Naryar]

It would be cool with a self-right function, e.g. spin weapon in a restricted way when bot is upside down in order to self-right.

[Madiaba]

I too agree, this code is pretty revolutionary. I can see this being used in the following ways:

   

• If bot with implemented code loses more than half of its weapons, slow down RPM in order to save battery life.
• If bot with implemented code loses more than half of its weapons, slow down RPM in order to prevent it from spinning offbalance.

I think, if possible, that this could be applied to other bot types as well.

   

• If flipper loses all "weapons" on its motors used for flipping, ignore trying to flip when enemy touches its smartzone and resort to trying to pin. Saving battery.
• If popup loses the "flipping components", ignore those motors and only use the weapons. Vise versa for the "weapon components".

Though I do believe that the later might not be possible atm.

All of these are code-able, Gig.

[Gigafrost]

I figured so. That also reminds me, has anyone come up with an "Avoid" tactic? Like:

When a bot gets a high number of points, or when a bot has no more weapons, switch from attack to defence. Dodging engagement with the opponent.

I think it would be kind of cool to see. But it has to be possible since there is already an Engage tactic. Theoretically speaking.

[Resetti's Replicas]

How do I find the motor ID number?  The motor in question is a Perm-80 EL