RSX / RCX & REX Files {Scripting}

OK, I decided that the silly min/peak values were, err, silly.

So after pondering with Cosmo (well, talking at him for an hour haha), I thought a curve is probably nicer logic.

Using a polynomial curve best-fitting the rough points you want in Excel, I just dropped that over my rev dependent boost value.

rcar $car=get scriptowner car

float $rpm
float $request
float $maxtorque
float $boost
float $maxthrottle = 1
float $speed = 0

float $spool = 2.5
float $friction = 1.5

while 1
{
$request = get $car throttle
$rpm = get $car rpm / 1000

//stops turbo spinning backwards (friction will be 0 at 0 speed, so it'll stop slowing down)
//or spinning on forever (artifical limit to simulate wastegate or running out of efficiency etc)
if $speed > 1000
{
$speed = 1000
}
else if $speed < 0
{
$speed = 0
}
else
{
$speed = $speed + ($request * $spool) - $friction
}

$boost = ((0.0179 * (pow $rpm to 2)) - (0.16 * $rpm)) + 1.0431

$maxtorque = ($request * $boost) + (($maxthrottle - $boost) * $request * ($speed/1000))

set $car throttle $maxtorque

paint ($speed) at float[2]{650,125}
paint ($boost) at float[2]{650,100}
paint ($maxtorque) at float[2]{650,50}

interrupt
}


Sooo, I've divided the input rpm by 1000, so the coefficients are not tiny.

I just set up a data sheet in Excel like

rpm (1000s) boost
0 1
1 1
2.5 0.7
5 0.7
7 0.8

So in theory, at idle you get no boost impacts on the throttle action, so as you floor the car it's giving the torque.crv value instantly. Then as the boost value drops, you add that fraction to be generated and added by the turbo 'speed'
As the revs rise past peak power I've trimmed the curve a bit, not sure if that will feel right or not in this case, but hey, just messing.

The values above are for the new Focus RS, and feel pretty good with that torque curve and car!


Feel free to tinker and ponder about with it. I think given this system and maybe a polynomial to the 6th order you could get a really nice shape to follow most 'curves' to fit your cars needs, and get the car responding fairly nicely to real behaviour.
Ideally you could just reference a curve LUT but anyway, this works ok for now hehe...

Now to try it on a mega-boost Venom GT hehe :D

Dave
 
Pardon my ignorance Dave, but how would this be any different than just modding the torque curve to reflect the turbo kicking in. Most modern turbo system go to great length to be as lag-free as possible.:confused:
Not trying to discourage any coding for certain. Just confused.

Alex Forbin
 
Pardon my ignorance Dave, but how would this be any different than just modding the torque curve to reflect the turbo kicking in. Most modern turbo system go to great length to be as lag-free as possible.:confused:
Not trying to discourage any coding for certain. Just confused.

Alex Forbin

Well I'd say because you can't model turbo lag for older cars. I don't really feel to much interest in driving a new TFSI x.x litre VW Something. I'd rather drive this
(also, that channel is eargasm)

Say you add the turbo into the torque curve - that would mean you have to assume the turbo is at full boost all the time. This works out for most turbo cars if you simply pretend you rev the car up to spin up the turbo, but as soon as you start to drive by simply letting go the clutch smoothly you already have a torque curve as if the turbo has fully spun up (which ofcourse would not happen with bigger turbos).

It's just the worst workaround possible in my opinion. So I think Mr. Whippy is on the right "path".
 
The problem is that a turbo takes time to respond. The torque curves we draw might realistically represent a dyno run in say 4th gear from 1000rpm to the red line.

So assuming we always drive off-boost at 1000rpm, and then accelerate full throttle, the curve will be pretty accurate.

However, in the lower gears, we can often accelerate faster up the rev range than the turbo can get up to boost for any given rpm point vs the higher gear, so torque is lower.
This is often seen with a torque curve that moves to the right (higher rpm), the lower the gear you use.

So there is that attribute which is different. Modern cars it is less evident, but still noticeable.


The main issue is that when you come off the throttle at say 4000rpm in a 911 Turbo, and then get back on the throttle, there should be maybe 0.5 to 1 second of time that passes between reaching full throttle and achieving full torque at those rpm that is possible.

