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

A minor update of simuv3 is on CVS, with the new limited slip
differential code.
I renamed the old code option to DIFF_LOCKING, since it was essentially
that.

Of course, the new LSD is not the only LSD possible.  It has an
interestingly different behaviour from the viscous coupler and the
locking though, in that it behaves rather more like a free differential
under low loads.

I've tested it quite a bit and it feels quite smooth.

-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

On Sun, 18 Jun 2006 02:39:48 +0200, Charalampos Alexopoulos  =

<ba...@re...> wrote:

> Hi
> I modify the source in order to make a more advanced cockpit design fr=
om
> the xml file of the car.The modified sources are compatible with the
> existing xml file while you can make more complex cockpits like the on=
e  =

> in
> the attached image.If you think that is interesting  i will be happy t=
o
> submit the code.
> Regards
> Charalampos Alexopoulos
>

did you forget the image?! sounds interesting anyway.

pls submit the code , that way anyone interested can check it out and it=
  =

will be there for future ref.
You dont need to wait for an official invitation ;)


I dont know what the policy is on this list but if it's not too complex =
 =

include the text in the post since it seems the mail archive interface  =

does not handle attactments.

attachments will just get to those currently on the list but not be  =

visible on the archive.

look forward to seeing what you've done.

oops!! i forgot to attach the image

> Hi 
> I modify the source in order to make a more advanced cockpit design
> from
> the xml file of the car.The modified sources are compatible with the
> existing xml file while you can make more complex cockpits like the one
> in
> the attached image.If you think that is interesting  i will be happy to
> submit the code.
> Regards
> Charalampos Alexopoulos

Hi 
I modify the source in order to make a more advanced cockpit design from
the xml file of the car.The modified sources are compatible with the
existing xml file while you can make more complex cockpits like the one in
the attached image.If you think that is interesting  i will be happy to
submit the code.
Regards
Charalampos Alexopoulos

Hi,

one trivial thing that bugs me each time I run torcs is the exit  
confirmation. My enjoyment of torcs is always marred by this annoyance on  
quitting the program.

I really hate these windozian " are you really , really sure ?" prompts at  
every turn. If I choose quit , it's because I want to quit not because I  
want to continue to run the game. Why assume the opposite?

If I am about to quit a word processor without saving my work, fine, I'd  
like to be warned. That is not the case here.

This is made worse by the fact that the default choice is to cancel the  
quit and stay in torcs. This means several manipulations are needed just  
to get out.


So ultimately I would like to suggest that the quit confirmation dlg is  
redundant and that it be removed. That would be nice.

Failing that I propose a simple patch that makes "Yes, let's quit" the  
default so all we need to do it hit <Enter> to confirm.

<Esc><Esc><Enter> and we're gone. Phew!

I hope this meets with general satisfaction and applause  ;)



Index: torcs/src/libs/client/exitmenu.cpp
===================================================================
RCS file: /cvsroot/torcs/torcs/torcs/src/libs/client/exitmenu.cpp,v
retrieving revision 1.3
diff -r1.3 exitmenu.cpp
65,70d64
<                     "No, Back to Game",
<                     "Return to TORCS",
<                     mainMenu,
<                     GfuiScreenActivate);
<
<     GfuiMenuButtonCreate(exitmenuHandle,
74a69,75
>    GfuiMenuButtonCreate(exitmenuHandle,
>                     "No, Back to Game",
>                     "Return to TORCS",
>                     mainMenu,
>                     GfuiScreenActivate);
>
75a77
>

Hi Wino (and others),

On Wednesday 7 June 2006 10:19, wi...@pi... wrote:
> On Tue, 06 Jun 2006 19:00:29 +0200, Mart Kelder <ma...@ke...> wrote:
> > Because not all robots have included these features, I added a attribute
> > to
> > the robot xml-file which lists the implemented features. At race start,
> > the
> > intersect between those features are taken, so only the features all cars
> > have are used (this means no safetycar if there is one car that isn't
> > aware
> > of it).
>
> nice idea , you might want to add some means of checking which car is
> blocking any particular feature. It could be a drag trawling all the xml
> files by hand to find out why one of these feature is no working.

At the moment it is quite simple: the bt's have most of the features, other 
robots haven't got any feature. The features of the player depends on the 
skill level.

Because it isn't that difficult to add such a list in the configuration screen 
where also the race distance can be configured, I added a list in that 
screen. Note that that screen isn't always displayed. I uploaded the slightly 
altered version.

Regards,

Mart

After a fair amount of research, I have discovered that there are many
types of LSDs.  I have discovered the following:

1) Near the limit of travelling at constant speed, they function as open
differentials.
2) More torque is transferred to the slower moving wheel when positive
drive train torque is applied.
3) When negative drive train torque is applied, behaviour differs
between each type.
4) Near the limit of large rotational differences between wheels and
high drive train torque there is usually a 'maximum torque bias'.
5) Performance vehicles use differentials which smoothly move from open
to semi-locked.

