Hi,
I have a virtual ball with mass launched at me and and when I intercept it with our machine, I notice that although my hand is in the same position, the image of where my hand is on the screen ('the stylus') - tends to travel with the projectile as it slows to a stop. It looks like a spring F=kx, but the projectile never just stops dead. Of course there is some fall through sometimes with the projectile and our stylus, but that doesnt concern me as much as the next issue.
This is causing some challenges, because we have a haptic wall to protect the user, and when the force of the projectile on our robot intercepts the invisible haptic-protection-wall (so, the projectile, our stylus, and the invisible haptic-wall have all collided), there is typically a lot of fall-through through the protective haptic-wall.
Any ideas on how I could prevent this?

Could this be because the actuator of our robot is not wrapped in a 'dynamictransform' node with a mass? I dont know if this is even possible..

Lastly, I am using <RuspiniRenderer/> when I initialize.

Quote:
Good thing it is virtual :D.

How did you launch the virtual ball? Are you using RigidBodyPhysics or DynamicTransform? Either way I assume that you feel a force on your machine when you intercept the ball. So you try to resist the force and hold it in the same position? Are you not moving the hand at all?

If you use RigidBodyPhysics or DynamicTransform I am pretty sure that the force applied will slow down the ball, and never ever just stop it instantly because both approaches tries to simulate physics and the forces acting on the virtual ball are to small to stop it right away. The forces from haptics renderers are based on the distance between a proxy on the surface of the object and the actual position of the haptics device, so when the device touches the object the force will probably be 0 and then increase as it travels further.

Try setting the proxyWeighting field of your device to 0 or 1 in order to visualize exactly where the proxy or probe is. So you can understand what is happening.

To prevent fall through:
The problem is probably that to few triangles are sent to the haptics loop, try changing the maxDistance field in the settings of H3DViewer. If you have very few haptic triangles in the scene set it to -1. If you have a lot of haptic triangles simply increase the value. The program will probably be more robust then. If this improves your program then use the correct settings node to set this option for your scene.

Make sure that you do not accidently go "round the wall" by being force to take a fast route around the wall between two frames, that can happen if the wall is to small. The cause of your problems is probably that not enough.

Can the ball go through the wall? In that case you are trying to simulate something that is physically impossible. The renderers can not handle this and if your haptics device is on the surface off the ball it will move with the ball, if the ball then go through the wall then you will have fall through. If this is the case in your program then none of my other suggestions will work.

Thank you for your thorough response. I am using the DynamicTransform node.
I think I have a resolution. I have a loop that is constantly modulating the velocity of the projectile by setting the force on it every loop, because there is no way to set velocity directly.

When the object is 'caught', the velocity modulating loop is still running and therefore the reason that h3d stretches both the stylus & projectile further forward is because my function is trying to put the projectile at a specific velocity, while the user is slowing the object down.

I thought I could get the velocity of the projectile within a certain % of what constant end velocity early, and then turn velocity modulation off - so that when the user catches the ball, the velocity modulator is not trying to push passed the users catch. This has worked.

There is hardly any fall-through now, however, there is still stretching of the stylus going on although my hand is steady. It think may just be how H3D is set up like you said how it uses proxyWeighting.