torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

Hi Jim

Sensors, so do you use 1.3.1 with the competition patch? Which platfrom?

I checked the side right after the start with TORCS 1.3.4, car7-trb1, 
human player, everything seems to be fine.

Beware, car setups are not validated, so if you have a fancy car 
definition file this might let the simulation "explode" (once there is 
somewhere a NAN produced it propagates to whatever it "touches", the 
"things fall apart"), e.g. super strong damping on "fast" values causes 
a NaN somewhere when hitting a high curb on high speed IIRC (e.g. the 
curb of the last chicane before the start on e-track-1, high speed and 
high curb slope and strong damping results in an exorbitant force -> plonk).

There are usually additional compiler switches/pragmas to jump into the 
debugger on FPU exceptions, this way you might be able to catch it for 
investigation, see:
vs2008/10:
http://stackoverflow.com/questions/4454582/visual-studio-c-2008-2010-break-on-float-nan
gcc:
http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html
http://www-personal.umich.edu/~williams/archive/computation/fe-handling-example.c

If you found an actual but in TORCS please let me know:-)

Best regards

Bernhard

On 11/28/2012 03:50 AM, James Ihrig wrote:
> Hello,
>
> I am still running into program crashes once in awhile, but for a
> different reason this time. It seemed that my sensors were picking up
> bad values sometimes. (I use offset centerline etc. for some calculations.)
>
> My bot currently turns hard right sometimes straight into the wall at
> the beginning of the race. Since I am using a neural network this is
> expected for some runs. So I added this bit of code into my drive funciton:
>
> static void
> drive(int index, tCarElt* car, tSituation *situation)
> {
>      std::cout << "Positition = ("
>          << car->pub.DynGC.pos.x << ", "
>          << car->pub.DynGC.pos.y << ", "
>          << car->pub.DynGC.pos.z << ") " <<std::endl;
>      ...
> }
>
> The output is:
>
> ...
> Positition = (667.472, 1163.4, 3.84071)
> Positition = (667.472, 1163.4, 3.84074)
> Positition = (667.472, 1163.4, 3.84076)
> Positition = (667.472, 1163.4, 3.84079)
> Positition = (667.472, 1163.4, 3.84081)
> Positition = (667.472, 1163.4, 3.84083)
> Positition = (667.472, 1163.4, 3.84084)
> Positition = (667.472, 1163.4, 3.84086)
> Positition = (667.472, 1163.4, 3.84087)
> Positition = (667.472, 1163.4, 3.84088)
> Positition = (667.472, 1163.4, 3.84089)
> Positition = (667.472, 1163.4, 3.8409)
> Positition = (-nan, nan, -nan)
> /usr/local/bin/torcs: line 53:  7428 Segmentation fault      (core
> dumped) $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*
>
>
> Once the position is nan or -nan, my program crashes because these
> values are ultimately used to index an array that I store approximations
> of a sigmoid in. (I don't imagine most others would do something like
> this.) My solution will be to check for nan of course, but I thought I'd
> mention it here in case it is a bug with TORCS. Perhaps some bad
> geometry at the edge of the track? Perhaps it's just my code again, but
> I definitely do not attempt to update position directly in my code, only
> the gas, brake and steering commands.
>
> At the very least, someone might check the geometry at the above
> position and see if there is anything funky there just in case. (I have
> no idea how to check it myself.) This should be a rare case since my bot
> did 1270 runs before this happened. Subsequent loads of my 1271st
> network will cause it to crash at the same point every time. (I have a
> separate program generating the networks, so I have been able to load
> that network in via XML as a first run multiple times)
>
> Feel free to let me know if I'm completely of my rocker here!
>
> Jim
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
>
>
>
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel
>

Just realized I may have left out some information that may be important in
that last message:

The track is I am running is "Forza" under "Road Tracks".

The position my car was at was just past the start line somewhere at the
edge of one of the two buildings, (or between them) at the right hand side
of the track.

Jim


On Tue, Nov 27, 2012 at 9:50 PM, James Ihrig <je...@gm...> wrote:

