# Robotic Arm analysis in Matlab/simulink

I am going through a paper, Kinematic Modelling and Simulation of a 2-R Robot Using SolidWorks and Verification by MATLAB/Simulink, which is about a 2-link revolute joint robotic arm. According to the paper, the trajectory analysis of the robot was done via simulations in MATLAB/Simulink.

It shows the following picture, Trajectory generation of 2‐R robot with MATLAB/Simulink:

and then, Simulink - Simulation block to calculate the trajectory:

I think this is done in SimMechanics, but I am not sure. Experienced users, can you please tell me what am I looking at and how can I reproduce this?

• Please add a screenshot of the subsystems also...it does not look like simmechanics, just equations implemented as function blocks...
– 50k4
Apr 6 '16 at 5:46
• I found the first image. Its implemented by using Robotic Toolbox by Peter Corke. The paper does not say anything about Subsystems. Does it mean that I can't implement it? You can view the paper at cdn.intechopen.com/pdfs-wm/41413.pdf Apr 6 '16 at 21:26
• I'm not sure if this is what you are asking but the second image is a Simulink block diagram. Apr 7 '16 at 7:33
• Ok. If I want to implement (reproduce) this Simulink block diagram, is it possible? What would i need to do? Apr 7 '16 at 17:37
• " how can I reproduce this" start from the dynamics equations. You don't have to utilize Matlab or whatever software that they used. Use any programming language that is capable of solving ODEs. Apr 8 '16 at 1:28

## 4 Answers

The paper does not say anything about Subsystems. Does it mean that I can't implement it?

This question implies that you don't really know what a subsystem is in the context of matlab.

It's as if you got a new car and a friend of yours says "that's a nice yellow color" and your response would be "What does 'yellow' mean? Can it still drive?"

Please take a step back and think about your approach once again.

This matlab/simulink code is not ment to be used as an introduction tutorial for beginners. Try to familiarize yourself with the fundamental basics of the programming platform separately.

Otherwise you have to solve one equation for two unknowns: What parts of the code are the way they are due to the content of the paper and what due to how matlab/simulink works?

From the paper you can deduce what they implemented, but if you don't know how, it becomes hard (and more importantly: unreliable) to deduce any further information from the code.

Choose tools according to the problem at hand. If using the tool becomes a problem in of itself, you can get trapped in the need-new-tool-to-solve-the-problem-of-the-previous-tool loop.

It looks like the second image is a Simulink system. That doesn't mean it's not also SimMechanics, because there are ways to interface Simulink signals to Simscape.

The thing that is hard (impossible) for you is that those are subsystem blocks, meaning that you can't replicate the code contained inside of them without being able to see inside.

The thing that's really a pain is that it might be stock functionality, or a couple stock blocks strung together, but you can't tell because it's been encapsulated.

The paper you mentioned in the comment clearly presents on SimMechanics model, but it also presnets the necessary equation to solve the inverse kinematics problem.

It seems that the screenshot you have submitted calculates sine and cosine functions of the angles. This would not be necessary if simmemchanics blocks would be used in the subsystems. It seems that the simmechanics model is used to verify the correctness of the inverse kinematics. It is a very convenient way to verify and validate the results. And the correctness of the equations.

From the point of view of the results the two approaches, the analytic solution and the numeric solution using simmechanics have to be the same (with a given tolerance of the numerical error).

From a performance (calculation time) point of view, the analytical solution should be superior to any other numerical solution.

The first step for reproducing the results is to utilize the equations. They didn't mention which controller they used but in my simulation I chose the PD controller, therefore,

\begin{align*} \ddot{\theta}(t) &= M^{-1}( u - V - G) \\ u(t) &= M ( \ddot{\theta}_{d} + k_{d} \dot{e} + k_{p} e) + V + G \\ M &= \begin{bmatrix} m_{11} & m_{12} \\ m_{21} & m_{22} \end{bmatrix} \\ V &= \begin{bmatrix} v_{11} \\ v_{21} \end{bmatrix} \\ G &= \begin{bmatrix} g_{11} \\ g_{21} \end{bmatrix} \\ e(t) &= \theta - \theta_{d} \\ \dot{e}(t) &= \dot{\theta} - \dot{\theta}_{d} \\ \theta_{1d}(t) & = 10t^{4} + 10t^{3} + 10t^{2} \\ \dot{\theta}_{1d}(t) & = 40t^{3} + 30t^{2} + 20t \\ \ddot{\theta}_{1d}(t) & = 120t^{3} + 60t^{2} + 20t \\ \theta_{2d}(t) &= 50t^{4} + 10t^{3} \\ \dot{\theta}_{2d}(t) &= 200t^{3} + 30t^{2} \\ \ddot{\theta}_{2d}(t) &= 600t^{2} + 60t \\ \end{align*}

where $k_{d} = 20, k_{p} = 100, m_{1} = m_{2} = 16.92, l_{1} = l_{2} = 1$. The results I got for the elbow down case via C++ code are

t     theta1  theta2 px        py
-----------------------------------------
0     0       0      2         0
0.1   0.111   0.015  2         0.00349066
0.2   0.496   0.160  1.99992   0.0177943
0.3   1.251   0.675  1.9993    0.0518948
0.4   2.496   1.920  1.99642   0.115588
0.5   4.375   4.375  1.98633   0.221951
0.6   7.056   8.640  1.95706   0.385653
0.7  10.731  15.435  1.88376   0.618508
0.8  15.616  25.6    1.7218    0.919393
0.9  21.951  40.095  1.40621   1.25027
1.0  30.0    60      0.878878  1.49793

They are very close to the results stated in the paper. Visualizing the movement of the manipulator is not big deal. As a matter of fact, people care much about the results not the visualization. This is can be done by OpenGL as well. No one cares about the software you are using.