Patch: Improved acceleration for road vehicles [In trunk]

[Terkhen]

I was referring only to vehicle weight. Since I was just checking for NewGRF compatibility and not for the actual realistic acceleration implementation (that will come later), I did not checked if TTDPatch takes into account cargo weight for all vehicles of the consist (but it is logical to assume that it does). The correct answer for my implementation is (3). The first part has the power, weight and tractive effort values for the complete vehicle. Every part (including the first one) can have a capacity. The weight of all cargo is taken into account to calculate the complete weight of the vehicle in a given moment.

Total weight = Weight of the vehicle (stored in the first part) + Weight of the cargo (sum of all parts)
Real tractive effort = (Weight of the vehicle + weight of cargo at the first part) * Tractive effort of the vehicle

[andythenorth]

Total weight = Weight of the vehicle (stored in the first part) + Weight of the cargo (sum of all parts)
Real tractive effort = (Weight of the vehicle + weight of cargo at the first part) * Tractive effort of the vehicle

OK, that makes sense. In my case it will mean changing some properties in code, but that's just work which is fine; I can't think of any actual implementation problems from the change.

[Terkhen]

Yet another update, but this is an important one

v5-r17214: More comments and code style corrections. Corrected the z coordinate in bridges and tunnels bug. Realistic acceleration for slopes works now. The acceleration part of the patch is still not tweaked, but it is complete.

I still need to play with the acceleration values a bit and add air drag, but besides that real testing can begin. I will implement air drag as hertogjan suggested: if not set by GRF the air drag value will depend on the vehicle's max speed. For rolling friction I will adapt Hirundo's solution: a different value for trams and trucks / buses.

[Comm Cody]

The Realistic Acceleration for slope causes some Vehicles slow down to 0MPH. I believe that for slopes, the minimum speed should be 5 mph. So the vehicle can tackle the slope.
Reported in Egrvts and HEQS.
Andy, this was with the Cascade Trucks.

[DaleStan]

1 mph (or, more likely, 1 <internalspeedunit>) is the TTDPatch minimum.

[peter1138]

I know you say it needs tweaking, but here are some comments:

Code: Select all

+	int speed = v->cur_speed * 5 >> 3; // km-ish/h -> mp/h

The train version uses "/ 16". Are you really bit-shifting instead? Also the comment is wrong.

Code: Select all

+			incl += u->rcache.cached_veh_weight * 15; // 3% slope, quite a bit actually

Quite a bit... for trains. Road vehicles can be expected to handle more, but maybe 3% is a good average? I'll assume the change from 60 to 15 is due to mass being measured in 1/4 tons.

Code: Select all

+	const int friction = 20; //[1e-3]

Rail vehicles have a friction coefficient of 35. Are you sure that road vehicles have *less* friction? Trams may have a similar value as for trains, otherwise it should be quite a bit more. Do we need to cater for the higher friction of big nobbly tyres as used off-road, for instance?

Code: Select all

+		this->u.road.tractive_effort = 0x4C;

Instead, please adjust the src/table/engines.h file in the same manner as trains. It's still a one-liner, but in the correct place.

Code: Select all

+			return (10 * this->GetDisplayWeight() * this->u.road.tractive_effort) >> 8;

What about Callback 36 support? That applies elsewhere too, I suppose.

It would also be nice to drop the "realistic" moniker, as, well... it's not. Many of the values chosen in the train version are only "roughly" right.

[andythenorth]

Rail vehicles have a friction coefficient of 35. Are you sure that road vehicles have *less* friction? Trams may have a similar value as for trains, otherwise it should be quite a bit more. Do we need to cater for the higher friction of big nobbly tyres as used off-road, for instance?

Coincidentally I just ran across this story:
http://www.roadtransport.com/blogs/big- ... e-wor.html
It puts the friction coefficient of rubber on steel of 0.9. That's only anecdotal, but it does indicate rubber tyred vehicles should have higher friction.

[FooBar]

Do we need to cater for the higher friction of big nobbly tyres as used off-road, for instance?

