Real-Time Physics Simulation Forum

added some features
http://www.youtube.com/watch?v=vOmrSV31ZNw
and renewed old video:
http://www.youtube.com/watch?v=L9BhyYopbYg

lukasdurica wrote:added some features
http://www.youtube.com/watch?v=vOmrSV31ZNw
and renewed old video:
http://www.youtube.com/watch?v=L9BhyYopbYg

Hi Lukas,

The demos are wonderful, have you got a web page for your project?

Cheers.

Hi,

Thank you for the response. I dont have any website. Just this youtube channel. If you are interested in this project, i can share some informations here.

lukasdurica wrote:Hi,

Thank you for the response. I dont have any website. Just this youtube channel. If you are interested in this project, i can share some informations here.

Thanks. I would like to know whether you are using the standard Bullet Hinge constraint and torque function to drive the joint ? Such as: enableAngularMoto()/setMaxMotorImpulse etc in the library.

Cheers.

Hi again.

I see. The answer is no, I dont use Hinge. I use btGeneric6DofConstraint instead, but with little modifications.
I dont use default inner motor, but I use its Limits to set the desired angle. Here is why:

1. inner motor is influenced by gravity and is weak, even when I set maxMotorForce to crazy numbers (max double), i didnt see any changes.
2. so i used hiLimit and loLimit to control the angle as well as Hinge does. it was also influenced by gravity, but it seemed to be more "stronger" than inner motor and I was lazy to switch it back
3. i use my own Limits to limit this kind of control
here is how it works as method:

void RotationalMotor::SetTargetLimitsPosition(double targetAngle, double lowerLimit, double upperLimit)
{
if (targetAngle > 180) //if is desired angle > 180 this part of code will fit it into <-180,180>
{
int res = static_cast<int>(targetAngle);
int numOfRot = res / 180;
numOfRot = numOfRot + 1;
targetAngle = targetAngle - numOfRot * 180;
}

else if (targetAngle < -180)
{
int res = static_cast<int>(targetAngle);
int numOfRot = res / 180;
numOfRot = numOfRot - 1;
targetAngle = targetAngle - numOfRot * 180;
}


if (lowerLimit < upperLimit) // here I use my own limits
{
if (targetAngle < lowerLimit)
{
targetAngle = lowerLimit;
}
else if (targetAngle > upperLimit)
{
targetAngle = upperLimit;
}
}


targetAngle= targetAngle* (Constants::DegreesToRadians); //just recalculation degrees to radians - radians = (degrees* pi) /180

6DofJoint.getRotationalLimitMotor(_axis)->m_loLimit = targetAngle;
6DofJoint.getRotationalLimitMotor(_axis)->m_hiLimit = targetAngle;

}
Here you just set the desired angle, so if you want to control it smoothly , you should create your own regulator.

But this is just the beginning how to use angle control. Here is list of bullet variables, that will improve quality of simulation (my values):

fixedTimeStep = 1000 in stepSimulation(..) method
subSteps = 10
number of constraint solvers = 60
ERP of constraint = 0.3
m_limitSoftness =0.0
linearDamping and angularDamping set to more than 0.8
but this are maybe too high values, good for my complicated simulation


Sorry for my terrible English. Hope this helps.

And yes, I almost forget - if you have 64bit processor use BT_USE_DOUBLE_PRECISION macro. It definitely improves quality of simulation.

lukasdurica wrote:And yes, I almost forget - if you have 64bit processor use BT_USE_DOUBLE_PRECISION macro. It definitely improves quality of simulation.

Hi Lukas,

You explained quite clearly! This part of your code Maybe could be simplified into So you are basically setting the high and low limits both to your target angle and it works? Sounds like a simple hack but produces good result! I thought you would need to compute the torque for each joint etc.

Also, could you explain a bit more on how to turn this macro on? Suppose it should be something like this:

Hi,
Thank you for the simplification, sometimes I mix drinking and programming and this is how it looks like

Well, it depends on waht is your IDE and your OS.
If you use Windows, try to reinstall BulletPhysics library using cmake to start the new project from scratch.
Here, follow this manual:
http://bulletphysics.org/mediawiki-1.5. ... om_scratch
Look at the fourth image (the red one) and there you can find BT_USE_DOUBLE_PRECISION (8. argument from bottom) and check it.
Then just continue in manual.
If you use Linux, (recipes here: http://bulletphysics.org/mediawiki-1.5. ... stallation), just run ccmake before cmake then switch to advanced (key T or something similar, I dont remember it correctly), and find BT_USE_DOUBLE_PRECISION and turn it to ON.

The second thing you have to do set this macro to your project (at least to projects where you use BulletPhysics)
I dont know your IDE, but it should be similar. Here is image where I added this macro in Eclipse.

Hope this helps.

lukasdurica wrote:Hope this helps.

Hi Lukas,

It helps a lot. After reading your post and looking into the manual, I found that you can also enable the double precision in compiling libraries by editing the CMakeList.txt: And enable double precision in your project by adding at the top of the file Bullet/src/LinearMath/btScalar.h

There are more possibilities. I just wanted to show you the easiest one .

Hi Lucas,

One more thing, I have switched to Double-precision, and there is no problem with compiling and running, which assumes I have done correctly.

But since I only got two objects in the space, the speed doesn't slow down too much. Is there any way that could prove the double-precision mode is running slower than single-float mode? Not sure which number I should look into.

Cheers.

Hi Shepherd,

What do you mean with "the speed doesn't slow down too much"?
Speed of what?
What do you expect to see? And what do you really see?

The way, I have realized double precision has affect to quality of simulation, that my Hexapod was shaking/jittering after I have reinstalled BulletPhysics, with the same simulation values as before, and I knew that simulation was more stable last time. I forgot to turn on double precision. So I did it. Quality of simulation was back.
So try to build some chain of constraints, fix it in the space, set some of my values (above) and you should see different type of behavior.

God, I have to do something with my english.
Hope this helps.

lukasdurica wrote:Hi Shepherd,

What do you mean with "the speed doesn't slow down too much"?
Speed of what?
What do you expect to see? And what do you really see?

The way, I have realized double precision has affect to quality of simulation, that my Hexapod was shaking/jittering after I have reinstalled BulletPhysics, with the same simulation values as before, and I knew that simulation was more stable last time. I forgot to turn on double precision. So I did it. Quality of simulation was back.
So try to build some chain of constraints, fix it in the space, set some of my values (above) and you should see different type of behavior.

God, I have to do something with my english.
Hope this helps.

Don't worry too much about your English, you have expressed yourself perfectly well.

Then you discovered this by practice. What I mean is that by using double precision, the speed is expected to be about 2x slower than single float mode. So there should be something, like simulation steps, CPU usage etc to see this difference.

Cheers.

Well, no, there is not such a thing. I´ll try to explain how it works.
There are 32-bit processors and 64-bit processors in ..hm.. modern computers.
32-bit processors can work with 32-bit-long word and 64 -bit processors can work with 64-bit-long word (so it means that 64 -bit processors can technically work with two 32-bit-long words, but this is not a point).
Example (just principle):
32-bit processor: 8,2456
64-bit processor: 8,24567859
So double precision means double precision, and if you have got 64bit processor - you can enjoy this advantage.
But if you think, that 64-bit processor can work with 2 32-bit-long words and when you swtich it to 64-bit,and you are expecting it will be 2*slower, that is not correct. Speed of simulation is not affected by 64-bit precision in this way.