• Welcome to PiBoSo Official Forum. Please login or sign up.
 
May 11, 2021, 06:54:55 PM

News:

World Racing Series beta14 available! :)


Questions about daily development

Started by Alby46, June 21, 2016, 09:07:24 AM

Previous topic - Next topic

HornetMaX

Quote from: PiBoSo on January 04, 2018, 01:21:47 PM
It should be easy enough to revert to the old gyroscopic calculation.
However, that probably wasn't correct either, given the super-stable wild-running bikes after some crashes or, most important, the difficulty in doing whips with MX bikes.
The new gyroscopic code is probably more accurate but, sadly, not stable enough with very high velocity spinning objects.
Is the "gyro code" yours or is it part of ODE ? I was under the impression gyro forces are automatically computed by ODE given the rigid body description (bodies, linkages, dofs etc).

PiBoSo

January 04, 2018, 05:17:28 PM #361 Last Edit: January 04, 2018, 05:19:57 PM by PiBoSo
Quote from: HornetMaX on January 04, 2018, 04:55:29 PM
Quote from: PiBoSo on January 04, 2018, 01:21:47 PM
It should be easy enough to revert to the old gyroscopic calculation.
However, that probably wasn't correct either, given the super-stable wild-running bikes after some crashes or, most important, the difficulty in doing whips with MX bikes.
The new gyroscopic code is probably more accurate but, sadly, not stable enough with very high velocity spinning objects.
Is the "gyro code" yours or is it part of ODE ? I was under the impression gyro forces are automatically computed by ODE given the rigid body description (bodies, linkages, dofs etc).

It's part of ODE, but the library is open source, so it's easy to change it.
"Obviously your ambition outweighs your talent".

HornetMaX

Quote from: PiBoSo on January 04, 2018, 05:17:28 PM
Quote from: HornetMaX on January 04, 2018, 04:55:29 PM
Quote from: PiBoSo on January 04, 2018, 01:21:47 PM
It should be easy enough to revert to the old gyroscopic calculation.
However, that probably wasn't correct either, given the super-stable wild-running bikes after some crashes or, most important, the difficulty in doing whips with MX bikes.
The new gyroscopic code is probably more accurate but, sadly, not stable enough with very high velocity spinning objects.
Is the "gyro code" yours or is it part of ODE ? I was under the impression gyro forces are automatically computed by ODE given the rigid body description (bodies, linkages, dofs etc).

It's part of ODE, but the library is open source, so it's easy to change it.
Clear, thx !

Stout Johnson

Quote from: PiBoSo on January 04, 2018, 10:07:00 AM
The new gyro computation makes the simulation explode with very fast spinning objects, like wheels, so it has to be disabled.
Hope it is just a temporary workaround.  :-\  with the new gyroscopic code the sim would probably have the potential to be more accurate. Might mean a lot of tweaking for your sims, but in the end it will surely be for the better.
    -----------   WarStout Kawasaki Team   -----------

PiBoSo

Quote from: Stout Johnson on January 04, 2018, 08:42:41 PM
Quote from: PiBoSo on January 04, 2018, 10:07:00 AM
The new gyro computation makes the simulation explode with very fast spinning objects, like wheels, so it has to be disabled.
Hope it is just a temporary workaround.  :-\  with the new gyroscopic code the sim would probably have the potential to be more accurate. Might mean a lot of tweaking for your sims, but in the end it will surely be for the better.

Snappe tested the MXB without gyroscopic forces extensively today, and it's worse in every area.
Same for GPB, so the gyroscopic forces have been re-enabled, but using the previous, stable, code.
"Obviously your ambition outweighs your talent".

matty0l215

Its odd that new code makes it unstable. Surley like everyone has said. New "better" code should give better simulation.

Do you know where the problem lies? Is it a problem of imcompatability with another part of your engine or is new code just not as good as the old one for this aplication? (As in for a motorcycle simulator)
Hitting the apex is just a figure of speech, Don't literally hit it...

PiBoSo

Quote from: matty0l215 on January 04, 2018, 10:26:48 PM
Its odd that new code makes it unstable. Surley like everyone has said. New "better" code should give better simulation.

Do you know where the problem lies? Is it a problem of imcompatability with another part of your engine or is new code just not as good as the old one for this aplication? (As in for a motorcycle simulator)

Yeah, it looks like the new algorithm ( or its implementation ) is not suited for a racing simulator.
"Obviously your ambition outweighs your talent".

matty0l215

Fair enough. :)

Is it a secret what you are using or could you share?
Hitting the apex is just a figure of speech, Don't literally hit it...

PiBoSo

January 04, 2018, 11:06:41 PM #368 Last Edit: January 04, 2018, 11:09:27 PM by PiBoSo
Quote from: matty0l215 on January 04, 2018, 10:57:57 PM
Fair enough. :)

Is it a secret what you are using or could you share?

According to the ODE code, this is the new algorithm used: https://www8.cs.umu.se/research/reports/show.cgi?year=2006&nr=005
"It is also shown that this scheme introduces physical anomalies in the system"  :o
Looks like its goal is to improve stability at the expense of accuracy. So the end result in GPB is that it is less accurate and less stable as well. Good riddance.
Meanwhile, the "old" explicit gyroscopic calculation is very stable ( probably thanks to the very high update rate of GPB ).
"Obviously your ambition outweighs your talent".

h106frp

