The online racing simulator
OutSimPack Help
(13 posts, started )
OutSimPack Help
You've probably stumbled across my AIRS project thread by now, but now I need some help, and I figured it would be best to isolate it for others. I've searched up and down, and found several posts including the OutSimPack that I am trying to handle. I have many questions that I have yet to find documented anywhere.

Accel I had an assumption based on the lack of documentation that this would provide numbers in terms of acceleration in Gs. So if I got

Accel.x = 0.5; Accel.y = 0.2; Accel.z = 0.0;

it would mean the car is turning to the left and accelerating. Or something along those lines. However, the range is not 1 = 1G of acceleration. I have no idea what the scale is, but I simply divided by 9.81 and it still seems to work, but I'd like to confirm this fact somewhere.

The more important issue is the numbers seem to be in world space, so with the numbers provided above, it could actually mean the car is accelerating very hard and turning a little. I tried to convert this into car space, and have so far had no luck. I'm looking to get the seat of the pants feeling for the ai driver.

Any one have more information on this?

Image of issue

Notice the G force gauge in LFS shows 0.67g forward and 0.01g left. Yet my display shows more left than forward.


const OutSimPack& msg(InterpretAs<OutSimPack>(data, dataLength)); //msg is the OutSimPack
const float kOneGravity(9.81f);

GameMath::Vector3 carDirection(LiveForSpeed::ConvertHeadingToForward(msg.Heading));
GameMath::Vector3 carUp(LiveForSpeed::ConvertPitchToUp(msg.Pitch));
GameMath::Vector3 carRight(carDirection ^ carUp); //Vector Cross Product

//Note the y/z is swapped on purpose. In my 'world' Y is up and Z is forward.
//The drawing code ignores the vertical acceleration, using only forward and right.
GameMath::Vector3 carAcceleration(msg.Accel.x / kOneGravity, msg.Accel.z / kOneGravity, msg.Accel.y / kOneGravity);
GameMath::Vector3 carSpaceAcceleration(carAcceleration * carRight, carAcceleration * carUp, carAcceleration * carDirection);
lfsScanner->SetCarAcceleration(driverCarIndex, carSpaceAcceleration);


GameMath::Vector3 LiveForSpeed::ConvertHeadingToForward(const float lfsHeading)
{ //angle 0 = 0* = (0,0,1) lfs = anticlockwise from above (Z)
float angleInRadians = GameMath::Convert::DegreesToRadians((lfsHeading));
GameMath::Vector3 forward(sin(angleInRadians), 0.0f, cos(angleInRadians));
GameMath::Vector3Normalize(&forward, &forward);
return forward;
}

GameMath::Vector3 LiveForSpeed::ConvertPitchToUp(const float lfsPitch)
{ //angle 0 = 0* = (0,1,0) anticlockwise from right (X)
float angleInRadians = GameMath::Convert::DegreesToRadians((lfsPitch));
GameMath::Vector3 up(0.0f, cos(angleInRadians), sin(angleInRadians));
GameMath::Vector3Normalize(&up, &up);
return up;
}

I've solved most of my matter. It seems I was wrong, and not sure how I came to that conclusion, about the input of the lfsHeading/Pitch variables; they are already in Radians, amd don't need to be converted. I guess I assumed based on the lfsAngle used in the MCI update packets.

I still don't have a documented way to know the values from .Accel are in meters/second/second, though I've assumed this for the time being. Can anyone verify that?

The fixed code (in case anyone is interested in using this thread for future) help is:


GameMath::Vector3 LiveForSpeed::ConvertHeadingToForward(const float lfsHeading)
{ //angle 0 = 0* = (0,0,1) lfs = anticlockwise from above (Z)
float angleInRadians = lfsHeading;
GameMath::Vector3 forward(sin(angleInRadians), 0.0f, cos(angleInRadians));
GameMath::Vector3Normalize(&forward, &forward);
return forward;
}

GameMath::Vector3 LiveForSpeed::ConvertPitchToUp(const float lfsPitch)
{ //angle 0 = 0* = (0,1,0) anticlockwise from right (X)
float angleInRadians = lfsPitch;
GameMath::Vector3 up(0.0f, cos(angleInRadians), sin(angleInRadians));
GameMath::Vector3Normalize(&up, &up);
return up;
}

I haven't seen any documentation to confirm other than the only other acceleration values mentioned in insim.txt are m/s^2 (in CarContact).
However, I also tried dividing by 9.81 and the outputs seem to match the G-Forces displayed in the in-game F9 view perfectly.

