MSPhysics tests and questions

markahon

Thanks for the reply faust07. Here's one of my designs, reduced, I hope Table design to test what weights cause table to tip over

faust07

In this case it seems to be the right approach to take all the parts into a component.
Joints are possible but not very helpful here. (You could test it with the "Fixed" Joint)
What I've changed:
Table legs and feet broken down into individual subcomponents. Then the collision geometry is more accurate. You can see it if you activate Collision Wireframe in Debug Draw in the MSPhysics UI.
The base plate I have assigned the material Concrete and I have the axis position of the cube weights corrected in order to prevent that the parts sink into the ground.
The axes were far outside the cube. But I do not know whether this significantly affect the behaviour of the body.
The best way to prevent sinking is to increase the value for the material thickness (to 0.10) in the UI. Please test it.

table with little corrections

faust07

Hi Anton, short question: how can I make up for the differences between controller and scripted input? With the same pre-set parameters why arise the differences in the results?
Model slightly reduced to test it.

Pengu-Test_03.skp

faust07

Here is an approximation of the setting of a servo joint (oscillator) with controller or script.
The oscillation about 180° in both directions corresponds to the number pi in the script. Seems somehow to be logical ...

Servo-Test_04.skp

Anton_S

Hello faust,

Nice coding there. So, when you assign value via script, i.e some_servo.controller=, the value is assumed as some angle in radians. Whenever, you assign it via controller, the angle is assumed as the angle in preset angle units, which are by default in degrees.

Now, instead of iterating through all servos to assign their controller, a more reliable way would be to use a variable. Control the variable through script and change servo angle via controller. Here is what I mean:

onStart { @p3_head_osc = 30 set_var('wing', 0) } onUpdate { set_var('wing', oscillator(@p3_head_osc) * 30) }

Paste this in the controller of a desired servo:
get_var('wing')

Other than that, I'm amazed by your improvement in scripting. Keep it up!

Anton

faust07

Thanks Anton! The simple way is the best - I will try it. Here a little pengu fun with my old script solution and "Curvy Piston".

robint

Hi All

Not wishing to hijack this OP, but I cant see where to post otherwise
so here goes. Attached is a simple falling block assy to test the validity of accel due to gravity, ie block should fall 9.81m in 1 sec, all thing set right.

What would be nice is to have a script that stopped the sim once the bloack collided with the baseplate. In theory I should be able to read the time taken, no of frames etc on the bottom lhs of the screen, but just now I approximate this by tapping pause on eyeballing the block - not very accurate at all

Iv'e seen there is an "on touch" script with slamming doors but Im still a ruby newbie

Is there a way to stop the sim on block reaching the baseplate?

FYI If I can get this to work for my students, then the next step is to simulate the viscosity experiment using a falling sphere in fluid, but I dont know if SU can simulate viscous fluid yet?

Great stuff on this page, I am truly humbled

Robin

falling block.skp

faust07

Hi Robint
Put this script into your baseplate (copy the 3 lines, select the plate, open MSP UI, select "Script", paste the lines into the Script window, run MSP):

onTouch { |toucher, position, normal|
MSPhysics::Simulation.reset
}

and the simulation stops "onTouch".

robint

@faust07 said:

Hi Robint
Put this script into your baseplate (copy the 3 lines, select the plate, open MSP UI, select "Script", paste the lines into the Script window, run MSP):

onTouch { |toucher, position, normal|
MSPhysics::Simulation.reset
}

and the simulation stops "onTouch".

Hi Faust, thanx for the tip, but not quite there yeet

the simulation resets and I lose all the time/frame data at the bottom of screen - which is what I need for this to be useful.

I tried .pause and .stop but they dont exist

Is there something else I could try?

robint

Hi Faust

Through the Ruby Code editor, I found a start_timer and stop_timer function

Would this help?

Say put start at the top to activate when staring sim,

then stop_timer after the reset action line

then display timer?

