3D robot simulator - friction problem

[marc_256]

Hello all,

For my daughter and myself,
we are building a small robot for are local robot club contest ...
So, I made a 3D simulator for testing the robotic arm program.

The goal is to find 5 cola cans, and put them together in the corner of the plane.

Now, I wanted to simulate the robot actions,
but for that, I need some friction between the robot gripper and the cola can.

Is this possible to simulate ?
and how can I program this physics settings ?
but what about friction value metal / metal ?

I found already the WorldGravity(9.



Thanks,
marc en elia

[DK_PETER]

It's possible. Take a look at CreateEntityBody(), EntityCollide() and the Engine's WorldCollision() functions.
That should get you started.

[Derren]

Can you get the area where the clamps and the can are touching?
Multiply this by a "friction coefficient" (unless there's a real world physics engine involved, you probably need to experiment with some values and they will most likely have nothing to do with any real world values you can find in books) and test against your gravity.

Let's say your gravity is 1 (or -1, whatever) and your friction is also 1. 1 per area unit. This means, if at least one area unit is touching (in real life: one square centimeter, or square inch, or whatever), you can lift the can.
So the downward acceleration of the can is Min(0, gravity - friction*area).
The Min(0... is so that a high friction or large are doesn't lift up the can. That would be nonsense.
You see, the lower the friction factor, or the lower the touching area, the more gravity comes into play.
If you let go of the can, then full gravity is in effect and the can falls down.

A huge friction would simply mean that your clamps are sticky or magnetic, as a tiny touching area is enough to lift the can.

Also, this means that pressure is irrelevant. In reality you can lift the can with two needles. This will not work with this simple method. But it would be way more complicated to take all that into account.

[IdeasVacuum]

Hi Marc

What a great project!

How is the actual robot going to recognise and grip the cans? Vacuum suction? Just good rubber grip?

I think the simulation, if it can already do the recognition and alignment tasks, doesn't necessarily need to know about friction. Once aligned, the coordinates of the can become an offset of the gripper's coordinates......

[marc_256]

Hello,

@DK_PETER and @ derren

I made some tests ...
I was just taking a look at the PB 3D commands, and the friction stuff is looking very complicated.
But if one day I have some time for it, I gone look to test this with some examples.

For now, I gone follow the solution of IdeasVacuum ...
If the coordinates are aligned, I go lift the cans with the gripper.

@IdeasVacuum

I did some tests with a LIDAR (laser) ... need more tests and some ultra sonic detection.
I recently have some "Sharp IR Distance Sensor - GP2D12 (10-80 cm)"
I wanted to use a stereo camera, but for now a little to complicated
working with an old 68000/16MHz SBC so, all programming in 68K ASM ...

Within the program I just use the cans coordinates to find them,
I do'nt use ray picking so far ...

And for lifting the cans, just good rubber tape inside the alu grippers.

thanks for the ideas,

marc

[marc_256]

Well, this is not so simple as I thought ...
I added some variables for gripper open/close, and position can = ok



But ... when the gripper is up in the air, and I open the gripper ...
the can must fall down, and hit the ground with the speed of -9.806 ?

And that is not so simple

So, maybe I need some physics here ...


marc

[Derren]

Not with the speed of -9.
That's the acceleration. Acceleration is speed per time.
So if you drop the can from a low height and the can travels only a split second, the speed will be low.

You have a speed "x" and for every frame of your animation, the position of the can is increased by x (be it positve or negative), right? That's how objects move.
Now to, simulate acceleration, you need to vary that speed-variable x.
For example, every tick, the speed "x" is increased by 0.1.
Since the speed of the can is 0 at the beginning, this means that the can is moving 0.1 units (pixels, meters, whatever) per frame. Then 0.2, then 0.3 and so on, Until you reach a "final velocity" (then the speed is no longer increased), or until you hit the ground (speed is reset to zero).

[IdeasVacuum]

Hi Marc

.... maybe the competition will control their Robots via an Arduino microprocessor and an Android Smartphone App?

About the pick-up put-down logic - that is just "mode".

# If the can is not picked up, it's mode is "free" [0] and it has it's own world coordinates
# If the can is picked up by the robot, it's mode is "captured" [1] and it's coordinates are an offset of the robot's gripper
# If the can is put down by the the robot, it's mode is "free" [0] and its coordinates are now the current world coordinates

So, the can only gets picked-up and carried by the Robot when the mode is set to "captured"

[marc_256]

@derren,

Yes I'm messing up some things here,
you are right, this is the WorldGravity()

On your second point you are right again,
but the max distance of the grippers are 270 mm height.
So, even if I use your formula, the time and distance are to little.

@IdeasVacuum,
Yes I know, but I started long time ago with my SBC 68000
And I love the MC68000 with all the I/O I have here on my board, so ...
and all the changes I made on the board

Yes, that is what I did, I used some extra variables now.


see you soon, with new updates ...

marc

[Derren]

what do you mean, the time and distance are too little. too little for what?

if you have something like gravity already in your engine, you just need to activate or deactivate its effect on the can.
I reckon any object will fall down until it collides with another entity, this way?

[IdeasVacuum]

Hi Marc

Your website is a really good read. I like this bit:

- You take a pencil, an eraser and A4 / A3 paper, and you start sketching,
to erase, to sketch and to many erasers and sketches ...
until you suddenly come to the conclusion that what you have outlined
it must be (your own robot).

So, I think the finished robot can conquer the World, never mind a few cans