I have made a model which the above properties.  It uses:

1) The 'maximum slip bias' parameter to determine maximum torque bias to
apply when the wheels are at maximum slip.

2) The 'locking input torque' parameter specifies the amount of input
torque required to apply maximum bias (This is done smoothly).  When
this is very small, the differential will lock for very small slip
values unless the drive torque is exactly zero (i.e. when coasting).

The following code exemplifies.  It is an extension of the open
differential.  When the pressure goes to 100%, the torque is distributed
to the wheels through a static friction model.  When either DrTq or the
slippage is near zero, the differential acts in an open manner.

float spiderTq = inTq1 - inTq0;
float rate = fabs(DrTq/differential->lockInputTq);
float pressure = tanh(rate*(spinVel1-spinVel0);
float bias = differential->dSlipMax * 0.5f* pressure;
float open = 1.0f - fabs(pressure)
DrTq0 = DrTq*(0.5f+bias) + spiderTq*open;
DrTq1 = DrTq*(0.5f-bias) - spiderTq*open;


The easiest way to tune this differential is to set dSlipMax to near 0
for more 'open' performance and to near 1 for more 'locked' performance.
(Note that this is never fully locked).  I found that values in the
range 0.5-0.8 work well and that the cars are substantially easier to
drive than in the previous on-off locking model.

-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

On Tue, 06 Jun 2006 19:00:29 +0200, Mart Kelder <ma...@ke...> wrote:

>
> Because not all robots have included these features, I added a attribute
> to
> the robot xml-file which lists the implemented features. At race start,
> the
> intersect between those features are taken, so only the features all cars
> have are used (this means no safetycar if there is one car that isn't
> aware
> of it).


nice idea , you might want to add some means of checking which car is  
blocking any particular feature. It could be a drag trawling all the xml  
files by hand to find out why one of these feature is no working.

regards

Hi all,

A couple of months ago I wrote this mailings list about blue flags which I 
implemented. It didn't fit in the coming release schedule, so the things in 
the mail obviously won't fit either. But I hope this (or a part of it) will be 
usefull some time. Also, I think it is in the idea for open source to share 
the source code, so I uploaded my changes to a website.

As earlier, blue flags are included. Currently, I disabled penalties for not 
letting an opponent overtake.

There are also yellow and green flags. If an accident occurs, these flags 
will be enabled. Overtaking is forbidden; if an opponent does overtake, a 
Stop-and-go penalty will follow.

If there are (depending on track type) many accidents, the safetycar will be 
send out. The safetycar is just a very slow bt-robot, which likes pitting in 
the last pit post. If a safetycar is send out, all over the tracks are yellow 
flags enabled, so nobody can overtake (with few exceptions, of course).

There also are white flags for cars driving slowly. It is just a warning for 
other drivers that a car is driving 20 m/s slower then the average speed in 
that segment.

As I can't make people waving flags, I hang lights every 200 meter above the 
tracks. There are also lights at the pit exit. Those lights will warn a driver 
that there are other cars near the pit exit. The pit exit will be closed if 
the safetycar drives nearby the pit lane. Leaving the pits at that point will 
disqualify a car.

Because not all robots have included these features, I added a attribute to 
the robot xml-file which lists the implemented features. At race start, the 
intersect between those features are taken, so only the features all cars 
have are used (this means no safetycar if there is one car that isn't aware 
of it).

Last but not least, I added timed sessions (including races, practice and 
qualification). This includes multi-car qualification sessions.

Because the files are quite big, I uploaded them to a website. The files can 
be found at http://home.kpnplanet.nl/~k....@kp.../mart/torcs.html

Regards,

Mart

More on the differential.  The Viscous Coupler seems to be just fine and
to correspond to the 'limited slip viscous coupling' differential.
However I am uncertain as to what type of physical differential the
'limited slip' differential in TORCS is supposed to be.  If anyone has
any info on that, I'd check it up later to make sure the simu
implementation corresponds to the actual physical device.

Cheers,
Christos
-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

On Tue, 06 Jun 2006 16:04:10 +0200, Christos Dimitrakakis  
<dim...@id...> wrote:

>
> Strictly speaking, there dead zone is not 0 anywhere (at least on the
> side of TORCS)
well I can produce 19000 on jstest and not get a twitch out of torcs so  
maybe the extreme exponent was resulting in <1.0 from 19000. That makes  
some sense now I know it's x^n.


> - changing the 'dead zone' value should make no
> difference with the wheel.
Thanks, I noted that in your last post.


If you set the sensitivity to 1 you should
> see a linear response.  I usually set it between 0.5 and 0.8.

Thanks for the tip, maybe something in the faq would be nice since this  
bahaviour is not at all what one would guess without knowing the code.  
There's a natural assumption that it would be some scaling factor.

A value >1 renders it somewhat unstable in the sense that you can no  
longer go straight ahead.

The range of values you suggest would be a real help.


>
> Note also that some joysticks have a 'hardware' dead zone which you can
> change with joystick utilities such as jscalibrator.

I'll try to look into that although last time I would not compile on my  
2.6.17 rc kernel. Indeed the hardware deadzone of +/- 5 degrees means the  
joystick is not well suited to torcs. I get on better with the mouse.



Last note the label should be "steering sensitivity" : sensible in German  
and French does not map directly to sensible in English. It will either  
get a laugh or a puzzled look from most native english speakers.

Thanks for your help.

I was just looking at the code for the limited slip differential.
Why? Because I tried different values for "max slip bias", but it seemed
to have no affect at all, while it should.

The code goes like this:

                case DIFF_LIMITED_SLIP:
// When the drive torque exceeds the lockInputTq, then we just update it
// as a spool differential! Why? I think this is a mistake.
                        if (DrTq > differential->lockInputTq) {
                                updateSpool(car, differential, first);
                                return;
                        }


                        spdRatioMax = differential->dSlipMax - DrTq *
differential->dSlipMax / differential->lockInputTq;

// Try to equalise velocities velocities..
                        if (spdRatio > spdRatioMax) {
                                deltaSpd = (spdRatio - spdRatioMax) *
fabs(spinVel0 + spinVel1) / 2.0;
                                if (spinVel0 > spinVel1) {
                                        spinVel0 -= deltaSpd;
                                        spinVel1 += deltaSpd;
                                } else {
                                        spinVel0 += deltaSpd;
                                        spinVel1 -= deltaSpd;
                                }
                        }
// Why the if clause? Why should the bias change sign depending on which
// wheel is faster? I thought the bias was permanent... and I'd write
// DrTq1 = DrTq * differential->bias;
// DrTq0 = DrTq * (1.0 - differential->bias);
// unless the bias means something else than what I think it does..

                        if (spinVel0 > spinVel1) {
                                DrTq1 = DrTq * (0.5 + differential->bias);
                                DrTq0 = DrTq * (0.5 - differential->bias);
                        } else {
                                DrTq1 = DrTq * (0.5 - differential->bias);
                                DrTq0 = DrTq * (0.5 + differential->bias);
                        }
                        break;

-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

wi...@pi... wrote:
> 
>> Do you have the same problem when playing with the mouse?
>>
>> If you don't have the same problem then perhaps you should take a look
>> at the calibration again.  I ran an experiment with 'jscal' and found
>> that it was possible to calibrate the joystick in such a way that it
>> exhibited an on-off response, which of course made it impossible to
>> drive.
>>
> 
> Thanks for explaining a little of the how the calibration is coded. I
> think I can see how that ties into what I am seeing. Responce like a
> chopped off parabola. With the values I gave it, a broad dead zone then
> very steep rise.
> 

Strictly speaking, there dead zone is not 0 anywhere (at least on the
side of TORCS) - changing the 'dead zone' value should make no
difference with the wheel.  If you set the sensitivity to 1 you should
see a linear response.  I usually set it between 0.5 and 0.8.

Note also that some joysticks have a 'hardware' dead zone which you can
change with joystick utilities such as jscalibrator.

Note also that the speed at which you can change the steering angle is
bounded.




-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

> Do you have the same problem when playing with the mouse?
>
> If you don't have the same problem then perhaps you should take a look
> at the calibration again.  I ran an experiment with 'jscal' and found
> that it was possible to calibrate the joystick in such a way that it
> exhibited an on-off response, which of course made it impossible to  
> drive.
>

Thanks for explaining a little of the how the calibration is coded. I  
think I can see how that ties into what I am seeing. Responce like a  
chopped off parabola. With the values I gave it, a broad dead zone then  
very steep rise.


Yes , the mouse is the same, so it's not an external joystick util  
interfering here.

In fact, mouse steering is a better way to see the effect because you can  
have the mouse pointer over the nose of the car and the extent of the dead  
zone is a lot more evident (although you can't put any numbers on it).
It seems the basic problem is that we need full lock to recover from a  
skid or crash but most of the time very limited steering.

Joysticks , even plastic steering wheel types , only have a very limited  
movement. Real cars probably have two full rotations of the wheel.

This probably means some trick has to be found which deviates from correct  
modelling of a car.


Could you point me to where this is coded? I'll experiment a bit and see  
if I can get something that works a bit better.

Thanks again for your help.

> So it seems impossible to desensitise the steering without introducing a
> huge dead zone.
> 
> I have not dug in to see how this is coded but does that makes sense to
> you?
> 

The code uses a x^n law to make the response go from a linear to a
curved response (with almost no response around the center) - the dead
zone value in TORCS is not used with joysticks at all!

So, sensitivity in joysticks controls a 'soft' dead zone - because you
want to have maximal response when the wheel is fully locked and you
want to have zero response when the wheel is centered.  So you cannot
control the extreme values of the response curve, but its shape.
Perhaps there is a better shape than x^n, but what?  I personally find
it good enough.

Do you have the same problem when playing with the mouse?

If you don't have the same problem then perhaps you should take a look
at the calibration again.  I ran an experiment with 'jscal' and found
that it was possible to calibrate the joystick in such a way that it
exhibited an on-off response, which of course made it impossible to drive.



-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

>>
>> Why is the program not reacting to the first 3/4 of the steering control
>> movement?
>>
>
> That's very strange.  Are you running the latest CVS?  We fixed a very
> minor problem with steering in that, but that's all.
>
> I personally use the joystick with a dead zone equal to zero, since the
> wheel itself already has a dead zone.
>
>


Thanks,  I've had another look at this comparing the jstest output as  
before. It seems that altering the "steer sensitivity" has a marked effect  
on the dead zone.

the results I posted before with excessive dead zone were with sens.=0.08;  
if I set it to 0.18 the dead zone comes down to +/- 14000 and if I go to  
-.88 I get a much more reasonable dead zone around 500 each side.

So it seems impossible to desensitise the steering without introducing a  
huge dead zone.

I have not dug in to see how this is coded but does that makes sense to  
you?

I presume this is not the expected behaviour.

regards.

wi...@pi... wrote:

> In any case the problem remains essencially the same: it require 3/4 full  
> movement before any steering occurs.
> 
> 
> 
> I am running a classis two axis analogue joystick, I use only left right  
> axis for steering, using torcs calibration to set it up.
> 
> I have a set of analogue pedals plugged in as js1 and this seems to work  
> as expected. I get fine accel control starting at the slightest touch of  
> the pedal.
> 
> 
> 
> Why is the program not reacting to the first 3/4 of the steering control  
> movement?
> 

That's very strange.  Are you running the latest CVS?  We fixed a very
minor problem with steering in that, but that's all.

I personally use the joystick with a dead zone equal to zero, since the
wheel itself already has a dead zone.


-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

Hi,

I have what I initially saw as a steering sensitivity problem , since fine  
corrections to the steering seemed impossible then the car would veer to  
one side.

It was basically uncontrollable above about 80km/h

On closer inspection it seems to be an issue with the deadzone.

I ran a test with jstest in a terminal next to the race and was able to  
see the following was happening.

joystick /dev/input/js0 output registers a change starting at about 5  
degrees off centre. Careful manipulation can register settings as low as a  
few hundred (fds=32000)

looking at the car's behaviour no steering movement occurs until joystick  
position regiester about 25000 !

I brought the deadzone down to 0.01 and this may have made a slight  
difference and steering seemed to start around 23000. Due to the crudeness  
of the test this difference is within experimental error and may in fact  
be just that , an error.

In any case the problem remains essencially the same: it require 3/4 full  
movement before any steering occurs.



I am running a classis two axis analogue joystick, I use only left right  
axis for steering, using torcs calibration to set it up.

I have a set of analogue pedals plugged in as js1 and this seems to work  
as expected. I get fine accel control starting at the slightest touch of  
the pedal.



Why is the program not reacting to the first 3/4 of the steering control  
movement?

TIA.