If there is such thing as 'off-road' in TTD, yes. Otherwise there's no point in equipping TTD vehicles with off-road tires.
Hides...

It would also be nice to drop the "realistic" moniker, as, well... it's not.

Suggestion: "Accelleration model: Less unrealistic".

[andythenorth]

If there is such thing as 'off-road' in TTD, yes. Otherwise there's no point in equipping TTD vehicles with off-road tires.Hides...

Well there is this...http://wiki.openttd.org/Peter1138/Roadtypes
Different TE coefficients for different roadtypes...or something? Dunno, I'm just, like some kind of GRF author
[ducks /]

[hertogjan]

The Realistic Acceleration for slope causes some Vehicles slow down to 0MPH. I believe that for slopes, the minimum speed should be 5 mph. So the vehicle can tackle the slope.
(...)

For your information, in my old patch, I did it as follows,

Code: Select all

if (mode == RVDM_ACCEL) {
	// Accelerate, but brake if speed is too high
	if (speed > max_speed + RV_SPEED_TOLERANCE_UP) {
		mode = RVDM_BRAKE;
	} else {
		accel = (traction + incl - resistance) * 4 / mass;
	}
	if (speed < 100 && accel < 0) {
		accel = 3000 / RV_ACCEL_MAGIC_CONSTANT;
		mode = RVDM_UNDERPOWERED;
	}
}

It works as follows: If the drive mode is set to accelerate (as opposed to braking or being stopped), and the vehicle is below its maximum speed, then first compute the acceleration by adding the forces, traction + inclination - resistance (inclination is for slopes, this may either be positive or negative depending on going down or up), and dividing it by the mass (in this example, mass is in units of 1/4 tons). If the speed is under a certain threshold value (here 100 units of cm/s, i.e. 1 m/s=3.6 km/h) and the acceleration is negative, then replace the acceleration by a preset value, to keep the vehicle moving. The line "mode = RVDM_UNDERPOWERED;" was useful for debugging, and to make sure that the rest of the acceleration function was skipped. If either of the two conditions is not met, then use the normal value of the acceleration.

For train physics, I also did something similar, but in a much more fancy way. Namely, if the train is underpowered, its acceleration was set to a value that was proportional to the difference of its speed and the threshold speed, but (in practice) always enough to keep it moving. This way I got a smoother behaviour.

[Terkhen]

Comm Cody: That bug has been added to the ToDo list. I will check the different solutions suggested to force a minimum speed. It needs to reflect that the vehicle can barely move at all, and to avoid that the vehicle becomes a wheeled wall in the middle of the road.

petern: Is there any problem with bit-shifting (besides making the code less understandable, but I can correct that with non-copypasted comments) that I am missing?. I converted (... * 10) / 16 into (... * 5) >> 3. I have the feeling that I am being really dense here but I don't know why

Your assumption about weight in the slope code is correct. I still have to do more tests, but it is the part I tested most while correcting bug and I find that this inclination value works good (with standard vehicles anyways). The friction value was changed while I was debugging some errors and I just left it that way before starting tweaking values. I don't know which would be a correct value: I still have to check some documentation about rolling friction, but I was thinking on implementing a different value for trams and another for bus / trucks and store it in the cache. I toyed with the idea of making it a NewGRF property, but then I thought that it would be more appropiate to make it dependent on the road type.

The suggested codechange for standard tractive effort will be implemented in v6.

Before removing the GetEngineProperty call from the road vehicle parts of GetPower, GetDisplayWeight and GetDisplayMaxTractiveEffort I checked at the properties supported for callback 36. Since callbacks for these properties are not implemented, I decided to remove the GetEngineProperty call. It will get back once I get more urgent features working and I finally start implementing callbacks for acceleration values.

About the "realistic" name... well, I actually preferred to call this feature "Improved acceleration" (as it is not realistic and neither it needs to be 100% realistic to meet my goal), but since it was called "realistic" for trains, I just followed the name convention. If "Improved acceleration" is preferred I will rename the patch gladly.

