Determinism

Post Reply
MRENOU
Posts: 9
Joined: Thu May 26, 2016 11:50 am

Determinism

Post by MRENOU »

Hi everybody,

I did a simulation of a robot with hinges and motors for articulations, and it seems like it's not really deterministic. But I would like to use my results on a real robot so I want it to be deterministic.
My robot is about 3cm long so I scaled the world by a 100 factor (just by scaling the gravity by 100, do I need to do something else ?)

I call stepSimulation like this :

Code: Select all

	world->stepSimulation(1.f/240.f); 
And every 0.5seconds I send new targets to the motors.

But if I run my simulation 15 times and display the position of the robots, it's not always the same results :
X Y Z
-0.353351 -19.6386 2.0749
-1.88595 -20.2211 2.16615
2.30163 -22.2516 2.25783
-1.36052 -20.7487 2.16961
2.93604 -20.4361 2.1884
-1.22291 -20.9594 2.18444
-1.88595 -20.2211 2.16615
1.02449 -22.7842 2.0988
-1.36052 -20.7487 2.16961
0.655865 -23.8902 2.2304
11.7345 -24.4347 2.24751
-0.353351 -19.6386 2.0749
1.26487 -22.0329 2.18892
39.6191 22.1354 6.25826
-0.353351 -19.6386 2.0749

Do you have any advice in order to make it deterministic ? Sometimes I have the same results (like the first line and the last one, or the second one and the 7th one), it's weird isn't it ?
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Determinism

Post by benelot »

Hello MRENOU,

To what extent did you already follow this guide whe implementing your physics stepping?:
http://www.bulletphysics.org/mediawiki- ... _Game_Loop

Your scaling sounds reasonable, but does it mean that your whole robot is 0.03 in size? That sounds like it is pretty small, especially because the subcomponents could be even smaller.

Your X Y Z notation is the position after a certain stepped time? That you get the same results from time to time is basically a discretisation of your stochastic behavior. Let us see if we can fix this.

If you step the way you do, you in fact step with the internal 1/60.0f time step, but only after you integrated enough time. Look at the description of time stepping here:
http://www.bulletphysics.org/mediawiki- ... _The_World

I can append my finished timewarp example (to be published soon in the example browser) for you, which runs deterministic and can speed up the simulation. Furthermore it goes into the advanced tuning of other important parameters.

Maybe it helps you to fix your issue.

Another issue you might have is the timing of your motor commands. If you want to be sure that they are applied at the right timesteps, you should use simulation tick callbacks:

http://www.bulletphysics.org/mediawiki- ... _Callbacks

This guarantees determinism related to the motor commands.

If nothing of this helps, we will have to look at your physics stepping loop in more detail.
Attachments
TimeWarp.h
(1.09 KiB) Downloaded 306 times
TimeWarp.cpp
(54.62 KiB) Downloaded 311 times
Last edited by benelot on Sat Jul 02, 2016 12:21 pm, edited 1 time in total.
MRENOU
Posts: 9
Joined: Thu May 26, 2016 11:50 am

Re: Determinism

Post by MRENOU »

benelot wrote:Hello MRENOU,

To what extent did you already follow this guide whe implementing your physics stepping?:
http://www.bulletphysics.org/mediawiki- ... _Game_Loop
Yes, partly, here is my main loop :

Code: Select all

addToWorld(world);

internalTimeStep = 1.f/240.f;
btScalar timeBtMvt = 0.5f;
int c(0);
int n(0);
int pas(timeBtMvt*60);

// Boucle principale
bool running = true;
while (running)
{
	 if (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
	{
		running = false;
        }

	// Update dynamics
	for (int i(0) ; i < 4 ; i++){
 		world->stepSimulation(internalTimeStep);
	}

 	// Commandes moteurs
 	if (c == n*pas)
 	{
		 for (unsigned int i(0) ; i < r_hingeConstraints.size() ; i++)
	         {
		       r_hingeConstraints.at(i)->setMotorTarget(i_target.at(i * r_nbMvtPerMotor + n), timeBtMvt);
		 }
		 n++;
 	}
	c++;

	// Simulation stops after "simulationTime" seconds
	if (c >= 60 * simulationTime)
	{
		running = false;
	}
}
cout << r_motionStates.at(0)->m_graphicsWorldTrans.getOrigin().getX() <<
		r_motionStates.at(0)->m_graphicsWorldTrans.getOrigin().getY() <<
		r_motionStates.at(0)->m_graphicsWorldTrans.getOrigin().getZ() << endl;

removeFromWorld(world);
where addToWorld and removeFromWorld are methods which add or remove my robot and constraints.
benelot wrote: Your scaling sounds reasonable, but does it mean that your whole robot is 0.03 in size? That sounds like it is pretty small, especially because the subcomponents could be even smaller.
No, of course it's more about 30cm long, sorry for that
benelot wrote:Your X Y Z notation is the position after a certain stepped time?
Yes it's the position of the body of the robot after this loop.
benelot wrote:Another issue you might have is the timing of your motor commands. If you want to be sure that they are applied at the right timesteps, you should use simulation tick callbacks:
Sounds like I'm not doing it properly... I'll take a look at this.

Thanks a lot, anything to say about my main loop ?
Thanks again benelot, you really help me for my project
MRENOU
Posts: 9
Joined: Thu May 26, 2016 11:50 am

Re: Determinism

Post by MRENOU »

I'm not sure to understand what is explained in the wiki for "Simulation Tick Callbacks", how do I need to use it for motor commands ?

The way I do it in my main loop is not good ?
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Determinism

Post by benelot »

The way you implement it is sufficient for most cases such as games, but it could be a source of your stochastic simulation. Therefore I suggested the change.

There is a nice example of using a Tick Callback for motor commands in the DynamicControlDemo/MotorDemo.cpp:

Look for void motorPreTickCallback (btDynamicsWorld *world, btScalar timeStep) and check how it is used to set the motor position. This might fix your issue.
MRENOU
Posts: 9
Joined: Thu May 26, 2016 11:50 am

Re: Determinism

Post by MRENOU »

Well ! I found the problem. You were right there was a problem on motor commands. I don't really know why but if I enable motors and set max impulse at initialization it's not deterministic...

So every time I set a new target to motors I need to do :

Code: Select all

hingeConstraints->setMaxMotorImpulse(btScalar(150.f));
hingeConstraints->enableMotor(true);
Maybe you know the reason why?
However thanks for the help benelot
benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Determinism

Post by benelot »

Hey! I am happy you found your issue. I can not tell you why it happens, we should ask Basroil on this, he is more motor control savy in Bullet Physics than I am.
Post Reply