Determining Steered Angle from Telemetry

Yeah I had that issue today again. Just restarting the pc helped, but I think @GeekyDeaks will fix this issue. It also has issues when you press the stop button instead of leaving the session or going into the pits

 

Well, as it happens this also one of the things I was going to add! . I'm going to have to go back and review my tests again as I assumed it was RPS, but that was because I thought I was working in MPH and the numbers are very similar if you assume a wheel diameter of about 650mm. KPH is a completely different value though, so you may well be right.... however the fact that the rear and front are not the same suggests it could really be RPS and the rears are a different diameter to the front. More testing required!

 

ok, I'll have a look at the logs later when I get some free time. To be honest I'm not comfortable with people running things in admin mode anyway, so I'd like to get to the bottom of it, or maybe do a check when the app starts that it has correct permissions.

 

You’ve maybe found someone who can help you more than what I can

 

Glad to hear it!

If it is in rps then Reiza must've coded all the cars as if they have shopping cart casters for wheels

The wheel speeds are given in radians per second, I'm convinced. The revolutions per second indicated in the SharedMemory.h is a mistake, and it was only coincidental that my first test with the Formula Junior appeared to correlate in km/h. I've tested with several vehicles with varying tire diameters: G40 Cup, G55 Cup, 911 GT3, Formula Junior.
With the first three vehicles I converted from -rad/s to km/h using the tire diameters here and compared the output for a slow clean outlap to the ground speed. Example below for the 911 GT3, but they all had this level of agreement:

Because it's new the Formula Junior is not present in the car info sheet, but I worked backwards to tire diameters of 547mm up front and 584mm at the rear which seems very plausible and results in the following:

 

Please give SimHub-Plugin-CalcLngWheelSlip a try to get precise readings of tyre diameters (and much more).
Unless Reiza updated F-Junior in the RC, tyre diameters are 549 / 599 mm.

PS: Confirmed, F-Junior tyre diameters are 549 / 599 mm also in RC
PS2: Yes, rps from telemetry is in rad/s
This is a little spreadsheet I made some months ago to confirm accuracy of viper4gh's plugin

 

- it was just me - I had accidentally commented out part of the metric/imperial logic during my test and hadn't realised I was actually reporting kph rather than mph

Makes total sense, especially looking at the plugin by viper4gh that @newtonpg gave details for. I'll update the units to report rad/s so we can calculate the correct values in i2

 

very cool @newtonpg . I don't delve much into simhub because I use VR and generally try to avoid overlays of any kind, but this looks useful for those occasions when gathering car parameters. I'll take a look at the code to see what they're doing (if I'm able to follow it - big if) and why I haven't calculated the same rear diameter for the FJunior. Thanks for sharing the spreadsheet as well.

 

Is it possible to integrate some of those equations into a workbook?

 

I'll try my best to answer while viper4gh is the author/developer of the plugin.

Programing expressions in SimHub can be easily done binding properties in JavaScript or in its internal variant NCalc but SimHub can't directly store values for "future" use. What you can do to surpass is create a "root" variable for some restricted use in the near future or (and that is the function of the plugin) create a reference entry to store the calculated tyre diameters, now since v1.3.3 using (and appending) a look up json table included in the installation files.

The plugin then calculates longitudinal tyre slip or locking (%) by comparing car speed against tangential tyre speed. This is useful to show on-screen tyre locking (or slipping) and help to setup brake pressure and brake balance to optimum levels. It also permits to interpret differential opening if you consider 15% as a limit to differentiating in the traction axle.

I'm gradually returning to MoTeC after years and in need to re-learn how to program a workbook (worksheet by the time I used it). So the broad answer to your question is Yes, you can but not in a trivial work. You'll need to store a tyre diameter table and make it usable by MoTeC the same way you maybe store and read wheelbase.

I've installed a very detailed workbook by stevendaniluk for iRacing and ACC, just to help my son. You can grab it at GitHub and adapt some of their nice features to AMS2.

Note: Tyre slip in AMS2 Telemetry is referred by Reiza as obsolete and give absolutely unusable results as longitudinal tyre slip (maybe they're in some combined lat vs long slip, I don't know).

 

Oh wait. Are you the author of that repo? If so,@Racinglegend1234 has already been taking your work and tweaking it for AMS2.

I have to confess, I think I had completely missed the point of what he was trying to do (my apologies @Racinglegend1234 ), and was purely focused on getting channel names that matched the default circuit workspace and some live i2 log files I managed to get hold of. I am wondering now if it would be better overall to change the channel names to match those expected by your workbooks as it might avoid some unnecessary work.

 