So, no documented proof, but I don't know what other unit they could possibly be.
Have you tried looking at them in LFS Units/s/s? So 65536 Units = 1m?

I don't have a easy way to check, but It's worth a shot. Someone else who may know is PeriSoft. He usually hangs around in the #liveforspeed IRC channel between 8-5 PM EST on weekdays.
dawesdust_12, that would have been my thought if it was the Vec (3 ints). But it is the Vector (3 floats) and those are usually either 1 unit = 1 meter, or described. I do believe I'm getting the correct values by dividing by the gravity constant, at least they seem to match my expectations.


What I am having a problem with, and this might be elsewhere in my code, is if I set the car forwardDirection based on the Heading of this packet, it seems to travel in unexpected ways. To solve this I've simply continued using the position/heading of the MCI packet, which was working. But it makes me wonder if something I did in the above is wrong. I will investigate more at a far later date and try to post any differences.

For now, back to work.
Quote from blackbird04217 :
What I am having a problem with, and this might be elsewhere in my code, is if I set the car forwardDirection based on the Heading of this packet, it seems to travel in unexpected ways. To solve this I've simply continued using the position/heading of the MCI packet, which was working. But it makes me wonder if something I did in the above is wrong.

The InSim (CompCar/MCI) Heading is an integer range with zero looking down Y+ and 16384 looking down Y-
OutSim Heading isn't really a heading at all; it's a float representing radians left (positive value) or right (negative value) of the Y+ axis.

If you convert them both to degrees:
Between 0 and 180 degrees they're identical
InSim 181 = OutSim -179
InSim 359 = OutSim -1

If you want them both the same:

<?php 
if (OutSim_deg 0OutSim_deg += 360
or
if (
OutSim_rad 0OutSim_rad += 2*PI
?>


Ooh, that might explain it then. I feel it is sort of a strange to give the heading in two completely different ways, but I will give this a shot this weekend when I have more time to work on the project and will certainly update as it will probably help.
Okay, I'm having some troubles again, with this exact packet. Not exactly sure anymore and I feel it is a little less documented than it could/should be - especially if people are using it for motion sensors.

Is OutSimPack.Accel in world coordinate space, or local to the car. Originally I had evidence to suggest it was in world space, and thus I made the above computations to translate it to car space based on the heading value. However, I am now finding evidence that the initial assessment may have been wrong and the OutSimPack.Accel value is already in local coordinate space to the car...

Can anyone who has dealt with this packet confirm this, or let me know any other information about this packet that is known?
OutSim Packets are always local to the car, as it's meant for motion rig setups.
Pretty certain the acceleration forces are along the world axis. (My old code corrects for that and the output looks perfect)


Edit:
I wrote my code over 6 years ago, so I can't remember exactly how it did things, but I did have to work out what most of the values represented the hard way.
I can glean some info from reading the code and looking at the output display, however some outputs are correct and others aren't so it's going to need a bit of testing to work out exactly what's going on.
Quote from Victor :something quoted from scawen I had lying around:
Quote :heading, pitch and roll are in radians.
acceleration is in metres per second squared.
velocity is in metres per second.
velocity and acceleration are indeed in the "world" coordinate system.

to work out a car's orientation matrix, the calculation order is : roll,
pitch, heading

to work out the acceleration or velocity in the car's coordinate system, a
programmer should create horizontal (x) forward (y) and up (z) vectors
(using the heading, pitch and roll) and take the dot product (scalar
product) of these with the acceleration or velocity vectors supplied in the
outsim packet.


amp88 found this for me and has been extremely useful. I think I'm very close to a solution, my only problem now is the difference between coordinate systems from LFS to AIRS, which I should be able to handle. Heh.
Epic fail on my part.
Okay, FINALLY I have Vel and Accel in both (airs) World and Car spaces. I couldn't convert heading/pitch/roll the way I was trying to above, at least I was super confused by trying that, instead I just created rotation matrices and multiplied them in the order of Scawen's quote and finally things started working as expected.

See here

The light red/blue line is the world right and forward directions, the dark red and blue line are the cars right and forward directions.

The light green line is the world acceleration and the cyan circle is the cars local acceleration, the driver will feel the opposite of this since this is the actual acceleration value.

The light pinkish line is the world velocity, and the yellow circle is the cars local velocity.

I'm not entirely sure about the local/world of AngVel, but I believe the value that I am using (pink line on physics sensor at top-left of the screen) is working to some degree as I expect. If this value is actually important for the AI driver, I will come back and make sure I fully understand it.

Now to clean up all that mess.

OutSimPack Help
(13 posts, started )
FGED GREDG RDFGDR GSFDG