Post #5, paragraph 3. Not the full specs, but "my computer is so old it only has two cores".
Very, very interesting to read Scawen, for those of us interested in the technical detail.
Please do continue.
Please do continue.
Hi.
Have you considered using the telemetry API to help you with this? There's no reason why you can't combine use of Insim and the telemetry API in a single program.
Use IndexedDistance and watch for the first zero crossing. You will need to use interpolation and knowledge of the track length to compute the exact lap start time. Linear interpolation works well enough in my experience, though there are more advanced possibilities if there is significant vehicle acceleration/deceleration across the start/finish line.
I haven't tried this personally in LFS, but I used this technique when developing a telemetry add on for Grand Prix Legends (GPL). In principle, it should work with any sim.
Hope the idea helps.
Have you considered using the telemetry API to help you with this? There's no reason why you can't combine use of Insim and the telemetry API in a single program.
Use IndexedDistance and watch for the first zero crossing. You will need to use interpolation and knowledge of the track length to compute the exact lap start time. Linear interpolation works well enough in my experience, though there are more advanced possibilities if there is significant vehicle acceleration/deceleration across the start/finish line.
I haven't tried this personally in LFS, but I used this technique when developing a telemetry add on for Grand Prix Legends (GPL). In principle, it should work with any sim.
Hope the idea helps.
Last edited by Johnners, .
Wheelbase, tracks and wheel/tyre sizes can be recovered from Car_Info.bin. See my post #5 in the live telemetry thread.
Body dimensions, I don't know.
Body dimensions, I don't know.
Yes, that's correct.
For the OSWheels[4] array of OutSimWheel structs, the indexing is 0 = LR, 1 = RR, 2 = LF, 3 = RF.
For the OSWheels[4] array of OutSimWheel structs, the indexing is 0 = LR, 1 = RR, 2 = LF, 3 = RF.
Here's the C++ source code for my telemetry program, for any C/C++ developers that would like to experiment with using it and perhaps as a starting point or a source of ideas for their own projects.
I developed this on Windows 10 Home 64-bit using Visual Studio Community 2015. It is intended to be compiled as a console program. When run from a command prompt it will listen for an active LFS session and UDP stream. It will then generate a CSV file rendering of the telemetry stream for the duration of the session. Fair warning - the CSV files can grow very large.
The CSV file format used is generic and designed to be used with multiple current generation sims, including LFS. (Yes, I regard LFS as a current-generation sim, in terms of the quality of its physics implementation.) The generic file format currently provides for a total of 176 channels, but note that any one sim (including LFS) populates only a subset of the available channels, i.e. no single sim provides everything.
This tool is part of a larger project directed at physics benchmarking of multiple sims, my primary telemetry focus. This is in contrast to most telemetry specialists, who direct their work primarily at driver performance analysis and setup development.
See the source code comments for more details about the utility and the telemetry file naming convention used. The first two rows of the CSV file are headers which define the channel names (row 1) and the units of measure (row 2); these are also reflected in the source code comments. The header rows are compatible with McLaren Atlas Express, my preferred telemetry analysis tool.
In addition to the CSV output file, the utility generates a binary (.bin) file containing a verbatim rendering of the UDP packets; this is very useful when studying the UDP packets in detail and I used it heavily while developing the utility. See also my earlier annotated OutSim Format document, which is helpful when inspecting the content using a hex editor, for example.
As currently implemented, the code that generates the computed slip angle channels (83-88) contains various hard-coded parameters reflecting an MRT5 running the default setup. These will need to be adjusted for other cars and setups. Yes, messy I know, but this is essentially a proof of concept at this stage. The computations are based on a technique originally developed by Todd Wasson, who used to be a very active forum contributor both here and in iRacing. I can give more detail on how the computation works if anybody is interested, but it's not actually needed for studying LFS telemetry because Scawen has so kindly chosen to make slip angles directly accessible to us! I use it in sims that do not directly report slip angles in order to generate useful estimates.
Channel 52 (steering wheel angle) also contains a hard-coding (steering ratio). There might be one or two others I have forgotten, but hopefully they will be fairly obvious in the source code.
The target sims for my larger project are iRacing (using Atlas with native iRacing binary telemetry (IBT) files), LFS, rFactor2, AMS1 and RRE. I may extend the list over time, with Assetto Corsa and ACC being the most likely additions.
I developed this on Windows 10 Home 64-bit using Visual Studio Community 2015. It is intended to be compiled as a console program. When run from a command prompt it will listen for an active LFS session and UDP stream. It will then generate a CSV file rendering of the telemetry stream for the duration of the session. Fair warning - the CSV files can grow very large.
The CSV file format used is generic and designed to be used with multiple current generation sims, including LFS. (Yes, I regard LFS as a current-generation sim, in terms of the quality of its physics implementation.) The generic file format currently provides for a total of 176 channels, but note that any one sim (including LFS) populates only a subset of the available channels, i.e. no single sim provides everything.
This tool is part of a larger project directed at physics benchmarking of multiple sims, my primary telemetry focus. This is in contrast to most telemetry specialists, who direct their work primarily at driver performance analysis and setup development.
See the source code comments for more details about the utility and the telemetry file naming convention used. The first two rows of the CSV file are headers which define the channel names (row 1) and the units of measure (row 2); these are also reflected in the source code comments. The header rows are compatible with McLaren Atlas Express, my preferred telemetry analysis tool.
In addition to the CSV output file, the utility generates a binary (.bin) file containing a verbatim rendering of the UDP packets; this is very useful when studying the UDP packets in detail and I used it heavily while developing the utility. See also my earlier annotated OutSim Format document, which is helpful when inspecting the content using a hex editor, for example.
As currently implemented, the code that generates the computed slip angle channels (83-88) contains various hard-coded parameters reflecting an MRT5 running the default setup. These will need to be adjusted for other cars and setups. Yes, messy I know, but this is essentially a proof of concept at this stage. The computations are based on a technique originally developed by Todd Wasson, who used to be a very active forum contributor both here and in iRacing. I can give more detail on how the computation works if anybody is interested, but it's not actually needed for studying LFS telemetry because Scawen has so kindly chosen to make slip angles directly accessible to us! I use it in sims that do not directly report slip angles in order to generate useful estimates.
Channel 52 (steering wheel angle) also contains a hard-coding (steering ratio). There might be one or two others I have forgotten, but hopefully they will be fairly obvious in the source code.
The target sims for my larger project are iRacing (using Atlas with native iRacing binary telemetry (IBT) files), LFS, rFactor2, AMS1 and RRE. I may extend the list over time, with Assetto Corsa and ACC being the most likely additions.
Last edited by Johnners, .
Generally, through sophisticated prediction code.
Taking iRacing as an example, it runs a simplified remote client physics engine on the local client to predict the positions of remote client cars. When it receives remote client positional and steering input updates from the server in a sufficiently timely fashion, these are passed into the remote client physics engine and factored alongside such considerations as track geometry and typical driving line. Although simplified, there's quite a lot factored in that engine; it has been steadily improved over time.
For iRacing, the default is to retrospectively patch remote client positions in the replay files, provided that the required (frame reference) server packet is received within one second or so of realtime, otherwise the patching code gives up and the predicted position is retained in the replay. The default can be changed to switch patching off, in which case the replay will replicate what was seen by the local client driver during the live race, i.e. with all remote client car positions from the prediction code. Some drivers prefer this, but it generally leads to less smooth animation when viewing replays; patched replays are generally smoother and that's one of the reasons that feature was implemented as the default.
Dealing with latency and packet loss is a very hard software engineering problem and there are many performance trade-offs and challenges, as Scawen has already noted. Current sims are generally much better at this than older generation sims, e.g. Grand Prix Legends, to choose a random example.
Last edited by Johnners, .
My understanding is that LFS generates its engine sounds synthetically and does not use a sample-based approach, therefore as far as I'm aware there are no engine sound modding capabilities.
Another screenshot showing more of the tyre telemetry.
Side by slide plots from two laps through the final few corners of Fern Bay Club in the MRT5.
In lap 1 on the left, I took too much kerb through one corner and had a series of three massive oversteer events.
In lap 2 on the right, I got through without drama.
From top to bottom, the sub-plots are:
- Slip angles plus steering wheel angle (dotted orange).
- Slip fraction (narrow plot).
- Touching (narrow plot).
- Lateral forces.
- Vertical loads.
Side by slide plots from two laps through the final few corners of Fern Bay Club in the MRT5.
In lap 1 on the left, I took too much kerb through one corner and had a series of three massive oversteer events.
In lap 2 on the right, I got through without drama.
From top to bottom, the sub-plots are:
- Slip angles plus steering wheel angle (dotted orange).
- Slip fraction (narrow plot).
- Touching (narrow plot).
- Lateral forces.
- Vertical loads.
Excellent!
The potential trap is the axis system convention. LFS convention is different to that used in the Wikipedia article, so it is essential to re-order the Euler angles accordingly when implementing that formula. I botched it on my first attempt!
Of course, happy to help, coded in C++.
X rotation = Pitch
Y rotation = Roll
Z rotation = Yaw
Positive = counter-clockwise, looking inward along the positive axis toward the axis origin.
And two examples of calling the function:
X rotation = Pitch
Y rotation = Roll
Z rotation = Yaw
Positive = counter-clockwise, looking inward along the positive axis toward the axis origin.
Vector World2Local(Vector WorldVector, float Pitch, float Roll, float Yaw)
//
// Function to transform WorldVector to LocalVector using the Euler angles and
// 3D affine transformation. Uses the 3x3 matrix form because only rotation is
// required (no translation).
//
{
Vector LocalVector;
// Total rotation matrix row 1 * WorldVector
LocalVector.X = cosf(Roll)*cosf(Yaw)*WorldVector.X \
+ (cosf(Pitch)*sinf(Yaw) + sinf(Pitch)*sinf(Roll)*cosf(Yaw))*WorldVector.Y \
+ (sinf(Pitch)*sinf(Yaw) - cosf(Pitch)*sinf(Roll)*cosf(Yaw))*WorldVector.Z;
// Total rotation matrix row 2 * WorldVector
LocalVector.Y = -cosf(Roll)*sinf(Yaw)*WorldVector.X \
+ (cosf(Pitch)*cosf(Yaw) - sinf(Pitch)*sinf(Roll)*sinf(Yaw))*WorldVector.Y \
+ (sinf(Pitch)*cosf(Yaw) + cosf(Pitch)*sinf(Roll)*sinf(Yaw))*WorldVector.Z;
// Total rotation matrix row 3 * WorldVector
LocalVector.Z = sinf(Roll)*WorldVector.X \
- sinf(Pitch)*cosf(Roll)*WorldVector.Y \
+ cosf(Pitch)*cosf(Roll)*WorldVector.Z;
return LocalVector;
}And two examples of calling the function:
// Transform linear velocity and acceleration vectors from world coordinate
// system to vehicle coordinate system.
LocalVel = World2Local(packet.OSMain.Vel, \
packet.OSMain.Pitch, packet.OSMain.Roll, packet.OSMain.Heading);
LocalAccel = World2Local(packet.OSMain.Accel, \
packet.OSMain.Pitch, packet.OSMain.Roll, packet.OSMain.Heading);
Last edited by Johnners, .
No worries Scawen, I was being lazy when I asked them. They were easily answered by paying full attention to the telemetry data and your documentation while I developed my program.
Here's an example plot produced using McLaren ATLAS Express and a CSV file generated using the OutSim data:
- Top area shows the sim-reported slip angles.
- Middle area shows steering wheel angle (solid orange) and car yaw angle (dotted orange).
- Bottom area shows slip angles computed using a technique originally developed by Todd Wasson, which is useful for sims that don't directly report slip angles in their telemetry stream. Two values are shown per tyre, one (name suffix CSV) was computed in real time during telemetry capture and the other computed offline during the Atlas session.
Vehicle is the MRT5 driven at the skid pad. It's initially driving a counter-clockwise lap on the 100 meter diameter circle, then it does a fast full left lock turnaround, rejoins the circle and continues on a clockwise lap.
Also attached are annotated copies of the OutSimPack and Car_info.bin documentation showing base addresses for all the data items, which I found very helpful when developing my telemetry capture program.
This is a great piece of work Scawen. Many thanks for releasing it to us.
- Top area shows the sim-reported slip angles.
- Middle area shows steering wheel angle (solid orange) and car yaw angle (dotted orange).
- Bottom area shows slip angles computed using a technique originally developed by Todd Wasson, which is useful for sims that don't directly report slip angles in their telemetry stream. Two values are shown per tyre, one (name suffix CSV) was computed in real time during telemetry capture and the other computed offline during the Atlas session.
Vehicle is the MRT5 driven at the skid pad. It's initially driving a counter-clockwise lap on the 100 meter diameter circle, then it does a fast full left lock turnaround, rejoins the circle and continues on a clockwise lap.
Also attached are annotated copies of the OutSimPack and Car_info.bin documentation showing base addresses for all the data items, which I found very helpful when developing my telemetry capture program.
This is a great piece of work Scawen. Many thanks for releasing it to us.
Last edited by Johnners, .
Fascinating viewing.
Mathias Müller's home page: https://matthias-research.github.io/pages/index.html
See top paper in Publications.
See also the n-pendulum simulation in Challenges.
Mathias Müller's home page: https://matthias-research.github.io/pages/index.html
See top paper in Publications.
See also the n-pendulum simulation in Challenges.
(Edit - Answered my own questions while trying this out.)
Nice implementation, works very well. Love that you have wheel steer angles, forces, loads and slip angles directly available. I would like to see this level of telemetry detail available in all serious sims. rFactor 2, RRE and AMS1 have some but not all of this data.
Which coordinate systems are used for distances/velocities/accelerations (world or vehicle)?
Answer - world coordinates. Use Euler angles and the general rotation matrix to get the vehicle equivalents:
https://en.wikipedia.org/wiki/ ... _matrix#General_rotations
Is the telemetry streamed only to UDP or are there options to save to disk?
Answer - UDP only, but it's easy enough to write a program to write to disk as binary data, CSV etc.
In CAR_info.bin, is "parallel steer" reflecting Ackermann factor? If so, can you give more detail on the value derivation please, including for anti-Ackermann?
Answer - Yes, 1 = parallel steer.
Are the OutSimPack.h comments for Pitch and Roll correct?
Answer - Yes. LFS axis convention is X = right, Y = forward.
My suggestions for additions:
- Power at current engine speed.
- Torque at current engine speed/throttle.
- Tyre contact patch velocities.
Nice implementation, works very well. Love that you have wheel steer angles, forces, loads and slip angles directly available. I would like to see this level of telemetry detail available in all serious sims. rFactor 2, RRE and AMS1 have some but not all of this data.
Which coordinate systems are used for distances/velocities/accelerations (world or vehicle)?
Answer - world coordinates. Use Euler angles and the general rotation matrix to get the vehicle equivalents:
https://en.wikipedia.org/wiki/ ... _matrix#General_rotations
Is the telemetry streamed only to UDP or are there options to save to disk?
Answer - UDP only, but it's easy enough to write a program to write to disk as binary data, CSV etc.
In CAR_info.bin, is "parallel steer" reflecting Ackermann factor? If so, can you give more detail on the value derivation please, including for anti-Ackermann?
Answer - Yes, 1 = parallel steer.
Are the OutSimPack.h comments for Pitch and Roll correct?
Answer - Yes. LFS axis convention is X = right, Y = forward.
My suggestions for additions:
- Power at current engine speed.
- Torque at current engine speed/throttle.
- Tyre contact patch velocities.
Last edited by Johnners, .
FGED GREDG RDFGDR GSFDG