G-krachten uitrekenen aan de hand van beperkte data

[ikt]

In een tooltje wil ik de g-krachten visualiseren van een voertuig. De relevante data die ik tot mijn beschikking heb, zijn de coördinaten, de tijdsduur tussen het vastleggen van de coördinaten, de snelheden van het object zelf en de rotatiesnelheden van het object.

Mijn huidige manier om dit voor elkaar te krijgen is door 3 punten te pakken, daartussen de hoek van te pakken. Zodoende heb ik de hoeksnelheid van het object, dit vermenigvuldigd met de absolute snelheid zorgt ervoor dat ik de versnelling in ms^2 heb. (ω·v)

Echter zorgt deze manier voor erg veel ruis in mijn data. Het gemiddelde van al die punten geeft wel een degelijk resultaat, maar ik heb toch het idee dat ik niet de goede data gebruik, of dat er ergens een fout zit.

C++:

// Vector3: Heeft een .x, .y en .z.
// De x-as is in de breedte van het voertuig, rechts positief
// De y-as is in de lengte van het voertuig, vooruit positief
// Functies volledig met hoofdletters komen uit de applicatie.
// 

std::vector<Vector3> LastCoords(3);

void onTick() {
Vector3 accel = g_vehData.mAcceleration;

    Vector3 absPos = ENTITY::GET_ENTITY_COORDS(g_playerVehicle, true);
    LastCoords.push_back(absPos);
    while (LastCoords.size() > 3) {
        LastCoords.erase(LastCoords.begin());
    }

    float worldSpeed = Length(g_vehData.mVelocity);
    float worldRotVel = 
        GetAngleBetween(LastCoords[1] - LastCoords[0], LastCoords[2] - LastCoords[1]) / MISC::GET_FRAME_TIME();

    if (isnan(worldRotVel)) {
        worldRotVel = PrevRotVel;
    }

    PrevRotVel = worldRotVel;
    float GForceX = (accel.x + worldSpeed * worldRotVel) / 9.81f;
    float GForceY = accel.y / 9.81f;
    UI::ShowText(locX + 0.100f, locY - 0.075f, 0.5f, fmt::format("LAT: {:.2f} g", GForceX));
    UI::ShowText(locX + 0.100f, locY + 0.025f, 0.5f, fmt::format("LON: {:.2f} g", GForceY));
}

Helper-functies:

C++:

template <typename Vector3T>
auto Dot(Vector3T a, Vector3T b)  {
    return a.x * b.x + a.y * b.y + a.z * b.z;
}

template <typename Vector3T>
Vector3T Cross(Vector3T left, Vector3T right) {
    Vector3T result{};
    result.x = left.y * right.z - left.z * right.y;
    result.y = left.z * right.x - left.x * right.z;
    result.z = left.x * right.y - left.y * right.x;
    return result;
}

template <typename Vector3T>
auto GetAngleBetween(Vector3T a, Vector3T b) {
    Vector3T normal{};
    normal.z = static_cast < decltype(a.x) >(1.0);
    auto angle = acos(Dot(a, b) / (Length(a) * Length(b)));
    if (Dot(normal, Cross(a, b)) < 0.0)
        angle = -angle;
    return angle;
}

Buiten ω·v zou ik niet echt weten welke data van toepassing is. De rotatiesnelheid van het voertuig zelf (om de eigen as) kan ik niet gebruiken - dan zouden de nummers bij een slip niet kloppen. Kan iemand helpen?

[RobIII]

ikt schreef op maandag 6 juli 2020 @ 17:33:
Echter zorgt deze manier voor erg veel ruis in mijn data. Het gemiddelde van al die punten geeft wel een degelijk resultaat, maar ik heb toch het idee dat ik niet de goede data gebruik, of dat er ergens een fout zit.

Ik denk dat je eerst eens moet kijken waar die ruis vandaan komt. Is je float precies genoeg voor je doeleinden? En als het gemiddelde een degelijk resultaat geeft, is een 'sliding window' van de afgelopen X gemiddelden (of over de afgelopen tijd T) dan niet wat je zoekt?

[.oisyn]

Ik snap eigenlijk niet zo goed waarom je zo moelijk doet met het uitrekenen van de hoek e.d. En eigenljik heb je data over acceleratie en snelheid ook helemaal niet nodig als je de coordinaten al hebt.

