Determining Steered Angle from Telemetry

Hi all,

I have started another little side project to see if I can take the Shared Memory telemetry from AMS2 and produce a MoTeC i2 log file. It's going ok so far, but I'm trying to take advantage of the oversteer math feature and not sure how to work out the Steered Angle that it uses. I'm not very au-fait with MoTeC and from what I can gather this is supposed to be the angle in degrees that the wheels are from directly ahead, which if that is correct, I'm struggling to find anything in the struct that corresponds to this value.

Does anyone know if it's possible to derive it from the telemetry or am I barking up the wrong tree?

Cheers!

 

If you are able to produce something that can be used in the free available MoteC i2 telemetry tool you will be my man.
Eventhough Im no fan of messing with the shared memory.

ByTheWay: AMS2 is more or less the only sim without a way to get a MoteC compatible output
And any who have used the real MoteC i2 does probably know how great this telemetry tool is.

 

well, it's all a bit rough and ready at the moment as it was intended more to be an educational exercise for me to learn about the telemetry and programming in python rather than be a practical tool, but you are welcome to play if you are looking for something to do and don't mind mucking around with python GitHub - GeekyDeaks/sim-to-motec: Simple scripts to convert sim telemetry to MoTeC log files

I'm still working out what metrics are available and what they really mean in relation to what MoTeC expects, the steered angle is one such example. There are also some quirks when dealing with in/out laps as well as off track moments or going into the pits that I still need to take a look at

 

If I understand correctly you have managed to get the game to output telemetry in the same way that has been done here:
AMS2 Telemetry CSV Writer
There are two steering signals, one is mSteering, the other is mUnfilteredSteering. I don't know if these names are given by the game itself or were given by the author of the program of the above thread, but assuming they are correct and that the order hasn't changed much (I think some values were added, DRS state iirc), then mSteering is the column after mClutch and before that there is mThrottle. I'm posting an example csv I fortunately have, since the program seems not to work anymore (probably the updates broke it)
Edit: I can't upload a CSV directly here, I can send it to you if you need it, please PM me if you are interested.
Edit 2: Values are very small, so I assume they are in radians rather than degrees.

 

Yeah, basically the same thing, the main difference is I'm outputting to the i2 log instead of a csv.

Right, so the names look the same as the struct elements in the SharedMemory.h I managed to find. There is a copy at sim-to-motec/SharedMemory.h at main · GeekyDeaks/sim-to-motec, but unfortunately, I forget where I originally got that from....

From what I can tell, both those measurements go from -1.0 to 1.0

Code:

float mSteering;   // [ RANGE = -1.0f->1.0f ]

I'm guessing it's the range of the steering wheel, but I'm not sure if it's the soft lock range or the full range. I'll check when I am on next. I"m actually using these measurements at the moment, but I have resorted to just picking an arbitrary multiplier to get the display in MoTeC matching my wheel inputs, which I suspect is a flawed approach.

 

I strongly suspect it's the steering range of the specific car you are driving, so if your steering wheel matches the in game steering, it's the "soft lock" out of the two.
For example karts have the smallest steering range, 180° I believe. When using the in-game "Telemetry HUD" the input shows that when the soft lock is reached, the input is at its max.
You could set this manually for every car, but I feel this is the wrong approach.

Tagging @Iko Rein @Matus Celko who worked on similar projects. Hopefully they can help out.
I really hope this project goes well! I would love to use i2 with AMS2.

 

It does seem to simply be the soft-lock. I have gone through the rest of the individual wheel variables and none of them seem to correspond with an angle or vector other than the Y component. Just multiplying mSteering by 40 to give a lock to lock of 80 deg, gives something sane for several cars like the Caterham, e.g.



but not for others like the F-Inter, which I'm guessing is simply down to the steering ratio, which does appear to be exposed to the custom FFB lua scripts.... so, now I'm looking to see if I can find that, but it also made me realise that MoTeC must also have a steering ratio setting for the vehicle that the gauge above uses, so I need to find that too.

More digging required, but does anyone know if it's possible to get the ratio from the FFB easily?

 

I'm not sure what you mean by "to be exposed to the custom FFB lua scripts"

Anyway, before finding the steer angle (to be clear, the angle of the front wheels), I would try to simply set a steering wheel angle channel as it is a helpful source of data for simple driving analyses, and also the most common and human-readable way. I understand steer angle is a more absolute measure, but we can always get that using the steering ratio by using math constants in Motec.
This can be only be achieved if we know the the steering wheel lock of the car.

I don't know if this can be done with an automated process that reads data from the game, but in case this wouldn't be possible, there's a handy list of info for every car here (look for the "Steering DOR" column). Maybe there is a way to recognise the car model and apply the correct steering lock when the data is recorded, or to pass this datum to Motec.

Even if any of this was not achievable, one could still have the steering channel as a percentage, and just show the original input, like in Tom Shane's pCars profiler. We could then manually add a math constant in i2 to show the actual steering angle.