[Comm Cody]

Also the horse vehicles from Egrvts have 0 Hp, but have tractive effort?

[QtanJ]

Rail vehicles have a friction coefficient of 35. Are you sure that road vehicles have *less* friction? Trams may have a similar value as for trains, otherwise it should be quite a bit more. Do we need to cater for the higher friction of big nobbly tyres as used off-road, for instance?

Coincidentally I just ran across this story:
http://www.roadtransport.com/blogs/big- ... e-wor.html
It puts the friction coefficient of rubber on steel of 0.9. That's only anecdotal, but it does indicate rubber tyred vehicles should have higher friction.

You can't compare those numbers directly. I don't have time(nor knowledge) to explain the acceleration system for openttd from coefficients of friction(as this involves creating a real realistic acceleration system and simplify it) but I will try to explain some points:

1. We primarily accelerate by using friction. In terms of trucks and cars the friction between the wheel and the surface mostly points forwards when we are accelerating forwards. Try, using a car, to accelerate when the roads are icy or try to run on ice sometime. Can you accelerate as fast as on asphalt? No, you will not be able to get a good enough grip on the surface. The wheels will spin if you use a car and you will probably fall and hurt yourself if you try to run on the ice.

I am not saying all friction in a forwards-accelerating truck points forwards. The friction in the source code points backwards when accelerating forwards and there is a reason for that.

2. The wheel-to-ground friction is mostly the same as "force" in

Code: Select all

return (force - resistance) / (mass * 2);

Resistance does include other forms of friction(friction in axles for example). The constant named friction is actually a frequency, but a frequency which is used in calculating the friction force which is slowing the vehicle down.

Force equals mass times acceleration
F=m*a

Acceleration equals speed per time
a=v/t

frequency equals time^-1
f=1/t

Code: Select all

resistance += friction * mass * speed / 1000;

To figure out what friction is in this code and resistance is a force than friction needs to be a frequency.(I can prove it with equalations one step at a time another time if needed)


The constants area(120 vs 15) and friction(60 vs 20) works together. It's not important if resistance come from drag or friction. It's more important that the sum is approximately correct.

As "friction" is a frequency, and area and friction works together I am not sure whether it's less friction for these vehicles pr mass. If we should use friction coefficients directly than I believe we have to make a more comprex acceleration system.

*I hope I have made myself clear. I am not too sure though. English isn't my primary language and if this wasn't enough I might not have simplified my arguments enough.

[Terkhen]

Comm Cody: It seems that eGRTVS only has partial support for realistic acceleration. In the present version of the patch, a default value for tractive effort is set for all NewGRF vehicles. It was set to ensure that vehicles with only power and weight could move (I needed it to start testing). For the next version it will be removed as it is no longer needed.

About the friction coefficient: I don't know what should be proper values... Right now pre-v6 has 35 for trams (like trains) and 40 for road vehicles (because I didn't wanted it to become too important while testing the rest of components of resistance).

[peter1138]

http://en.wikipedia.org/wiki/Rolling_re ... t_examples

OpenTTD's value of 35 is related to some value between 0.0002 and 0.0010. Therefore the relevant figure for road vehicles, even trams, should be quite a bit higher.

[Terkhen]

I have taken the highest value for rails (0.001), and the lowest for trams (0.005) and trucks (0.006). With air drag disabled and using 35 * 6 as friction for road vehicles, not a single standard vehicle was able to reach its maximum speed (in the case of buses, they could barely reach half of their maximum). I will make road vehicle friction coefficient higher than the one for trains, but it seems like the increase can't be realistic.

[QtanJ]

I have taken the highest value for rails (0.001), and the lowest for trams (0.005) and trucks (0.006). With air drag disabled and using 35 * 6 as friction for road vehicles, not a single standard vehicle was able to reach its maximum speed (in the case of buses, they could barely reach half of their maximum). I will make road vehicle friction coefficient higher than the one for trains, but it seems like the increase can't be realistic.

