The TORCS Racing Board
Username: Password: Remember Me?
Lost Password Register
Author: firechief | Created: 2017-07-17 05:21:46
Subject: A behavioural bug in Klin
I finally had a bit of time to run the race with the corrected Klin, and quickly noticed an issue that only seemed to occur on the main straight...

Throughout the race, several cars were bumped into the pit area and given stop & go penalties, and each time Klin was involved. This is the only real behavioural bug I've seen with Klin. As many new robots have all kinds of erratic handling in traffic, Paulo you've done an excellent job & I hope you can track this down :)
Last Edited: 2017-07-17 05:21:46 by firechief
    Author: phi | Created: 2017-07-17 20:31:37
    Subject: Re: A behavioural bug in Klin
    Thanks Andrew

    Nice and clear presentation, for a ugly and less clear bug.

    This situation is not easy to capture in my system, but I managed to attract it: however, not with these effects. In your great video:

    A) Klin goes brutally to the K1999 line: perhaps this intensity has caused Klin to exceed its limits and has invaded the space of the USR -- I hope this is not the problem, as I am trying to solve this problem without being able to reach a satisfactory solution.

    B) In path.cpp:2495 there are a 'break' that limits Klin to one opponent behind. It's a remote hypothesis (I do not see that well in the code), but maybe Klin is aware of one of the Axiom and not the USR... Anyway, this 'break' is completely out of context except for tests, and is for elimination.

    I will continue to be attentive to the subject, although in my tests Klin improves with the elimination of this 'break'. If you (or another racer) want and have time to test until the next race, please, do:

    C) eliminate 'break'; and

    D) in path.cpp:2484:

    if(fabs(sidedist) > car->_dimension_y)
    accel = AccelToLetCarPass(accel);

    In this way we may be able to prevent this problem from happening again.

    Last Edited: 2017-07-17 20:31:37 by phi
      Author: firechief | Created: 2017-07-18 02:39:08
      Subject: Re: A behavioural bug in Klin
      I don't think its the "brutality" of the move to the K1999 line that's the problem. Rather, it shouldn't be trying to move to the racing line at all, as it has another car alongside.

      I added the code changes, but didn't see a lot of difference in Klin's behaviour. If anything its even more stubborn about holding the racing line when other cars are beside it - and it wasn't long before it knocked another overlapper into the pits:-

      The change to the acceleration didn't improve things, as it increased the risk involved when overlappers attempted a pass (due to Klin travelling faster) or ended up with cars stuck behind Klin for long distances while awaiting a clear opportunity. Because Klin was travelling faster, it wasn't reacting as quickly to the presence of an overtaker beside it & was more likely to cause damage.
      Last Edited: 2017-07-18 09:28:21 by firechief
      Author: firechief | Created: 2017-07-18 07:44:14
      Subject: Re: A behavioural bug in Klin
      By the way, USR is also based on K1999 - I know how difficult it was for me to find a solution to the car's driving off the racing line. I'm very interested to see what you come up with, as you've approached it in quite a different way to the method I used.
      Last Edited: 2017-07-18 07:44:14 by firechief
      Author: phi | Created: 2017-07-18 12:01:15
      Subject: Re: A behavioural bug in Klin
      I think the best solution is multi-line method, and you know better than I, Andrew. Not a day goes by without thinking of studying and applying this solution, so much that it solves numerous problems and offers great possibilities of development. But then I realize that this is not part of Klin's philosophy (at least in its current model): there must be only one line, and at this moment I can not conceive another way of thinking without Klin being no longer Klin.

      I'm going to work this out the best I can, and let's see what comes out.
      Last Edited: 2017-07-18 12:01:15 by phi
        Author: wdbee | Created: 2017-07-18 19:50:24
        Subject: Re: A behavioural bug in Klin
        I'm not sure that I understand your one line approach correctly. Your robot should be able to overtake. This should be triggered by the relative position and speed difference of one or more opponents relative to your car. And let pass a faster opponent isn't it just the same with just a different sign of the differences?

        To be honest, there are some other teams that do not manage two opponents overtaking in line without steering into the second just when the first did pass ;)

        In races you do not see it often, because they are leading teams, but at test races driving without an adjusted setup it looks very similar to the first video.

        Often the overlapped cars start their action (avoiding) when the overlapper is at side. AFAICS that is much to late, they should be out of the way when the faster opponent reaches them. Keep in mind, we are talking about overlapping, not overtaking. This means there is no room for tricks like change the side just in front of the following car to make it brake.

        In the rules there is no definition which side to use. But we are driving similar cars. The racing line is the fastest way to drive. So a simple good decision should be to go away from the racing line but once a side is reached to stay there.

        Hope this helps


        And there is another trap we found some years ago: To decide about an opponent being lapper or overtaker we used the laps. But driving over the start line this does not work for a short moment and caused similar accidents. The car in front switched from being lapped mode to don't let it pass mode and steered into the overlapping car.
        Last Edited: 2017-07-18 20:35:40 by wdbee
          Author: firechief | Created: 2017-07-19 04:41:41
          Subject: Re: A behavioural bug in Klin
          > So a simple good decision should be to go away from the racing line but once a side is reached to stay there.

          Agreed, that's the perfect action to take. I'd also suggest capping the accelerator at something like 70% to make sure the overlapper gets past without delay, as it slows both cars down if it turns into a wheel-to-wheel battle - there's nothing to gain in that situation but the potential for damage.
          Last Edited: 2017-07-19 04:41:41 by firechief
          Author: phi | Created: 2017-07-19 07:49:35
          Subject: Re: A behavioural bug in Klin
          > So a simple good decision should be to go away from the racing line but once a side is reached to stay there.

          This is not so simple. Go where? Do you forget that Klin is hit by several cars at the same time, and not infrequently at least two pass through him at the same time? In one last test, two Mouse overlapped Klin simultaneously in the middle of a left turn, one on the left, another on the right; considering that Klin did not touch one of them, this is not bad at all. The position where to go and where to stay has to be a commitment made and carried out at the time and according to the situation. I am wrong?

          PS: Klin already reduces its accelerator to 50%.
          Last Edited: 2017-07-19 07:49:35 by phi
            Author: firechief | Created: 2017-07-19 09:10:12
            Subject: Re: A behavioural bug in Klin
            Yes, Klin's accelerator usage for overtakers is fine.

            The problem of "where to go" is perhaps not quite that difficult. I'd suggest looking at it this way:-

            1. Are there cars alongside? If so, handle that situation & don't worry at all about cars behind.

            2. No cars alongside, but overlappers behind...
            a) Choose the closest overlapper, ignore any others.
            b) If this overlapper is to the left of the car, move to the right. Otherwise move left.

            That should pretty much cover any circumstance. If there's more than one overlapper, the one further behind is likely to see klin move to a side in order to let the first one through, and its up to the 2nd overlapper to see this and look to overtake on the side klin's leaving open.

            If two cars get alongside, one left & one right, klin should hold the middle line as you described - but then again that's a general question of side avoidance (it can happen while overtaking slower cars too).
            Last Edited: 2017-07-19 09:10:12 by firechief
            Author: wdbee | Created: 2017-07-22 11:29:21
            Subject: Re: A behavioural bug in Klin
            The reason to be overlapped on both sides is that you did not decide early enough to move to the side ;), which is very common to the robots.

            As Andrew told, first priority is having cars at side and handle it.
            Next should be to check for overlappers (But most robots do it with last priority)

            In opposite to the rules saying look at berniw or bt for getting a good behaviour both use a timer to block overlappers for 5 seconds resulting in just the situation to not be prepared for being overlapped in a save way (for both sides) and is in conflict with the rule saying that blocking is not allowed.

            It is up to you to keep the things simple for your robot, just start early enough and stay on the side until all overlappers have passed.

            Using 70% throttle will result in issues, because some of the cars do accelerate better then others and this will increase the time driving side by side.
            Last Edited: 2017-07-22 11:29:21 by wdbee
              Author: phi | Created: 2017-07-22 20:37:44
              Subject: Re: A behavioural bug in Klin
              A) When an overlapper show itself on one side, Klin opens that side. I think the problem is not the idea that Klin develops, but rather its implementation (to the level of verification and management of the cars behind). Formally, Klin check the side cars, then the front cars, and finally the rear cars; like you wrote. The order 'front ==> back' is not important because the Klin method has set the maximum left/right margins where it can go, and along the process corrects those margins taking into account security restrictions; at the end of all verifications, he has a path with "infinite" possibilities to go by -- assumption: any path serves, provided it lies within these margins --, and he chooses the direction (steer) closest to the ideal (K1999). Everything is fine, as far as I'm concerned, except for the margin correction angles when checking the cars behind, and, to a certain extent, some aspects of the design and structure of this block. Anyway, even with all this yet to be resolved, Klin reveals itself a reasonably car (at least In my tests): the overlappers doesn't lose too much time, and, in my opinion, Klin is accordingly to the rules; it's also not a chaotic car, hitting on everything and everyone, at least in my opinion.

              B) «... start early enough ...» So simple and I have not experimented in this respect... Klin checks and manages below 20 m distance; you may be right, and I should increase that value. At the moment my code is a bit chaotic with other tests, but as soon as I'm in condition I hope to test new values.

              C) The best and most perfect procedure for a slow car like Klin is to go home and sleep :) The rule has Berniw as a reference, but it allows flexibility and only says not to block; furthermore, it says that nothing is perfect (Berniw robot isn't perfect), which, as far as I'm concerned, is correct and applied to all robots. A gray cloud hangs over it. If such a rule were something like "drive as fast as you can, but car X will have to be able to overtake you on the Y track after Z seconds" then, perhaps (I think), the "gray zone" clear a little bit because there are a test that we can do easily (I think) and with some degree of concretude. But there is no such rule, and at this point the rule seems to me more about an idea than simply about blocking or not.

              D) A note about possible disturbances (or random results, if we like) that occur in a given race:

              In my curiosity about Glicko, I applied and calculated this scale to all races since the first in 2005. The Glicko is calculated for each race, so, we have an order of strength previously established before each race - the Glicko calculated in the previous race: will the race results correlate with that order? that is, the results are in accordance with the strength of the drivers? To answer that questions I apply 'Spearman Rank-Order Correlation' (ignoring the tied observations), and, if all my calculations are fine and there are no bugs in the program, the results in 'E-Track 6', like the other races before, are 99% according to Glicko order -- as a curiosity, all races since Wheel 1 (2015) have this correlation result, with the exception of Dirt 2 (2016): Dirt 2 challenges the order of the mighty, it seems...
              Last Edited: 2017-07-22 20:37:44 by phi
                Author: firechief | Created: 2017-07-23 05:08:54
                Subject: Re: A behavioural bug in Klin
                A) In theory that sounds excellent, I had the idea to implement something like that for USR this year instead of using 3 paths, but I simply haven't found the time yet. Klin is indeed not chaotic - the only exception being the bug that prompted me to start this thread.

                B) I think Klin's detecting overlappers ok, going by its accelerator reduction. 20m should be fine, I wouldn't look to extend it. I think though its a little slow to alter its racing line to open up a gap for the overlapper.

                C) As you said, its a gray rule, made more so by the reference to berniw and bt which have unfriendly behaviour as W-D described. In fact, berniw has another quirk - it always tries to open a gap for the overlapper on the inside line through a corner, so if the cars are navigating through some tight esses - the section immediately before the pit straight on e-track-6 for example - a berniw will switch back and forth from one side to the other with a high likelihood of either losing control or ramming the overlapper off the track.

                I don't think a rule such as "once the overlapper's within X distance it has to pass within Y seconds" is feasible, as overtaking involves two cars. The overlapped can do everything in its power to let the overlapper past, but the overlapper might be poor at overtaking and slow to seize the opportunity given to it - and that's not the fault of the overlapped car.

                D) Yes dirt-2 really throws the cat among the pigeons. Wait till you see the outcome of dirt-3, I expect similar chaos.
                Last Edited: 2017-07-23 05:08:54 by firechief
                  Author: phi | Created: 2017-07-23 12:41:34
                  Subject: Re: A behavioural bug in Klin
                  A) I'd like to see that. You have all the potential to make this a great car.

                  The freedom this allows, sometimes takes the car to spectacular maneuvers of overtaking, sometimes in "S" among the opponents and at high speeds. I think you'd like that, and your USR too (it's a powerful and energetic car, if I can say that).

                  It is as if it were a wild horse with a tendency, and we do not tell him where to go but where he can go (and he goes, sometimes to places where we did not suppose he was, revealing in a way a life of his own). We are not the commander, but the father; sometimes I get tired (conceptualization does not help), and I wonder if it would not be better to become the commander...

                  B) Perhaps by reducing the accelerator to 20m, but by managing the deviation angle at the longest distance?

                  If you open too much the angle, Klin does not move to open a gap; if you close too much the angle, Klin gets out of control. In addition to not having discovered the most efficient angular relationship for "going out of the way", the implementation is completely unstable to allow "staying there"; so, "going out of the way and staying there" is a big problem. I have done some revisions (very long to give here for you to test, if you wanted) that improve certain aspects and not others, but so far nothing that satisfies me; on the other hand, I have noticed that what works relatively well in one track, in another is completely inappropriate.

                  I know, you know, we all know: this question is very important, as Klin will be overlapped almost at every lap, and I do not want to ruin anything.

                  C) I was thinking more in the sense that the more experienced drivers choose a car X, a circuit Y and a time Z (or a distance Z, or these and/or other conditions), and every car submitted to the championship would have to satisfy this condition.

                  D) All dirty tracks have "chaotic" results. In a sense, is something that jumps right in the eye, and we do not need statistical tests to deduce this. But, what about Forza, with 3 "chaotic" results against 4 "normal" results? What happened in 'Forza 2015', for example? Is a track that depends greatly on setup and is therefore subject to wide variations?
                  Last Edited: 2017-07-23 12:41:34 by phi