sorry my newbie attempts at script (do you hav any recommendations on the best way to learn script for MSP - there's so much flack out there its hard to know where to start)

Cheers

Robin

faust07

Hi Robin,
have tested to find a solution to pause simulation per script, but have nothing found until now.
I'm a script newbie too. For my purposes I look into scripts of models from the experts at 3D-Warehouse (AntonS & PituPhysics) or ask them in Anton's main MSP post.

robint

Well we are both struggling, blind leading the blind

FYI this timer thing is fundamental to simulating physical systems (mass speed acceleration)

The on touch is a good start, just need to time the sequence and display result on reset

opens up a whole new way of simulating mechanical systems

as fundamental say as a thermometer is to tell you the temperature - if you see my point

so I must perservere. If I get a result I will post it you

Cheers

Robin

robint

A bing moment has occured

when I # out the reset line, I just had a ontouch line only and it outputs to screen what might be some sort of final velocity m/s on impact (according to the script info)

pls see model

Now I cant yet correlate that to the calc velocity which should be 14m/s on impact from 10m
it comes out at 58 and varies with the UI sim setting of Newton update rate (currently 10)

also from dropping from 5m gives 33 (should be 9.9m/s and is 1/sqr2 - .707) whereas 33/58 is ca.57

maybe some dynamic friction in play?

Is this a worthwhile line of enquiry?

Cheers

Robin

ps the ball is in anton's examples funny little thing - and something for gamers pool table maybe?

falling block.skp

Anton_S

Yes, the final velocity should be 14 m/s, and it is 14 m/s.

Your script in the model you posted, just outputs the frame:

onTouch { |toucher, position, normal, force, speed|
  simulation.log_line("onTouch #{frame}")
}

That explains why you get unrelated results.

To output the final velocity, you should change the code to output the speed:

onTouch { |toucher, position, normal, force, speed|
  simulation.log_line("onTouch #{speed}")
}

And besides, setting the linear damping of the falling box to zero will make the final velocity even more right because this will eliminate the dissipative force.

robint

Thank you so much Anton, I was just about to post an apology for a stoopid boy Pike moment (no smilie for Duh )

but I read the second line and it outputs frame to screen, what a numpty

You gave me some other scrip that outputs velocity, strange to note that the cube reaches a terminal velocity ca 2m/s ca halfway down - intriguing. Is there something in there that simulates viscosity?

onUpdate {

Get current velocity

cv = this.get_velocity

Output it in the note

note = sprintf("Velocity: (%.3f, %.3f, %.3f)", cv.x, cv.y, cv.z)
simulation.display_note(note)
}

Cheers

Robin

Anton_S

Yes, the viscosity is simulated by the linear damping. To remove the linear damping, select the desired group, open MSPhysics UI, activate the Properties tab, and set Linear Damping to 0.00. This should alter the height of terminal velocity.

If you meant something else, like water or buoyancy, you can add a buoyancy plane by navigating to (Menu)Extensions->MSPhysics->Create Buoyancy Plane. Although the liquid is not simulated. It's just the buoyancy force that is applied.

robint

Hi Anton

Just when I thought you cracked it with speed, something strange happens

When dropping the block from 10m = ok = 14m/s as per calc (see model)

Move the block down to 5m => nonesense answer like 0.07... (should be 9.9m/s)

Yet move block to other elevations like 8.5m or 2.5m , seems to work ok (but I haven't checked the result against calcs (12.9, 7)

So I am completely stumped

BTW sometimes the block appears to penetrate the baseplate and slowly return to zero, could this be the reason?

Thats ruined my day

Cheers

Robin

falling block2.skp

robint

Maybe uncovered a nasty bug? Anton

Here's a suggestion from your speed indicator

onUpdate {

Get current velocity

cv = this.get_velocity

Output it in the note

note = sprintf("Velocity: (%.3f)", cv.z)
simulation.display_note(note)
}

When it runs, on collision it displays 0.00 as expected, the block has stopped but we lost the terminal velocity

Could we say put an IF loop in the output velocity to note, only iff velocity <say .5m/s, then it should go to zero when the block stops (assuming no bounce)

Just a thought, maybe a simpler approach? from a ruby newby

Cheers

Robin

robint

Sorry, Im getting tired

I meant it should retain the highest last value in note when the block stops

Apologies

Robin

Anton_S

It's all cool

Here is the code for viewing maximum velocity.

onStart {
  @max_vz = 0
}

onUpdate {
  v = this.get_velocity
  if v.z.abs > @max_vz
    @max_vz = v.z.abs
    simulation.display_note(sprintf("Max Speed %.3f m/s", @max_vz))
  end
}

And yes, the speed indicator in onTouch may not always work right, which is the problem of the physics engine that my wrapper is using.