From looking at the code some more I think I understand more. I think I have spotted an error. I did comment on it in my latest post, but I believe I concluded wrong.


The friction coefficient for trains is 0.035 in trunk as it is now. This could be 0.0010 for rolling friction pluss 0.0025 for axles(and possibly other things as well), but I am not sure.

F=Crr * N

F equals resistance force(Newton)
Crr equals friction coefficient(no unit)
N equals normal force which equals mg(newton)
m = mass(kg)
g = gravitational force(m/s^2)= 9.81(actually over 9.82 some places and below 9.81 other places)

Of course this is only correct when mass is in kg and force is in newton.

To take values from the source code:

resistance += friction * mass * speed / 1000;

F= "resistance +="
Crr= friction/1000
N != mass*speed (this is wrong if we use that formula from wikipedia.)
N= mass*9.81

If we assume the axles give the same friction than a friction value of 75-70 seems reasonable.

[Terkhen]

Version 6 can be found at the first post. Support for NewGRF air drag property has been added, and the acceleration function has been tweaked and now works as expected

Now the patch can be tested more seriously, because unless there is some problem or inconsistency in the acceleration function, its behaviour is finished.

v6-r17251:

• Almost all functions corrected and remade as class member functions.
• Force a minimum speed of 1 km/h.
• Default tractive effort is now set after loading NewGRFs.
• Different rolling friction coefficients for trams and trucks (Hirundo).
• Air drag behaviour changed to allow using NewGRF air drag.
• Standard air drag values added to the engine table.
• Tested that air drag is already read correctly from NewGRFs in trunk.
• If air drag is zero (or unset), the air drag value for the vehicle will be dependant on its speed checking a table. If air drag is one, it will be treated as "no air drag". This check is made after loading NewGRFs (Hertogjan).
• Air drag cached with small additions for each articulated part (1/16 of first vehicle's air drag)
• Acceleration function corrected and tweaked.

QtanJ: Thank you for your help with friction. Finally I settled for slightly lesser values than the suggested ones (40, 60), as they gave better results (I assumed that axles added less friction in trams/busses/trucks than in trains to justify these values).

andythenorth: Now that acceleration in slopes and friction are working correctly, the behaviour of HEQS vehicles has changed a lot when moving in rough terrain. A full loaded Kilimanjaro Unitised Mining Truck can cope with small slopes, but the Camelback Mountain gets to 1 km/h. I assume this is because I am still using a HEQS version that sets power in different parts of the articulated vehicle and now these multiple values are ignored.

Roujin: While testing air drag, I used the Hover bus a lot. Right now its air drag value is 24 (taken from the standard vehicle it replaces). The standard value it would get after looking at the table if air drag was set to zero (6) would allow it to reach its max speed (you can check this by changing the ID using the NewGRF parameter to a big enough ID to allow air drag to be unset). It still takes a lot of time to reach this speed with current values, though.

Everybody: What's your opinion on renaming the patch to "Improved acceleration"?. I'm asking because unless there's objections, this is exactly what I am going to do in v7.

[andythenorth]

andythenorth: Now that acceleration in slopes and friction are working correctly, the behaviour of HEQS vehicles has changed a lot when moving in rough terrain.

Ok, exciting I'll compile and have a look.

I don't mind what this feature ends up being called. Whatever produces least player confusion would be best

[Roujin]

Version 6 can be found at the first post. [...]

Congratulations

Roujin: While testing air drag, I used the Hover bus a lot. Right now its air drag value is 24 (taken from the standard vehicle it replaces). The standard value it would get after looking at the table if air drag was set to zero (6) would allow it to reach its max speed (you can check this by changing the ID using the NewGRF parameter to a big enough ID to allow air drag to be unset). It still takes a lot of time to reach this speed with current values, though.

Alright, I'll have a look and tweak it a bit.

Everybody: What's your opinion on renaming the patch to "Improved acceleration"?. I'm asking because unless there's objections, this is exactly what I am going to do in v7.

I'm fine with it and I guess the devs will like it more than "realistic" acceleration in any case.