It sounds trivial, and more modern cars that time is smaller, but it can add up to a great deal in the cars character. Awd turbo cars like a 911 Turbo or Nissan GTR become much less sensitive on the limit because on/off throttle movements don't make big changes in torque, it kinda softens them. The difference between a 911 GT3 and a 911 Turbo is this loss of sharpness, in return for a bit more wallop!


For now in Racer it's hard to really spot it in action when using realistic ish values for modern cars (ie, sub 1s lag)... the main issue I think is that there is little visual cue to acceleration. SMD cameras help with some pushing back in the seat movement, but that is hard to gauge because under say 1g constant acceleration, there is no visual cue to you. Only when g's change is it apparent in the SMD camera moving.

Perhaps with a tilting camera (tilts back when accelerating hard, and tips forward when decelerating), you could more easily gauge the acceleration as 1g would tilt back twice as far as 0.5g, and you would get used to different tilts corresponding to different g forces.
Maybe if we can cue our senses into something to detect g forces from a visual sign, then the presence of the turbo will be more obvious. Ie, throttle right in, head tips back a bit, then a second later it pushes twice as hard again and the view tilts back another 5deg say...!?


Been working on this script more. I've been scratching my head over the implement more. I think I've got a good logic now, just I'm a crappy programmer. I can do straight physics pretty well too, but programming something is different. Trying to get nice numbers from solutions so you can factor coefficients sweetly etc... arghhh :D

I think I'm looking at going down the route of something very similar the Racer engine, so inertia, force (function of current torque output), and braking coefficient, and then a curve to define where 'boost' is a function of the delivery of the engine (the fraction that is made instantly and the fraction that needs the turbo to be spinning at full speed to give)


Tinkered with awd bias but it's early days. I'm quickly realising that to do it well will require very strict programming logic to make sure I or any user gets the kind of behaviour they expect from the coefficients they plug in.

Anyone done anything on gears yet? The command executes a proper change (not a sudden 'change in time' shift)... so automatic gearboxes should be possible now in a nice way (true kick-down and all that stuff)...

Dave
 
I did have a friend with a 930 Turbo and he said it was a problem but you got used to it, my Porsches were NA. The Esprit TT I used to drive never seemed to lag, though it did have a rather loud sucking sound as the turbos spooled up.
I've wanted to try some autobox coding but haven't had much spare time lately.

Alex Forbin
 
Autoboxes look complicated.

I was reading this last night

http://www.mathworks.com/products/s...demos/shipping/simulink/sldemo_autotrans.html

For now you could probably forget the torque converter and approximate it using a slippy standard clutch (and retain Racers logic for the entire shift process), and then just implement a kind of LUT as per the diagram with the shift thresholds (Cosmo posted one on here in the past for a DSG gearbox)

In theory you then just check diff speed vs throttle input and calibrate your curves to get the response you want. The logic is *fairly* simple, not sure how streamlined you could get it.

These are the times when you think you could probably program a system that felt 'ok', but then it might have a weakness vs some special gearboxes that did things a certain way. Ie, the new ZF 8 speed auto can shift blocks of gears, say 8th to 2nd in one change. Do we need to consider that in our programming somehow, just for these special gearboxes...

I'm of the mind that if it 'feels' right and you can make it do what the real thing does, approximately, then for our needs it's close enough :D

Would be cool to get kick-down just by flooring it in Tib's Jag X-Type haha :D

Dave
 
I agree on not getting overly complicated with things. A slippy clutch would work fine with one of the old style pre-lockup style converters since that's what they approximated in RL. It would be better though to be able to control the clutch directly.
As for shifting I was thinking along the lines of comparing the throttle position/present gear/mph.
If the throttle is light+speed low=shift@low RPM
If the throttle is medium=shift@normal RPM
If the throttle is heavy=kick down and hold to max RPM before shifting unless in 1st gear.

Ideally it would be nice to have access to the torque calc used to determine clutch slip and base the shift points on load.

Alex Forbin
 
Just the basics (tuned for the Lamborghini, not the best test subject on Carlswood cause it barely gets out of 2nd gear on the track). Basically a DSG, if the transmission is tuned that way.

