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...

https://www.youtube.com/watch?v=eIMmz8DrFjo

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.


    Regards
    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:-

      http://i.imgur.com/MnOPImN.jpg

      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

        Wolf-Dieter

        Edit:
        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
                    Author: firechief | Created: 2017-07-23 13:56:44
                    Subject: Re: A behavioural bug in Klin
                    If you'd like to discuss robot ideas, and as we're both basing our bots on K1999 it might make sense, maybe email me - novocas7rian (at) gmail.com - rather than clutter up the forum ;)

                    Forza is indeed heavily setup dependent, though I think most competitors know by now not to use any wing angle at all on this track. Because it relies so much on outright speed, any damage will have a huge effect on lapspeed at Forza due to the increase in drag, more than any other track. I think that may affect the chaotic nature of its results.
                    Last Edited: 2017-07-23 13:56:44 by firechief
                      Author: phi | Created: 2017-07-23 17:33:00
                      Subject: Re: A behavioural bug in Klin
                      «clutter up the forum»? That sounds bad to me. Maybe I do not understand the expression very well, but I can't talk about the idea of my robot if this helps to understand the problem in this thread? I do not intend to discuss ideas about robots, and I do not think I'm doing this. If A) offends you, I apologize, but what I said is not meant to start a discussion of ideas: reports only and above all to my impression about Klin.
                      Last Edited: 2017-07-23 17:33:00 by phi
                        Author: firechief | Created: 2017-07-24 03:03:16
                        Subject: Re: A behavioural bug in Klin
                        Sorry I didn't mean anything bad by it & I'm sure nobody's in the least offended by your posts here - by all means please keep posting!
                        Last Edited: 2017-07-24 03:03:16 by firechief
                  Author: wdbee | Created: 2017-07-23 16:21:51
                  Subject: Re: A behavioural bug in Klin
                  > 20m should be fine
                  Sorry, but just to define such a distance will not work. As I wrote, you have to be prepared until the overlapper is with you. Try USR without a setup driving slow and make your robot faster, you will see USR is never prepared to let you pass ;)
                  At opposite the mouse based robots work well, you will love to overlap them.

                  The distance to decide depends on your ability to go to the side. Driving at side means you have to reduce the speed. So you need some time depending on the speed difference between racingline and side. The time you have depends on the speed difference between your car and the overlapper.

                  So the first step would be to increase the distance to check for overlappers. Later you will be able to implement better methods.

                  Looking at the side you see the overlapper 20 or more meters back is one thing, but that does not say anything at curvy sections of a track ;)

                  The klin drives much too good to go home and sleep!
                  Last Edited: 2017-07-23 16:21:51 by wdbee
                    Author: phi | Created: 2017-07-23 17:57:29
                    Subject: Re: A behavioural bug in Klin
                    I said:

                    «... 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.

                    Then, Andrew said:

                    20m should be fine

                    Then, I said:

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

                    And now I don't know :) I only know that he is not sleepy for now.
                    Last Edited: 2017-07-23 17:57:29 by phi
                      Author: wdbee | Created: 2017-07-24 07:54:26
                      Subject: Re: A behavioural bug in Klin
                      And Andrew said, klin should go faster to a side.
                      Well I assume this will be more difficult, so I would start earlier to keep things simple.

                      What I want to make clear is, that there is not a fixed distance when to start to move to the side. It depends on the situation. So start checking early and decide when to move to the side depending on the speed difference. You will know how much time you will need to slow down and be prepared to drive stable to the side without spin offs by testing ;). From distance and speed difference you can calculate the time until the overlapper is with you. This gives you the signal when to start. To not miss the signal, you have to watch for overlappers early.

                      Hope this helps

                      Wolf-Dieter
                      Last Edited: 2017-07-24 07:54:26 by wdbee
                        Author: phi | Created: 2017-07-24 11:39:17
                        Subject: Re: A behavioural bug in Klin
                        Yes, you make it clear, Wolf-Dieter, thanks. I think your paragraph above summarizes your point of view very well:

                        > The distance to decide depends on your ability to go to the side. Driving at side means you have to reduce the speed. So you need some time depending on the speed difference between racingline and side. The time you have depends on the speed difference between your car and the overlapper. [2017-7-23]

                        For now I'm concentrating on stabilizing the procedure at 20m, given that I got to this distance by tests: it's, for me, the one that has met the best conditions so far, taking into account the range of characteristics of the atual tracks. In accordance with your citation, I'm finding the «ability to go to the side». I believe that this is the first thing to do before anything else, and that this is done in the best way keeping the distance unchanged.
                        Last Edited: 2017-07-24 11:39:17 by phi
                          Author: wdbee | Created: 2017-09-08 15:03:01
                          Subject: Re: A behavioural bug in Klin
                          Looking to the klin code (path.cpp):
                          ...
                          #if MNG_OVERLAPPERS_IN_LEFTRIGHT
                          ...
                          if(backo.car->_pos < car->_pos)
                          ...
                          the explanation for the behavioural bug seems to be, that the detection stops when
                          backo.car->_pos becomes > car->_pos. The overlapper is still at side! There is no lefto.car or righto.car used, but backo.car. But is backo still defined if backo.car->_pos becomes > car->_pos? As result the klin often steers to the side where the overlapper is still passing.

                          Another issue: The distances between cars are taken from the position and the dimensions only without taking into account, that the cars are not aligned perfectly. Yawing cars need additional space to avoid collisions.

                          Cheers

                          Wolf-Dieter
                          Last Edited: 2017-09-08 15:03:01 by wdbee
                            Author: phi | Created: 2017-09-10 01:09:26
                            Subject: Re: A behavioural bug in Klin
                            Hi, Wolf-Dieter

                            The code is somewhat fragmented and unsatisfactory at this level.

                            The rear and side cars are treated in the MaxSteer(), and when the overlapper is on the side it is treated like all side cars with the acceleration reduction difference. Klin only stops track overlappers when they are ahead of him.

                            Klin knows reasonably well when an opponent needs space on one side, and gives him that space under the condition of being minimal (taking into account the physical and security space). It is possible to change the dimension of space and the smoothness in approaching its minimum, but in this moment it is impossible to avoid or obstruct this approximation: this one is an integral part of Klin's "personality". In other words, Klin will always approach the car in the side, whenever that is the direction of the ideal direction.

                            If you whant, you can play in MaxSteer() with MIN_DIST (side distance) (line 1370) and/or the parameters of AngleDisplacementMiddleCar() (opening the door to overlapper) (lines 1460 and 1462). Here and in the maneuvers I still have to do, and the system is not yet stable and satisfactory even though I've been more satisfied with it since the beginning of this thread.

                            ---------------------

                            Another issue: yes.


                            Regards
                            Last Edited: 2017-09-10 01:09:26 by phi