How to Simulate Linear Delta Robot

[arp]

Hi,
I am new to V-REP. I want to simulate this Robot.

https://www.youtube.com/watch?v=AYs6jASd_Ww

I tried looking into how the the Adept Quattro and ABB IRB 360 have been done. But I am still a little clueless on how to model this robot.

Specifically I am confused because the triangular end-effector is connected to six joints. How would I make a single object child of six-joints?

My idea of how the robot hierarchy should be is as follows:

Code: Select all

Base
|--PrismaticJoint1(For Linear Motor)
     |--ShapeMovingWithPrismaticJoint
                  |---SphericalJoint       
                                |---Rod1
                                        |--SphericalJoint
                                                     |---TriangularEndEffector(But this is connected to six other joints )
                  |---SphericalJoint
                                |---Rod2
                                        |--SphericalJoint
                                                     |--TriangularEndEffector(This seems not possible)
|--PrismaticJoint2
  ---And so on

Pointers in the correct direction would be greatly appreciated

Additional Question:
I see three Green Joints in the End Effector of the Adept Quattro. called Q_cartesianX ... What is the use of these three Green Coloured Joints?

[coppelia]

Hello,

modeling such a parallel robot is no simple task, and it requires some experience. Since the mechanism has several loops, you will have to very carefully think about how to create the model hierarchy. The model hierarchy can sometimes be simplified if you only need to run the robot in forward or in inverse kinematics.
In the Adept or ABB models, they can run in both: forward and inverse kinematics, which makes their hierarchy structure more complicated.

The green joints are used when the robot operates in inverse kinematics mode. Have a look how the robot operates, while inverting the visibility layers to get an idea what is happening.

Cheers

[arp]

Hi,

First I would just like to make the forward-kinematics, so that the end-effector is at the appropriate position when the position of the linear-motors is specified.

Do you think using the geometric constraint solver is the way to proceed forward?

[coppelia]

Using the geometric constraint solver is not a good idea, since it will be less precise and slower to reach a stable situation (the geometric constraint solver uses a damped resolution method for stability).

But in the end, the linear delta robot is almost the same as the angular one: only the base joints are different (prismatic instead of revolute). So if you keep the same structure, but simply replace the base joints (the driving joints), it should be fine.

Cheers

[arp]

Hi,

I got the mechanism working by using GCS, overlap constraints for the end-effector.

Here is how I got it working.

Code: Select all

*Base
|--PrismaticJoint
      |--SphericalJointTop1
             |--ConnectingRod1
                   |--SphericalJointBottom1
                         |--EndEffectorShape
                              |--DummyEndEffector  <--|
      |--SphericalJointTop2                           |
             |--ConnectingRod2                        |
                   |--SphericalJointBottom2           |
                              |--DummyEndEffector2 <--|  
.
.
.

The above tree is repeated for three Prismatic Joints and all the EndEffector Dummies have the GCS, overlap constraint.

With this the mechanism seems to have the correct motions atleast. Is there something wrong with the above solution?

Additional Question: Why is the GCS less precise than IK?

[coppelia]

Depending on the application , the GCS module can work well, but following is the situation:

When having a very complex mechanism such as the delta robot, there are several dozens of joints involved, and also several loop closures. To make it mechanically correct, one would have to carefully design the correct DoF of each branch, in order not to create additional constraints blocking the mechanism (the reality can be somewhat easier: in reality you always have some compliance here and there).
The GCS analyzes the number of DoFs for each branch and takes decisions based on that. We believe that for a robust mechanism it is better for the user to define the individual branches and DoFs, and to use the IK module instead of the GCS module. This also because the GCS module will automatically introduce some damping, which will increase calculation time and/or reduce precision.

Cheers