Het verschil tussen 2 coordinaten op verschillende momenten (gedeeld door de tijd ertussen) is je snelheid, als vector.
Het verschil tussen 2 snelheden is de acceleratie, als vector.

Die acceleratie vertaalt zich direct naar G-krachten als je deelt door de valversnelling.

De vraag is natuurlijk wel, wat is de bron van je data? Gaat het om een game of simulatie die jou de exacte coordinaten kan geven? Of betreft het een echt voertuig en komt dat bijvoorbeeld uit de GPS rollen?

[ Voor 17% gewijzigd door .oisyn op 08-07-2020 16:06 ]

[ikt]

RobIII schreef op maandag 6 juli 2020 @ 18:05:
[...]

Ik denk dat je eerst eens moet kijken waar die ruis vandaan komt. Is je float precies genoeg voor je doeleinden? En als het gemiddelde een degelijk resultaat geeft, is een 'sliding window' van de afgelopen X gemiddelden (of over de afgelopen tijd T) dan niet wat je zoekt?

Een sliding window over de laatste 20 frames geeft een degelijk resultaat, maar zou dat de goede manier zijn om de waarden op te lossen?

Floats zijn jammer genoeg het enige type dat uit de API komt. Als ik alles naar double cast en daarmee berekeningen doe, worden de resultaten niet zichtbaar beter.

.oisyn schreef op maandag 6 juli 2020 @ 18:07:
Ik snap eigenlijk niet zo goed waarom je zo moelijk doet met het uitrekenen van de hoek e.d. En eigenljik heb je data over acceleratie en snelheid ook helemaal niet nodig als je de coordinaten al hebt.

Het verschil tussen 2 coordinaten op verschillende momenten (gedeeld door de tijd ertussen) is je snelheid, als vector.
Het verschil tussen 2 snelheden is de acceleratie, als vector.

Die acceleratie vertaalt zich dirent naar G-krachten als je deelt door de valversnelling.

De vraag is natuurlijk wel, wat is de bron van je data? Gaat het om een game of simulatie die jou de exacte coordinaten kan geven? Of betreft het een echt voertuig en komt dat bijvoorbeeld uit de GPS rollen?

De data komt uit een spel, die exacte coördinaten geeft.

Je eerste opmerking - nog niet aan gedacht, en het werkt goed. Het geeft wel een vector terug in wereld-coördinaten, maar met wat vectorgeklungel moet dat wel naar een object-relatieve vector gedraaid kunnen worden. Bedankt!

Voor de volledigheid - mijn uiteindelijke oplossing:

C++:

    Vector3 worldVel = ENTITY::GET_ENTITY_VELOCITY(g_playerVehicle);
    Vector3 worldVelDelta = (worldVel - PrevWorldVel);

    Vector3 fwdVec = ENTITY::GET_ENTITY_FORWARD_VECTOR(g_playerVehicle);
    Vector3 upVec = ENTITY::GET_OFFSET_FROM_ENTITY_IN_WORLD_COORDS(g_playerVehicle, 0.0f, 0.0f, 1.0f) - ENTITY::GET_ENTITY_COORDS(g_playerVehicle, true);
    Vector3 rightVec = Cross(fwdVec, upVec);

    Vector3 relVelDelta {
        -Dot(worldVelDelta, rightVec), 0,
        Dot(worldVelDelta, fwdVec), 0,
        Dot(worldVelDelta, upVec), 0,
    };

    Vector3 accel = relVelDelta * (1.0f / MISC::GET_FRAME_TIME());

    float GForceX = accel.x / 9.8f;
    float GForceY = accel.y / 9.8f;
    float GForceZ = accel.z / 9.8f;
    PrevWorldVel = worldVel;

[ Voor 19% gewijzigd door ikt op 07-07-2020 09:21 ]

[.oisyn]

@ikt Top

Wel een opmerking. Ik ken de API verder niet, maar als ik erop Google vind ik oa GET_ENTITY_MATRIX die je direct de forward, up en right vectors geven van een entity, dat scheelt weer wat gekunstel met een up-vector bepalen en een crossproduct doen, maar je zou ook GET_OFFSET_FROM_ENTITY_GIVEN_WORLD_COORDS kunnen gebruiken om de world-vector direct naar entity space te kunnen transformeren

[ Voor 8% gewijzigd door .oisyn op 08-07-2020 16:05 ]