Sorry but I'm not the author and have edited my post just before you quoted me.
The author is Steven Daniluk and you can follow him at GitHub.

 

I would think it’s easier if you keep the naming the same and upload my workbook. Then if someone wants to add something, they can do it themselves or they can tell me so I can do it

 

@GeekyDeaks
Thank you for the Sim-to-motec v1.6.0. It is working flawless.
Now I have a lot to (re)learn MoTeC

 

Ah now I see! You're using Extended Car Info by Coanda as a reference for tyre diameters BUT those diameters used by RST (RacingSimTools Telemetry) for some reason they differ from the calculated tyre diameters using SecondMonitor and also SimHub with viper's plugin.
Accurate tyre diameters are part of the installation files of viper4gh plugin as json file (uploaded here).

PS: No criticism to RST software, I am a very very happy user of the app!

 

Yes, I was using RST (and Second Monitor) until I came across @GeekyDeaks project. For most practical purposes I find those tyre diameters are close enough, or require only minor tweaks to clean up the traces.

I think things are sufficiently understood now with version 1.6 that you can get the oversteer expression working with a bit of manipulation of channel names.
But personally, since we can get the body yaw rate from shared memory (the Y component of mAngularVelocity, 'avy' in shmem.py), I prefer to compare this to the angular rate around the origin of a corner calculated by:

Code:

Angular Velocity [rad/s] = Lateral G [m/s/s] / Velocity [m/s]

Oversteer occurs when the yaw rate exceeds the angular rate. Example below with the Formula Junior for an intentionally drifty run through Turn 1 at Oulton Park. I'm using a modified version of the 1.6.0 source code to get the mAngularVelocity output in Motec.

Summary:

• corner entry, 140m to 200m:
  • wheel speed traces are showing moderate slip under braking on corner entry, moreso on the inside (right) wheels as steering is added at 180m
  • On the 3rd chart the body yaw (red trace) increases more rapidly than the angular velocity (green trace). Oversteer
• mid corner, 220m to 250m (cursor location):
  • brakes are being released and opposite steering lock is applied
  • the yaw rate is greater than angular velocity, but slowly converging and wheel slip is decreasing
• mid corner, 250m (cursor location) to 320m:
  • playing with the throttle and steering to match the yaw and angular velocity
  • as throttle is increased > 50% the rear wheels start to spin up, inner moreso than the outer
• corner exit phase, ~320m to 380m:
  • counter steering reduced and the yaw rate reverses to bring the angular velocity back to 0. As this happens the rear wheels grip up
  • I overcorrect with the steering slightly and get a small wobble out of the corner, visible as the damped oscillating patterns in the yaw and angular velocity traces

• The purple trace in the lowest chart is the derivative of (Yaw - Angular Velocity)
  • when the derivative is positive and increasing it indicates oversteer, and negative and decreasing indicates understeer.
  • Positive and decreasing or negative and increasing both indicate a correction happening to stabilize the vehicle at a new angular velocity.
  • Some amount of oversteer and understeer is ok in the corner entry and exit phases to cause the angular velocity to change. Note that everything in this example is exaggerated, and made weirder by the large counter steering angle required.

 

MoTec also has their own ways of calculating oversteer

 

I fully agree and can confirm that the slip values from the AMS2 Shared Memory API are useless.
That was the cause why I wrote the Simhub plugin which uses the TyreRPS (and yes, they are in radians per second) values to calculate the tyre surface speed (where the tyre diameters are needed) and compare it with the car speed, which results in definitively better usable values.
The last Release of the CalcLngWheelSlip plugin includes a lot of tyre diameters (thanks to @newtonpg again), but there are still many missing.

@GeekyDeaks
Great work with the Log Recorder, I think I used MoTec i2 the last time for the GTR titles and maybe Race07. I will give it a try, thanks.

 

I know this is old, but I looked into this for another project and found that multiplying mSteering by 27.5 seemed to match up with the expected steering lock angle values.

My method of testing was to select a steering lock then log the maximum extent of steering by turning until wheel lock.

Example:

• Select 16 degrees for the steering lock on a car
• Turn the wheel until it stops and make note of the mSteering value
• Divide the steering lock angle (16) by the reported mSteering value and get the multiplier

I repeated the process for half a dozen values or so across 3 cars. They all reported 27.5 as the multiplier. Also, rounding to 4 decimal places seemed to be better since we are working with such small numbers. The tricky part would be verifying this against cars that cannot have their steering lock adjusted such as Cross Karts. I am not sure if this is useful, but thought it might be worth mentioning.

 

@Nainkaigo Hope this can help you
AMS2 car parameters
Steering lock angles were obtained using an app (Angulus) with my cellphone