> Hello,
>
> I am still running into program crashes once in awhile, but for a
> different reason this time. It seemed that my sensors were picking up bad
> values sometimes. (I use offset centerline etc. for some calculations.)
>
> My bot currently turns hard right sometimes straight into the wall at the
> beginning of the race. Since I am using a neural network this is expected
> for some runs. So I added this bit of code into my drive funciton:
>
> static void
> drive(int index, tCarElt* car, tSituation *situation)
> {
>     std::cout << "Positition = ("
>         << car->pub.DynGC.pos.x << ", "
>         << car->pub.DynGC.pos.y << ", "
>         << car->pub.DynGC.pos.z << ") " <<std::endl;
>     ...
> }
>
> The output is:
>
> ...
> Positition = (667.472, 1163.4, 3.84071)
> Positition = (667.472, 1163.4, 3.84074)
> Positition = (667.472, 1163.4, 3.84076)
> Positition = (667.472, 1163.4, 3.84079)
> Positition = (667.472, 1163.4, 3.84081)
> Positition = (667.472, 1163.4, 3.84083)
> Positition = (667.472, 1163.4, 3.84084)
> Positition = (667.472, 1163.4, 3.84086)
> Positition = (667.472, 1163.4, 3.84087)
> Positition = (667.472, 1163.4, 3.84088)
> Positition = (667.472, 1163.4, 3.84089)
> Positition = (667.472, 1163.4, 3.8409)
> Positition = (-nan, nan, -nan)
> /usr/local/bin/torcs: line 53:  7428 Segmentation fault      (core dumped)
> $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*
>
>
> Once the position is nan or -nan, my program crashes because these values
> are ultimately used to index an array that I store approximations of a
> sigmoid in. (I don't imagine most others would do something like this.) My
> solution will be to check for nan of course, but I thought I'd mention it
> here in case it is a bug with TORCS. Perhaps some bad geometry at the edge
> of the track? Perhaps it's just my code again, but I definitely do not
> attempt to update position directly in my code, only the gas, brake and
> steering commands.
>
> At the very least, someone might check the geometry at the above position
> and see if there is anything funky there just in case. (I have no idea how
> to check it myself.) This should be a rare case since my bot did 1270 runs
> before this happened. Subsequent loads of my 1271st network will cause it
> to crash at the same point every time. (I have a separate program
> generating the networks, so I have been able to load that network in via
> XML as a first run multiple times)
>
> Feel free to let me know if I'm completely of my rocker here!
>
> Jim
>

Hello,

I am still running into program crashes once in awhile, but for a different
reason this time. It seemed that my sensors were picking up bad values
sometimes. (I use offset centerline etc. for some calculations.)

My bot currently turns hard right sometimes straight into the wall at the
beginning of the race. Since I am using a neural network this is expected
for some runs. So I added this bit of code into my drive funciton:

static void
drive(int index, tCarElt* car, tSituation *situation)
{
    std::cout << "Positition = ("
        << car->pub.DynGC.pos.x << ", "
        << car->pub.DynGC.pos.y << ", "
        << car->pub.DynGC.pos.z << ") " <<std::endl;
    ...
}

The output is:

...
Positition = (667.472, 1163.4, 3.84071)
Positition = (667.472, 1163.4, 3.84074)
Positition = (667.472, 1163.4, 3.84076)
Positition = (667.472, 1163.4, 3.84079)
Positition = (667.472, 1163.4, 3.84081)
Positition = (667.472, 1163.4, 3.84083)
Positition = (667.472, 1163.4, 3.84084)
Positition = (667.472, 1163.4, 3.84086)
Positition = (667.472, 1163.4, 3.84087)
Positition = (667.472, 1163.4, 3.84088)
Positition = (667.472, 1163.4, 3.84089)
Positition = (667.472, 1163.4, 3.8409)
Positition = (-nan, nan, -nan)
/usr/local/bin/torcs: line 53:  7428 Segmentation fault      (core dumped)
$LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*


Once the position is nan or -nan, my program crashes because these values
are ultimately used to index an array that I store approximations of a
sigmoid in. (I don't imagine most others would do something like this.) My
solution will be to check for nan of course, but I thought I'd mention it
here in case it is a bug with TORCS. Perhaps some bad geometry at the edge
of the track? Perhaps it's just my code again, but I definitely do not
attempt to update position directly in my code, only the gas, brake and
steering commands.

At the very least, someone might check the geometry at the above position
and see if there is anything funky there just in case. (I have no idea how
to check it myself.) This should be a rare case since my bot did 1270 runs
before this happened. Subsequent loads of my 1271st network will cause it
to crash at the same point every time. (I have a separate program
generating the networks, so I have been able to load that network in via
XML as a first run multiple times)

Feel free to let me know if I'm completely of my rocker here!

Jim

Hi Jim

Ah, ok, the "name" thing is because the "owner" of this is TORCS, so it 
does release the memory at some point, so if you do not "strdup" it 
tries to free "wrong" memory.

situation->currentTime is the current simulation time, yes.

Regarding your "often restart" use case, you should stay with 1.3.4, 
becuase I fixed many (possibly all) remaining memory leaks (see 
changelog), so if you restart very often this can get significant.

I do not know what kind of work you are doing, but there is as well a 
command line mode (e.g. if you want to evolve some AI without watching 
it, see the FAQ, section for researchers) or the blind practice mode 
from the TORCS menu.

Best regards

Bernhard

On 11/25/2012 05:57 AM, James Ihrig wrote:
> Thank you, I was able to solve both the gear changing problem as well as
> the crash on driver selection.
>
> As a note, I think the crash on driver selection may have been related
> to my random crashes during runs when I issued a restart. Once I changed
> my name and description from:
>
>
>      modInfo->name    = "MyBot";        /* name of the module (short) */
>      modInfo->desc    = "";    /* description of the module (can be long) */
>
> to
>
>      modInfo->name    = strdup("MyBot");        /* name of the module
> (short) */
>      modInfo->desc    = strdup("");    /* description of the module (can
> be long) */
>
> I no longer have an issue with that. I hadn't followed the other driver
> format exactly since I am not ever allowing multiple cars in my tests.
>
> I still don't know why my earlier attempts at gear changing didn't work,
> but your example code seemed to work. I will look at it more closely on
> Monday.
>
> As for the time, I am currently using situation->currentTime, my bot
> isn't timing some things correctly but at this point I'm still assuming
> the mistake is on my end. (30 second timer seems to take 2 minutes to end.)
>
> Am I correct in assuming that situation->currentTime is the current
> simulation time I should be using? Am I also OK to assume that this is
> measured in seconds?
>
> I have not yet attempted to speed up the simulation again as I'm still
> doing stability testing at real-time first.  (450+ race restarts with up
> to 2 min runs each and not a single program crash so it's looking
> fantastic so far.)
>
> Thank you again for your help,
>
> Jim Ihrig
>
>
> On Sat, Nov 24, 2012 at 10:40 AM, Bernhard Wymann <be...@bl...
> <mailto:be...@bl...>> wrote:
>
>     Hi James
>
>
>      > I've been running Torcs-1.3.3 and have had a couple problems. First,
>
>         when running my bot at a faster speed than real-time, my bot will
>         sometimes float straight up, then off to the side of the track
>         and the
>         race will end. (This issue seems like a bug, but I'm reluctant
>         to say so
>         since I've modified the TORCS code.) Second, I am having trouble
>         with
>
>
>     I guess this must have something to do with your changes, I have
>     never seen/heard of a problem like this before. The problem "makes
>     no sense" if you look at how TORCS works: It simulates basically in
>     simulation time, just when you have a "watching mode" selected it
>     synchronizes real and simulation time to spit out frames, that is
>     it. So I doubt that there can be something wrong. I hope you do not
>     rely on the real time clock in your robot, only use the simulation time.
>
>
>         I have tried to copy/paste this into my drive() fuction (from other
>         drivers code) but all I see is the gear bouncing between 1st and 2nd
>         gear, so I feel I must be missing something. I didn't understand
>         what
>         the code was doing so I tried a bunch of variations with _gear and
>         _gearCmd and and even tried manipulating the clutch. Is there any
>         documentation on how gear changing is supposed to work?
>
>
>     No, but it is trivial, the gearbox switches to the gear you choose.
>     How you do the decision is then your business;-) But one example is
>     explained in the robot tutorial:
>     http://www.berniw.org/torcs/__robot/ch3/gears.html
>     <http://www.berniw.org/torcs/robot/ch3/gears.html>
>
>     This method just works if the gearbox ratios differ and have the
>     correct order, so if you sabotage the gearbox you can make this
>     method fail, but for any halfway "real" gearbox it works.
>
>
>         I have tried upgrading to TORCS-1.3.4 to see if my issue with
>         the bot
>         leaving the course would be fixed, but it crashes once I select
>         a track
>         when configuring the race. (It seems to be crashing sometime
>         after the
>         constructor is called for my bot, but before any other function
>         in that
>         class.) Is there anything I need to know to move my bot to the newer
>         version?
>
>
>     Maybe, have a loot at this, this is the only adoption regarding
>     drivers in 1.3.4, all the other bots are unchanged (if I remember
>     correct):
>     http://torcs.cvs.sourceforge.__net/viewvc/torcs/torcs/torcs/__src/drivers/human/human.cpp?__r1=1.45.2.9&r2=1.45.2.10&__pathrev=r1-3-1
>     <http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/src/drivers/human/human.cpp?r1=1.45.2.9&r2=1.45.2.10&pathrev=r1-3-1>
>
>     If you took bt/beriw/etc. robots as base it should work then I
>     guess. I recommend just comparing what you do with the existing
>     robots or running the debugger, then you will see.
>
>
>         I'd also like to note that none of the links in the FAQ seem to be
>         working right now.
>
>
>     I recognized that some days ago, but I did not yet have time to look
>     into this, I upgraded the CMS recently, and it could be the result
>     of a cross site scripting fix which has done there, but I have to
>     look into this.
>
>     Best regards
>
>     Bernhard
>
>

Hi

Yes, if the car damage is more than 10000 damage points it gets removed 
from the race with a "virtual crane" (lift off the track, move to the 
side, let down).

Damage is done in collision.cpp, so you can comment it out/modify it there.

Best regards

Bernhard

On 11/25/2012 06:48 AM, James Ihrig wrote:
> Timing seems to be better now at real time, (still haven't tested the
> simulation while sped up again) I may have compiled the wrong version of
> my source. Also, I think I figured out why the vehicle was sometimes
> float up and then off the side of the track. It seems to happen when the
> vehicle takes heavy damage. I'll just need to look into turning that off.
>
> Jim
>
>
> On Sat, Nov 24, 2012 at 11:57 PM, James Ihrig <je...@gm...
> <mailto:je...@gm...>> wrote:
>
>     Thank you, I was able to solve both the gear changing problem as
>     well as the crash on driver selection.
>
>     As a note, I think the crash on driver selection may have been
>     related to my random crashes during runs when I issued a restart.
>     Once I changed my name and description from:
>
>
>          modInfo->name    = "MyBot";        /* name of the module (short) */
>          modInfo->desc    = "";    /* description of the module (can be
>     long) */
>
>     to
>
>          modInfo->name    = strdup("MyBot");        /* name of the
>     module (short) */
>          modInfo->desc    = strdup("");    /* description of the module
>     (can be long) */
>
>     I no longer have an issue with that. I hadn't followed the other
>     driver format exactly since I am not ever allowing multiple cars in
>     my tests.
>
>     I still don't know why my earlier attempts at gear changing didn't
>     work, but your example code seemed to work. I will look at it more
>     closely on Monday.
>
>     As for the time, I am currently using situation->currentTime, my bot
>     isn't timing some things correctly but at this point I'm still
>     assuming the mistake is on my end. (30 second timer seems to take 2
>     minutes to end.)
>
>     Am I correct in assuming that situation->currentTime is the current
>     simulation time I should be using? Am I also OK to assume that this
>     is measured in seconds?
>
>     I have not yet attempted to speed up the simulation again as I'm
>     still doing stability testing at real-time first.  (450+ race
>     restarts with up to 2 min runs each and not a single program crash
>     so it's looking fantastic so far.)
>
>     Thank you again for your help,
>
>     Jim Ihrig
>
>
>
>     On Sat, Nov 24, 2012 at 10:40 AM, Bernhard Wymann <be...@bl...
>     <mailto:be...@bl...>> wrote:
>
>         Hi James
>
>
>          > I've been running Torcs-1.3.3 and have had a couple problems.
>         First,
>
>             when running my bot at a faster speed than real-time, my bot
>             will
>             sometimes float straight up, then off to the side of the
>             track and the
>             race will end. (This issue seems like a bug, but I'm
>             reluctant to say so
>             since I've modified the TORCS code.) Second, I am having
>             trouble with
>
>
>         I guess this must have something to do with your changes, I have
>         never seen/heard of a problem like this before. The problem
>         "makes no sense" if you look at how TORCS works: It simulates
>         basically in simulation time, just when you have a "watching
>         mode" selected it synchronizes real and simulation time to spit
>         out frames, that is it. So I doubt that there can be something
>         wrong. I hope you do not rely on the real time clock in your
>         robot, only use the simulation time.
>
>
>             I have tried to copy/paste this into my drive() fuction
>             (from other
>             drivers code) but all I see is the gear bouncing between 1st
>             and 2nd
>             gear, so I feel I must be missing something. I didn't
>             understand what
>             the code was doing so I tried a bunch of variations with
>             _gear and
>             _gearCmd and and even tried manipulating the clutch. Is
>             there any
>             documentation on how gear changing is supposed to work?
>
>
>         No, but it is trivial, the gearbox switches to the gear you
>         choose. How you do the decision is then your business;-) But one
>         example is explained in the robot tutorial:
>         http://www.berniw.org/torcs/__robot/ch3/gears.html
>         <http://www.berniw.org/torcs/robot/ch3/gears.html>
>
>         This method just works if the gearbox ratios differ and have the
>         correct order, so if you sabotage the gearbox you can make this
>         method fail, but for any halfway "real" gearbox it works.
>
>
>             I have tried upgrading to TORCS-1.3.4 to see if my issue
>             with the bot
>             leaving the course would be fixed, but it crashes once I
>             select a track
>             when configuring the race. (It seems to be crashing sometime
>             after the
>             constructor is called for my bot, but before any other
>             function in that
>             class.) Is there anything I need to know to move my bot to
>             the newer
>             version?
>
>
>         Maybe, have a loot at this, this is the only adoption regarding
>         drivers in 1.3.4, all the other bots are unchanged (if I
>         remember correct):
>         http://torcs.cvs.sourceforge.__net/viewvc/torcs/torcs/torcs/__src/drivers/human/human.cpp?__r1=1.45.2.9&r2=1.45.2.10&__pathrev=r1-3-1
>         <http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/src/drivers/human/human.cpp?r1=1.45.2.9&r2=1.45.2.10&pathrev=r1-3-1>
>
>         If you took bt/beriw/etc. robots as base it should work then I
>         guess. I recommend just comparing what you do with the existing
>         robots or running the debugger, then you will see.
>
>
>             I'd also like to note that none of the links in the FAQ seem
>             to be
>             working right now.
>
>
>         I recognized that some days ago, but I did not yet have time to
>         look into this, I upgraded the CMS recently, and it could be the
>         result of a cross site scripting fix which has done there, but I
>         have to look into this.
>
>         Best regards
>
>         Bernhard
>
>
>

Timing seems to be better now at real time, (still haven't tested the
simulation while sped up again) I may have compiled the wrong version of my
source. Also, I think I figured out why the vehicle was sometimes float up
and then off the side of the track. It seems to happen when the vehicle
takes heavy damage. I'll just need to look into turning that off.

Jim


On Sat, Nov 24, 2012 at 11:57 PM, James Ihrig <je...@gm...> wrote:

> Thank you, I was able to solve both the gear changing problem as well as
> the crash on driver selection.
>
> As a note, I think the crash on driver selection may have been related to
> my random crashes during runs when I issued a restart. Once I changed my
> name and description from:
>
>
>     modInfo->name    = "MyBot";        /* name of the module (short) */
>     modInfo->desc    = "";    /* description of the module (can be long) */
>
> to
>
>     modInfo->name    = strdup("MyBot");        /* name of the module
> (short) */
>     modInfo->desc    = strdup("");    /* description of the module (can be
> long) */
>
> I no longer have an issue with that. I hadn't followed the other driver
> format exactly since I am not ever allowing multiple cars in my tests.
>
> I still don't know why my earlier attempts at gear changing didn't work,
> but your example code seemed to work. I will look at it more closely on
> Monday.
>
> As for the time, I am currently using situation->currentTime, my bot isn't
> timing some things correctly but at this point I'm still assuming the
> mistake is on my end. (30 second timer seems to take 2 minutes to end.)
>
> Am I correct in assuming that situation->currentTime is the current
> simulation time I should be using? Am I also OK to assume that this is
> measured in seconds?
>
> I have not yet attempted to speed up the simulation again as I'm still
> doing stability testing at real-time first.  (450+ race restarts with up to
> 2 min runs each and not a single program crash so it's looking fantastic so
> far.)
>
> Thank you again for your help,
>
> Jim Ihrig
>
>
>
> On Sat, Nov 24, 2012 at 10:40 AM, Bernhard Wymann <be...@bl...>wrote:
>
>> Hi James
>>
>>
>> > I've been running Torcs-1.3.3 and have had a couple problems. First,
>>
>>> when running my bot at a faster speed than real-time, my bot will
>>> sometimes float straight up, then off to the side of the track and the
>>> race will end. (This issue seems like a bug, but I'm reluctant to say so
>>> since I've modified the TORCS code.) Second, I am having trouble with
>>>
>>
>> I guess this must have something to do with your changes, I have never
>> seen/heard of a problem like this before. The problem "makes no sense" if
>> you look at how TORCS works: It simulates basically in simulation time,
>> just when you have a "watching mode" selected it synchronizes real and
>> simulation time to spit out frames, that is it. So I doubt that there can
>> be something wrong. I hope you do not rely on the real time clock in your
>> robot, only use the simulation time.
>>
>>
>>  I have tried to copy/paste this into my drive() fuction (from other
>>> drivers code) but all I see is the gear bouncing between 1st and 2nd
>>> gear, so I feel I must be missing something. I didn't understand what
>>> the code was doing so I tried a bunch of variations with _gear and
>>> _gearCmd and and even tried manipulating the clutch. Is there any
>>> documentation on how gear changing is supposed to work?
>>>
>>
>> No, but it is trivial, the gearbox switches to the gear you choose. How
>> you do the decision is then your business;-) But one example is explained
>> in the robot tutorial: http://www.berniw.org/torcs/**robot/ch3/gears.html<http://www.berniw.org/torcs/robot/ch3/gears.html>
>>
>> This method just works if the gearbox ratios differ and have the correct
>> order, so if you sabotage the gearbox you can make this method fail, but
>> for any halfway "real" gearbox it works.
>>
>>
>>  I have tried upgrading to TORCS-1.3.4 to see if my issue with the bot
>>> leaving the course would be fixed, but it crashes once I select a track
>>> when configuring the race. (It seems to be crashing sometime after the
>>> constructor is called for my bot, but before any other function in that
>>> class.) Is there anything I need to know to move my bot to the newer
>>> version?
>>>
>>
>> Maybe, have a loot at this, this is the only adoption regarding drivers
>> in 1.3.4, all the other bots are unchanged (if I remember correct):
>> http://torcs.cvs.sourceforge.**net/viewvc/torcs/torcs/torcs/**
>> src/drivers/human/human.cpp?**r1=1.45.2.9&r2=1.45.2.10&**pathrev=r1-3-1<http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/src/drivers/human/human.cpp?r1=1.45.2.9&r2=1.45.2.10&pathrev=r1-3-1>
>>
>> If you took bt/beriw/etc. robots as base it should work then I guess. I
>> recommend just comparing what you do with the existing robots or running
>> the debugger, then you will see.
>>
>>
>>  I'd also like to note that none of the links in the FAQ seem to be
>>> working right now.
>>>
>>
>> I recognized that some days ago, but I did not yet have time to look into
>> this, I upgraded the CMS recently, and it could be the result of a cross
>> site scripting fix which has done there, but I have to look into this.
>>
>> Best regards
>>
>> Bernhard
>>
>
>

Thank you, I was able to solve both the gear changing problem as well as
the crash on driver selection.

As a note, I think the crash on driver selection may have been related to
my random crashes during runs when I issued a restart. Once I changed my
name and description from:


    modInfo->name    = "MyBot";        /* name of the module (short) */
    modInfo->desc    = "";    /* description of the module (can be long) */

to

    modInfo->name    = strdup("MyBot");        /* name of the module
(short) */
    modInfo->desc    = strdup("");    /* description of the module (can be
long) */

I no longer have an issue with that. I hadn't followed the other driver
format exactly since I am not ever allowing multiple cars in my tests.

I still don't know why my earlier attempts at gear changing didn't work,
but your example code seemed to work. I will look at it more closely on
Monday.

As for the time, I am currently using situation->currentTime, my bot isn't
timing some things correctly but at this point I'm still assuming the
mistake is on my end. (30 second timer seems to take 2 minutes to end.)

Am I correct in assuming that situation->currentTime is the current
simulation time I should be using? Am I also OK to assume that this is
measured in seconds?

I have not yet attempted to speed up the simulation again as I'm still
doing stability testing at real-time first.  (450+ race restarts with up to
2 min runs each and not a single program crash so it's looking fantastic so
far.)

Thank you again for your help,

Jim Ihrig


On Sat, Nov 24, 2012 at 10:40 AM, Bernhard Wymann <be...@bl...> wrote:

> Hi James
>
>
> > I've been running Torcs-1.3.3 and have had a couple problems. First,
>
>> when running my bot at a faster speed than real-time, my bot will
>> sometimes float straight up, then off to the side of the track and the
>> race will end. (This issue seems like a bug, but I'm reluctant to say so
>> since I've modified the TORCS code.) Second, I am having trouble with
>>
>
> I guess this must have something to do with your changes, I have never
> seen/heard of a problem like this before. The problem "makes no sense" if
> you look at how TORCS works: It simulates basically in simulation time,
> just when you have a "watching mode" selected it synchronizes real and
> simulation time to spit out frames, that is it. So I doubt that there can
> be something wrong. I hope you do not rely on the real time clock in your
> robot, only use the simulation time.
>
>
>  I have tried to copy/paste this into my drive() fuction (from other
>> drivers code) but all I see is the gear bouncing between 1st and 2nd
>> gear, so I feel I must be missing something. I didn't understand what
>> the code was doing so I tried a bunch of variations with _gear and
>> _gearCmd and and even tried manipulating the clutch. Is there any
>> documentation on how gear changing is supposed to work?
>>
>
> No, but it is trivial, the gearbox switches to the gear you choose. How
> you do the decision is then your business;-) But one example is explained
> in the robot tutorial: http://www.berniw.org/torcs/**robot/ch3/gears.html<http://www.berniw.org/torcs/robot/ch3/gears.html>
>
> This method just works if the gearbox ratios differ and have the correct
> order, so if you sabotage the gearbox you can make this method fail, but
> for any halfway "real" gearbox it works.
>
>
>  I have tried upgrading to TORCS-1.3.4 to see if my issue with the bot
>> leaving the course would be fixed, but it crashes once I select a track
>> when configuring the race. (It seems to be crashing sometime after the
>> constructor is called for my bot, but before any other function in that
>> class.) Is there anything I need to know to move my bot to the newer
>> version?
>>
>
> Maybe, have a loot at this, this is the only adoption regarding drivers in
> 1.3.4, all the other bots are unchanged (if I remember correct):
> http://torcs.cvs.sourceforge.**net/viewvc/torcs/torcs/torcs/**
> src/drivers/human/human.cpp?**r1=1.45.2.9&r2=1.45.2.10&**pathrev=r1-3-1<http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/src/drivers/human/human.cpp?r1=1.45.2.9&r2=1.45.2.10&pathrev=r1-3-1>
>
> If you took bt/beriw/etc. robots as base it should work then I guess. I
> recommend just comparing what you do with the existing robots or running
> the debugger, then you will see.
>
>
>  I'd also like to note that none of the links in the FAQ seem to be
>> working right now.
>>
>
> I recognized that some days ago, but I did not yet have time to look into
> this, I upgraded the CMS recently, and it could be the result of a cross
> site scripting fix which has done there, but I have to look into this.
>
> Best regards
>
> Bernhard
>

Hi James

 > I've been running Torcs-1.3.3 and have had a couple problems. First,
> when running my bot at a faster speed than real-time, my bot will
> sometimes float straight up, then off to the side of the track and the
> race will end. (This issue seems like a bug, but I'm reluctant to say so
> since I've modified the TORCS code.) Second, I am having trouble with

I guess this must have something to do with your changes, I have never 
seen/heard of a problem like this before. The problem "makes no sense" 
if you look at how TORCS works: It simulates basically in simulation 
time, just when you have a "watching mode" selected it synchronizes real 
and simulation time to spit out frames, that is it. So I doubt that 
there can be something wrong. I hope you do not rely on the real time 
clock in your robot, only use the simulation time.

> I have tried to copy/paste this into my drive() fuction (from other
> drivers code) but all I see is the gear bouncing between 1st and 2nd
> gear, so I feel I must be missing something. I didn't understand what
> the code was doing so I tried a bunch of variations with _gear and
> _gearCmd and and even tried manipulating the clutch. Is there any
> documentation on how gear changing is supposed to work?

No, but it is trivial, the gearbox switches to the gear you choose. How 
you do the decision is then your business;-) But one example is 
explained in the robot tutorial: 
http://www.berniw.org/torcs/robot/ch3/gears.html

This method just works if the gearbox ratios differ and have the correct 
order, so if you sabotage the gearbox you can make this method fail, but 
for any halfway "real" gearbox it works.

> I have tried upgrading to TORCS-1.3.4 to see if my issue with the bot
> leaving the course would be fixed, but it crashes once I select a track
> when configuring the race. (It seems to be crashing sometime after the
> constructor is called for my bot, but before any other function in that
> class.) Is there anything I need to know to move my bot to the newer
> version?

Maybe, have a loot at this, this is the only adoption regarding drivers 
in 1.3.4, all the other bots are unchanged (if I remember correct):
http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/src/drivers/human/human.cpp?r1=1.45.2.9&r2=1.45.2.10&pathrev=r1-3-1

If you took bt/beriw/etc. robots as base it should work then I guess. I 
recommend just comparing what you do with the existing robots or running 
the debugger, then you will see.

> I'd also like to note that none of the links in the FAQ seem to be
> working right now.

I recognized that some days ago, but I did not yet have time to look 
into this, I upgraded the CMS recently, and it could be the result of a 
cross site scripting fix which has done there, but I have to look into this.

Best regards

Bernhard

Greetings,

I've been running Torcs-1.3.3 and have had a couple problems. First, when
running my bot at a faster speed than real-time, my bot will sometimes
float straight up, then off to the side of the track and the race will end.
(This issue seems like a bug, but I'm reluctant to say so since I've
modified the TORCS code.) Second, I am having trouble with shifting.

I have noticed this code in other bots:
http://codepad.org/bwc5LY4q

I have tried to copy/paste this into my drive() fuction (from other drivers
code) but all I see is the gear bouncing between 1st and 2nd gear, so I
feel I must be missing something. I didn't understand what the code was
doing so I tried a bunch of variations with _gear and _gearCmd and and even
tried manipulating the clutch. Is there any documentation on how gear
changing is supposed to work?

I have tried upgrading to TORCS-1.3.4 to see if my issue with the bot
leaving the course would be fixed, but it crashes once I select a track
when configuring the race. (It seems to be crashing sometime after the
constructor is called for my bot, but before any other function in that
class.) Is there anything I need to know to move my bot to the newer
version?

Any advice on any of the issues I currently have would be appreciated.

Thank you,
James Ihrig

P.S.

The full code I am currently working with is here:
code.google.com/p/aiproj2012/source/checkout

To speed up the race, I have added the following line to the bottom of
ReOneStep() in raceengine.cpp

    ReInfo->_reTimeMult = 1.0;

I'd also like to note that none of the links in the FAQ seem to be working
right now.