Regarding the steering ratio, I couldn't find any explicit mention anywhere in the game or in the telemetry, but in the setup menu there's a "steering lock" setting that tells us how far the front wheels can steer in one direction. For example, the Caterham Academy has a default steer lock of 24°. Given that the steering wheel lock is 720°, this would give us a nice and neat 15:1 ratio.
I'm not sure this setup datum can be fetched in any way, but one can again manually input this into Motec. It should be noted that this setting can be changed, so having a static value somewhere could give an incorrect reading.

I hope any of this makes sense

 

That looks perfect chap! I'm already using lookup tables for other stuff, so this will be no different and for my own purposes I can override the ratio if I change the setup

 

I'd been looking for a way to identify and analyze under/oversteer occurrences with telemetry, and after becoming frustrated with other apps I came across your program @GeekyDeaks . I'm very impressed by it!

Has there been further development on the steering telemetry output since the discussion above from a few months ago? I'm using it in some formulas in Motec but results seem off, and improve when I scale the output to match the steering lock value in the vehicle settings.

At full lock with steering lock maxed in the vehicle settings to 28° in the few vehicles I've tested this on, the output to the Motec file is 40° steering from v1.5.3 - which is consistent with your comment here
I have used photomode to take a top down shot of the Formula Junior at full lock. It's a crude check, but good enough to convince me that the steered angle is < 40°.

If the vehicle setup steering lock is not accessible from shared memory, then as suggested in a previous post, I think the correct approach is to keep the mSteering in -1 to 1 range, and the user can define a constant or channel in a setup sheet in Motec for the steering lock to use as a multiplier in a maths expression. The output with 40x scaling already applied is misleading.

Thanks for the great tool!

 

Funny you should ask! I have been looking at it again recently as well as a few other metrics and came to a similar conclusion from the work @Racinglegend1234 has done on his MoTeC worksheet. I have some testing to do, but hope to be able to build a new release over the next few days.

 

would you be able to output the value as a property within simhub? it would be useful for shaker effects and dashes

 

His tool only works with MoTec so maybe the steering angle is a thing depending on the program used

 

Excellent!
I've done some testing myself since my last post. I took the source you shared on github and removed the 40x multiplier on mSteering in the ams2 logger.py. (other minor changes as well that I'll mention after)
I ran a couple laps with steering lock settings of 14°, 24° (default), and 28° in the Formula Junior. The unscaled mSteering values at full lock for each are ±0.51, ±0.88, and ±1.0 respectively. So based on this (limited) test, it seems the output of mSteering should be multiplied by the maximum available steering lock setting of the vehicle regardless of the actual setting. This returns ±14.28°, ±24.64°, and ±28° - not perfect, but then it's not apparent to me whether this is because there is some other factor not being accounted for that causes the small discrepancies for steering lock < 28°, or if this is just how the sim is coded.
Screenshot from Motec below for a section of each outlap as I left the garage and went lock to lock. Note that I have inverted the sign of mSteering in the top graph so it plays nice in other formulas I'm using it in.


I'm using this to check the angle of the front wheels and compare with the required steering angle of an ideal neutral steering vehicle on the same path (Ackermann angle) as described here. A large divergence of those values indicates under or oversteer.
For a slow lap with minimal tire slip, and with a scale factor of 28 on the steered angle output per above, these series are in agreement. This gives me confidence that the scaling is correct.

Faster lap with some slip to show that they may diverge:



I mentioned that I've made some other changes also:
I'm not much of a programmer but I was able to modify logger.py and channels.py following other examples in your code to get the individual wheel speeds from mTyreRPS output to Motec. This output does already appear to be in -km/h, not rps as suggested by SharedMemory.h (I'm unsure if this conversion is elsewhere within your program or performed by the sim) and there is some further scaling needed to have it match the ground speed perfectly, probably as a function of tire diameters. Anyways, I would like to request this is added to a future release also as it is a very useful metric.

Wheel speeds for the faster lap that was shown above, with sign already inverted in a Motec expression. On straights the front and rear speeds should be equal to the Corr speed trace so there is some further scaling needed, especially at the rear in this example.


EDIT: it was purely coincidental that the mTyreRPS values appeared to be in -km/h. The proper units are -rad/s as discussed in post #25

 

You guys are great.
But would this project end up with a nice little app that can save the telemetry output from AMS2 in a nice little file in the MoteC i2 format?
So I will be able to use some of my MoteC worksheets again - without having to fiddle with some .py files and some Proton coding and what-have-we.

ByTheWay: Oh man creating slightly advanced MoteC worksheets is enough for me.
No fiddling with you guys Python thing needed.

 

My workbook will be added to the GitHub page as a good base so if there is anything you want me to add then just PM me and I can add it

 

It auto saves data into a MoTec log file so you can access it in MoTec without any hassle

 

@ GeekyDeaks
Sorry to post this support request in the public forum.
I'm getting [Errno 13] Permission denied while running your app both in AMS2 v1.4.8.1 and AMS2 Beta v1.5.0.0
What am I doing wrong?

 

Run it in administrator, it made it work for me

 

Forgot to say, running in administrator mode.