January 05, 2018, 12:10:48 AM #369 Last Edit: January 05, 2018, 01:27:55 AM by h106frp
Out of curiousity I tried;
reducing brake rotor mass - you can make this very low without issues (went down to 100g) - handling appeared to improve marginally in a positive sense, not a big observed change
reduced front wheel mass -  you can reduce this quite a bit and handling improves with small instability under heavy braking with silly values of mass
reduced rear wheel mass - oddly, reducing this creates big issues, very low values crash ODE as soon as you go to track, more modest reductions create a lot of instability under heavy braking which seems odd relative to the observations with the front wheel

Bike does feel more lively (in a realistic way) with lower rotating mass, less tendency to run wide on turns and less crabbing on inclines - reminds me of beta6 for some reason.  Straight line, high speed stability does not seem to change much at all, curiously I did not get a riderless runaway bike issue despite trying  ::)

Tried changing the mass back to default and scaling the moments instead, nice easy handling but the bike seemed to lose a bit of 'character'


Stout Johnson

January 05, 2018, 09:26:47 AM #370 Last Edit: January 05, 2018, 09:46:44 AM by Stout Johnson
Quote from: PiBoSo on January 04, 2018, 10:35:07 PM
According to the ODE code, this is the new algorithm used: https://www8.cs.umu.se/research/reports/show.cgi?year=2006&nr=005
"It is also shown that this scheme introduces physical anomalies in the system"  :o
I read the paper of Lacoursière. From what I understand, I think it is like you say. They somehow went into a trade-off between stability and geometric correctness. This (http://lost-found-wandering.blogspot.de/2013/01/gyroscopic-forces-in-ode.html) might also be interesting for you. Looks like the paper from Lacoursière is not totally immune to criticism.

From what I understand though, the paper of Lacoursière deals with any kind of rigid body (e.g. "long thin object" like in the numerical experiment on p.11). As far as I understand, for the simulation of gyroscopic forces for wheels, there should not be much of a problem right? I quote: "the rigid body will eventually stabilize in a state of rotation about the axis with the largest inertia" (p.11 in the paper). For the simulation of gyroscopic forces of wheels there should not be any problem imho, since there is only one axis of inertia (edit: well at least the axis of rotation should be the one with the largest inertia).

So maybe the instabilities you experienced with the new library are due to other variables from your sim? The tests from h106frp might be helpful in that respect maybe? Again, from what I understand if you simulate wheels, there probably should not arise such problems. Maybe the implementation of the new gyroscopic calcualtions just made other instabilities more obvious? In other words: Can you rule out that the instabilities you experienced in your tests with Snappe are caused by anything other than the new gyroscopic code and only became obvious with the new (better?) calculations?
    -----------   WarStout Kawasaki Team   -----------

HornetMaX

Quote from: PiBoSo on January 04, 2018, 09:47:10 PM
Snappe tested the MXB without gyroscopic forces extensively today, and it's worse in every area.
As expected :)

Quote from: PiBoSo on January 04, 2018, 09:47:10 PM
Same for GPB, so the gyroscopic forces have been re-enabled, but using the previous, stable, code.
Question: did GPB even suffer of instabilities tied to gyro forces at all ? I haven't seen much outside the occasional "normalization error" (for which I have no clue indicating it may come from gyro forces instability) ... so maybe the new ODE code was not even needed in the first place.

Checking the gyro forces computation should be relatively easy for a spinning wheel (if you have access to the current wheel state and external forces).




PiBoSo

Quote from: HornetMaX on January 06, 2018, 05:34:22 PM
Quote from: PiBoSo on January 04, 2018, 09:47:10 PM
Same for GPB, so the gyroscopic forces have been re-enabled, but using the previous, stable, code.
Question: did GPB even suffer of instabilities tied to gyro forces at all ? I haven't seen much outside the occasional "normalization error" (for which I have no clue indicating it may come from gyro forces instability) ... so maybe the new ODE code was not even needed in the first place.

No, it didn't suffer any instability. This is why I wrongly assumed that the new code was more accurate, as I couldn't see any other problem to solve.
Maybe GPB doesn't have stability problems because the wheels' inertia is closer to a box than a long stick, and because GPB uses small integration steps.
From what I can understand, most dynamics simulators ( that are not racing, of course ) run under 100hz and can use very odd-shaped objects.
"Obviously your ambition outweighs your talent".

HornetMaX

Quote from: PiBoSo on January 06, 2018, 09:09:54 PM
No, it didn't suffer any instability. This is why I wrongly assumed that the new code was more accurate, as I couldn't see any other problem to solve.
Maybe GPB doesn't have stability problems because the wheels' inertia is closer to a box than a long stick, and because GPB uses small integration steps.
Or maybe we just never reach the conditions for the instability to appear (due to the presence of the virtual rider + user inputs + road contact etc) so in practice we don't really care, especially if the "solution" to that "problem" is actually worse.

HornetMaX

OK, I had a better look at the paper and just looking at how the trajectories of the proposed solution differ from the true ones (in the test case, single body with no applied torque), it is clear this will not work for us.
We're surely better off with a method that stays closer to true trajectories with a risk of being unstable in specific situations than with a method that is globally stable but is fairly far from true trajectories.

Just wondering: ever thought about replacing the ode library with a different one ? Not really to solve any specific problem coming from the ode library itself, but maybe re-coding that part to a different library could help spot bugs/wrong stuff. It's probably quite an effort (especially if the other ode lib has a fairly different api), but ...

Did you know this ? https://simtk.org/projects/simbody