Modeling cargo lifter simulation with PhysX 3.3

Visual, Game & Mobile Development Physics Modeling
#1

Hi all,

We are currently trying to set up a kind of cargo lifter simulation with PhysX.
http://imgur.com/Fra8jb9

The pose of an actor which represents the carrier (grey box in image) is given by another program. If the carrier is positioned correctly under a cargo element (white box), it should be able to:
A/B lift the cargo
D move with the cargo on top between different storage locations
C drop the cargo.

The main problem we face is to avoid that the cargo slips from the moving (kinematic) carrier, but can also be easily stacked on the storage pillars.

We investigated some possibilities of how to model that with PhysX, but meanwhile we’re quite stuck with the amount of options.
We thought of switching the cargo between kinematic and dynamic mode. Fixed joints between the carrier and the cargo during transport might also be a way to go, deleting them as soon as the cargo is dropped. But how do we register the drop collision? Do we need sweep queries if the carrier pose is updated too slowly?

Could someone please point us in the right direction?

Thanks,
Lars

#2

Hey Lars,

One of the (easiest) options you have, is to make a form locked shape (e.g. pins on the carrier and holes in the cargo). This is the way real cargo transportation also works.

We use this approach in our simulation tool and it works perfectly: https://youtu.be/GZNc_cSQ4no?t=59
the yellow gripping feature in this movie shows two smalle dots the gripper has two small holes. With close to no friction and a tool of ~3kg, the tool can be extracted from its tube.

Critical is to choose:
-A sufficient small time step (<10ms)
-A right ContactOffset and RestOffset (when they are too big, the pin will not fit the hole :)

Good luck

#3

Hello JOT,

thanks for your suggestion and the example video. Interesting work.
Our real application does not rely on locking the cargo by special shapes, but on friction. I’d resort to creating special shapes that are non-existent in the real application as one of the last means.

Meanwhile I got collision callbacks working and we will try to use fixed joints. That looked promising in a small test application. How to handle slow update rates (~100ms) of the kinematic actors is still a problem we might face…

Thanks
Lars