Might need to 'reload scripts' to get it functional - physics scripts don't seem to autorun.
scripts/physics/automatic.rsx
Code:
rcar $car = get local car
float $throttle = 0
float $gear = 2
float $rpm = 1000
float $mindownrpm = 2500
float $maxdownrpm = 5500
float $minuprpm = 3900
float $maxuprpm = 7900
float $shiftpoint = 0
while 1
{
  $throttle = get $car throttle
  $gear = get $car gear
  $rpm = get $car rpm
  // shift down?
  $shiftpoint = $mindownrpm + $throttle * ($maxdownrpm - $mindownrpm)
  if $rpm < $shiftpoint
  {
    if $gear > 2
    {
      set $car gear ($gear - 1)
    }
  }
  $shiftpoint = $minuprpm + $throttle * ($maxuprpm - $minuprpm)
  if $rpm > $shiftpoint
  {
      if $gear < 7
    {
      set $car gear ($gear + 1)
    }
  }
interrupt
}

If you're just cruising in 3rd around 120km/h and you punch it, it'll drop down to 2nd, then into 1st most of the time. I didn't play too much with the maximum range on either shift, cause I'd have to figure out where each gear ratio overlaps (don't want it to be shift-up and shift-down at the same time)

Throttle determines shift points - more open throttle = higher. I haven't played with the built-in automatic so I don't know if this is better or the same.

Also gives you somewhat launch control, if you put it in neutral and rev it up to 7900 rpm it'll throw it into first for you. Should probably write an exception for the low gears.

Main problem I see right now is that if you're decelerating from full throttle (eg. coming to the hairpin on Carlswood) it has a tendency to shift up, when the throttle drops quicker than the speed. Which just means more downshifts once you get to the curve.

Also, the amount of open throttle to affect the shift could probably stand to vary based on speed - at 100km/h (in a more reasonable car) cruising takes about 45% throttle anyway, so the lowest downshift rpm when you ease off the throttle is 4000+ instead of 2500.
 
Haha, well I had a fun evening fighting with a nice auto system.

Suddenly you realise why most games don't implement one (aside from it being not really essential for racing games), because it's not really that easy to automate. Thus each car with it's different gears and character, and engine output, would need coefficients tweaking around.

If as Alex said, you could sense load and work with that, there would still be coefficients to tinker with. Perhaps if you were really good you could put your current gear in, and lookup the torque.crv, lookup the gear ratios from car.ini, and then determine the current peak torque possible vs the lowest one possible, and then use the current throttle as a demand, and move to the gear that gives the closest acceleration possible to the demand given (assuming the gear can be selected)
Could actually not be so nice though, wouldn't know till you programmed it, eek!


So far I've basically drawn (using 4th power polynomials) curves to represent the shift up and down points between gears across the known speed range and throttle range of the car.

So basically the set up of the code is identical for every automatic, but the polynomials change. You just copy those best fit equations from Excel, and you basically build your curves in there (ideally you would draw all the curves in CurvEd and somehow have several curves in one file and load from there, but I'm not going there haha!)

It seems to work ok... the main thing I need to do is avoid it telling the gearbox to do stuff while the gear is currently changing (a shame that Racer clutch/gear change system doesn't block requests when a shift is currently active)...


Just like Stereo's system really, but with the request vs speed values put into curves... I can imagine calibrating them to each car will be a big task though!


Stereo, I guess with your code you could add a bit more granularity to the input values? Ie, set the min/max per gear too?
Perhaps just have the same coefficients set per gear in a big if else if statement!? Might offer almost all the flexibility you need then to avoid gear overlap issues?
Thinking more that might just be a lot nicer than mine unless someone wants to get a car really really close to the real ones reactions by getting the curves perfect.

Thanks

Dave
 
Thanks for the test code Stereo - it acts a bit overexcitedly at the moment, but it's early days of course :)
I get the feeling that your approach, together with Alex Forbin mentioning load based logics, could be a nice way to deal with CVT simulation - the interpolation method seems to fit right in there.



The link Dave posted on the last page shows most (all?) the stuff that makes up the classic automatic transmission behavior I think - we'll ignore complex features like "learning the driver", anticipation based on vehicle dynamics sensors or GPS and such anyway, for now.
Eventually, it would be nice to be able to select PRND321 each, for example, and get appropriate responses from the system in Racer though. Or being able to manually interfere and then return to automatic mode after a certain time has passed (or some other trigger) :)



In my opinion, there are two main subsystems we have to deal with; the automated gear selection process and the torque converter behavior, including stall condition.

For the shifting pattern, a LUT/array approach probably would be the most efficient method and it's closest to real life definition, too. There's a curve type example in the aforementioned link. Otherwise, an array type would look like this.

Probably neater for implementation right now, as we can't create curve files with multiple lines such as the other approach requires. It does take more manual input than a polynomial, but in return it offers a more straight forward (compared to "random" poly factors), high resolution control over shift behavior. It "just" needs a nice logic written to maneuver the array :wink:



With stall ratios typically in the region of 2:1 for the majority of vehicle types we deal with, this is also a fairly important performance aspect of torque converter automatics. We have control over clutch and max_torque via scripts now, too, so it should be doable (?).



Another small thing to consider would be creeping - right now, Racer's automatic implementation doesn't creep when in gear, or if you set it up to do that, it won't stop the torque transfer when you're standing still with the brakes applied (so you constantly get burnouts, involuntarily).
 
I don't think we have clutch control yet - scriptfuncs only lists get (rcar) clutch.

Is the LS1 shift table showing speed(mph?) to shift? I guess setting it up that way would ensure you only have one particular gear at any speed without having to worry about ratios. Definitely needs a LUT though, I just used interpolation because it was a 1st approximation of the same lines.

I'll try to figure out the Simulink explanation of a torque converter later, I have a vague idea of how they work physically but I'm not at all familiar with the equations, or how it translates to Racer variables.

That and figure out how to easily write a look-up table in scripts... do not want to script in every if-else. For ease of use, would it be better if I directly copy the Racer crv format, or can I get away with something simpler?
Code:
3 // number of throttle settings
3 // number of gears
4 // column width
  0 0.5   1 // throttle
 10  15  18 // 1st to 2nd
 20  30  35 // 2nd to 3rd
 13  20  23 // 3rd to 2nd
  7  12  14 // 2nd to 1st
Fixed width table would be the easiest thing to read in, so something like this.


Main question right now: Can clutch (and other variables the scripts have access to) be directly related to transmission output rpm, or do the gear ratios, final drive, wheel radius need to be coded into the script so it can calculate expected-rpm vs. actual-rpm from the car's speed? It looks like (approximately) the larger the difference in input/output speeds, the higher the torque_factor should be to compensate, but I don't really know how the "clutch" variable fits in to making sure the gears change smoothly.




On another note, since I learned to drive (instructor had an auto Mazda Protege) I've only driven cars with manual or cvt so I don't remember much about how automatics feel shifting... gotta go by written explanations I guess.
 
Right, my bad, I didn't double-check the clutch listing.

The LS1 table indeed shows vehicle speed in mph. I'd paraphrase the content like this perhaps: Depending on the currently selected gear, you have one or two options to either shift up, down or either (1st and 4th obviously can only change in one direction). Then, depending on the throttle position there are one or two entries, vehicle speeds, that determine whether the step should be a downshift, hold or upshift. Sample case: 2nd gear selected, 50% throttle. If you're going less than 7mph, 1st will be selected. Between 7 and 48mph 2nd is held and above 48mph 3rd gear is selected.

The table you have there is probably fine - I'm not that experienced in coding, though I thought an array would be a neat way to list it. Basically, you can feed a multidimensional array like a matrix, which keeps the data fairly compact. The challenging part is to then set up the code to read the array's contents properly.
A simple example of that is the positioning for onscreen paint scripts - eg. paint ($speed) at float[2]{650,125} - where the pixel coordinates are the contents of the array. You can visually arrange that to duplicate the tables in a user friendly way and have the scripts run through the columns and rows to deal with the shifting. That's where I'll try to sneak out through the forum's shadows :wink:



The clutch sits in front of the transmission, so all the factors contributing to the effective overall gear ratio need to be taken into account. If I got your quesiton right, the problem here is that the clutch itself is half engine speed, half transmission speed, so you'd take the engine speed as the expected rpm, and the (overall ratio corrected) vehicle speed as the actual speed... I'm not quite sure this is what you had in mind though, sorry.

The given peak stall ratio occurs for maximum in/out speed difference, ie engine running, gear selected but vehicle still stationary - it then "slips down" until (if) lock-up occurs.
 
Once it's in an array of floats it probably won't be hard to script around, still gotta try it later.

The question about the clutch I had is how to calculate the stall ratio (or speed difference) within the script. The transmission component is obviously fine, moves up and down the gears smoothly and all that jazz. Engine RPM is available too.

Also, what the max torque on the clutch should be in this situation - I guess the max torque output by the clutch is simply clutch_position*clutch.max_torque? So you set clutch.max_torque to 2x the engine's max torque, then clutch_position to 0.5, and you won't slip. Then when gears change, the torque converter multiplies torque, and clutch_position stays constant, so the engine is producing more than max_torque - but only cause it's able to slip.

Hrm... probably cut down on shift time, make sure the script is controlling the clutch position, and also tweaking max_torque depending on how much the engine revs past the clutch speed... then you get your load.

Looking at the output speed, the torque converter eliminates the gap in acceleration, and actually replaces it with a small surge - engine speed is greater than transmission speed, so the torque converter multiplies it up, until the wheels catch up to the engine or the engine slows down.

Tricky part there is that the load on the engine also needs to be increased, to "trick" it into slowing down. Not sure if the scripts can generate fake engine load?
 
Haha, try populating those tables :D

Just messing with a car right now and it's been a real bugger. Not sure if I've done something wrong, my code is a bit iffy, but it seems to work in higher gears, but the lower ones where road speed vs loads are bunched up it's getting in a fit bobbing up and down.

I started by going through each gear at 100% thottle to see where I wanted it to shift up, then down to about 1100rpm in each gear to set the down-shift speed that should always happen at 0% throttle.
Then I also set the shift down max speeds, so it wouldn't be a pointless down shift to shift into about 500rpm of acceleration, so I just revved to 5000rpm (6000rpm car), and used that speed for the next gear ups shift down max speed at 100% load.

It's just filling in between the end points. Stereos system makes more sense for now, probably just adding in those values per gear would be enough...

Tables seem heavy work to set up per car so far even! I'd say as you are mentioning above, that some logic to sense torque per gear possible (each side of current gear check?) and then determine the right gear for the current throttle % as a demand is the best route?

Ie, 50% throttle in 3rd, drop it to 25% throttle, check to see what 2nd 3rd and 4th gear torques would be @ wheels at that instant, and which value is closest to about 25% of the max torque - min torque value?!

Hmmm

Dave
 
I suspect the reason tables exist is cause that works :p if they'd found something else just as good, they would use it. Of course, we have a bit of an advantage in being able to test the torque curve in each gear since all the car's data has to be input anyway.
 
Yep, the tables work indeed.

I'm just worried about the set up time for users. Which ever way we end up going we'll have to write a decent FAQ because I for one was pulling my hair out trying to understand the logic and what the numbers I was actually putting into the table meant... they kinda don't make sense in a direct tangible thing, you only really get what they are doing while you drive around and feel them in action and feel the changes.

Also, my little tip so far, set up 1 > 2 first, get that feeling good. Then do 2 > 1, then get that feeling good. I've been populating the whole range with rough numbers so far and I've just had my car going all over the shop through the gears haha :D

Are you working on a table system Stereo? It sounds better to an array table as big as is felt necessary and work with that. Sounds intuitive for editing too!


Hence me just wondering about a sensing system method too... might tinker with that code a bit and see if anything starts to crystallise and make sense :D
I have a feeling it probably won't haha :)

Dave
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 77 7.3%
  • 75% online 25% offline

    Votes: 112 10.6%
  • 50% online 50% offline

    Votes: 153 14.5%
  • 25% online 75% offline

    Votes: 289 27.4%
  • 100% offline racing

    Votes: 419 39.8%
  • Something else, explain in comment

    Votes: 4 0.4%
Back
Top