top of page
Writer's pictureAurel

#15 Transform Sensor - problem partially solved (Quaternion vs Angular Velocity)

Updated: May 3, 2022

Following the thorough process of trying to solve the issue of finding an angle, I found out that the Quaternion is the best solution to find the angle, but I don't know how to use it so here in this post I show how I found an alternative to the quaternions, through integrating the angular velocity of the robot.


I found a very useful link where I learnt that the Quaternions can provide me with exactly what I need, which is taking the angle of rotation around specific axes and that most probably the reason why I was having issues trying to get the correct value for my rotation was because of something called the "Gimbal lock", so my unerstanding as of now is that the best option for me to learn and use would be the Quaternion:


I have also received an email from someone at Mathworks suggesting to use a library, the Robotics System Toolbox ( https://uk.mathworks.com/help/robotics/coordinate-system-transformations.html ) where they recommended using the conversion blocks to get the value which I needed.

I have downloaded the ADD-in library and tried following the documentation and examples at https://uk.mathworks.com/help/robotics/ref/coordinatetransformationconversion.html but unfortunately all I was getting was an array of values, which I couldn't split or isolate and take only 1 value from there. There must be a way to use the existing blocks and take the needed value but I can't find any way, explanation or example that would help me, and even trial & error is not working.

Potential solution: The only way I could potentially use these conversion blocks would be to transfer the array into the Matlab workspace environment, extrapolate the value I need and then put it back to Simscape environment and use it there, but since the project goal is to use Simscape and Solidworks, I have decided to let it go for the moment and try to do that in my own time after I finish everything else.


Below is the system where I tried to use the conversion block and see what results I could get from a robot that has fallen flat on the ground and showing those values on a Display block, and what other options for the conversion i could get if I needed to:


I have also tried the following suggestion but without any success: https://uk.mathworks.com/help/physmod/sm/ug/rotational-measurements.html



Current solution:

Amongst the few suggestions and resources I got, I have found out that:


I have tried to use the Angular Velocity from the transform sensor, and the option of "Omega X" seems to work best when I apply that to my system, all other options don't work so I will stick to this one.


I have taken that output of Omega X from the Transform Sensor block, converted the physical signal into a simulink signal and then applied an integrator block which gives me the Output in RAD. The 2 displays I use (Min Angle, Max Angle), show the lowest peak of the actual output and the highest, respectively. My system currently looks like this:


With the current system the "Tune" button of the PID block doesn't seem to work, or if it works, it gives values for an unstable system, so I have manually tuned it myself, and after many trials & errors I have obtained some acceptable PID values of P = 4 ; I = 20 ; D = 0.15 and I have compared the values shown both on the displays and on the Output Graph to determine the most suitable values with least amount of overshoot.


The following video is made in real-time speed with indication of the "Desired Angle" at the values of Step Time = 2 sec ; Initial Value = 0.17453293 rad (equivalent of 10 deg) ; and ultimately Final Value = -0.17453293 rad (equialent of -10 deg), and the behavior is that it starts the simulation where the robot goes in the relative forward for 2 seconds, then changes direction for the rest of the simulation, and one of the problems by not having perfect values of the PID is that there will be overshoot and in this case of my robot, there is movement in a direction due to its inertia, so it does not change direction instantly, but it is the best I could obtain from manual tuning and the remaining time:


The Output Graph showed a fairly stable system, but with imperfect stabilization, but acceptable. The legend for this graph is Yellow Line = Actual Angle; Blue line = Desired Angle, the vertical scale reppresents the angle in radiants and the horizontal scale reppresents the time in seconds. It also shows that the setpoint is never reached, but any other values tried in the trial and error, would make the robot fly away when it needs to change direction, making the current values the most stable ones found:




Comparison with other closest value tried and it was a close call which one to choose. Values of Lowest and Highest anles were taken from the displays in the system. The reason why I chose the one which didn't touch setpoint, it was because it was ultimately the most stable one with least amount of overshoot. I have tried other values for the PID but they were bringing either the lowest angle to a huge amount, or making the robot unstable, or simply was not enough to keep the robot upright.

PID Values

Setpoint (RAD):

At start

After 2 sec

Lowest Angle (RAD)

Highest Angle (RAD)

Meets setpoint?

P=4

I=20

D=0.2

0.17453293

-0.17453293

-0.6329

0.2887

Yes

P=4

I=20

D=0.15

0.17453293

-0.17453293

-0.325

0.2956

No



In conclusion, I currently have a solution which I want to stick with and apply on my own robot, it is not perfect, but it is the best I was able to find not knowing how to use the Quaternion option and extrapolate the desired element from it. The reason why this is acceptable is because previously my problem was that I couldn't make the robot move in the opposite direction, because it didn't recognize normally the values before 0 deg and after 90 deg.

I will start designing and modelling my 2 wheel legged robot and apply all my knowledge there and work with that model to attempt individual vertical leg movement for my final objective.







EXTRA


Here is a comparison with BEFORE and AFTER the angular velocity was integrated to obtain the appropriate angle.

Both experiments were done using a desired angle of:

-Step time = 2 sec

-Initial value = 0.17453293 rad (10 deg)

-Final value = 0.17453293 rad (10 deg)



BEFORE - robot knows direction, but angle is measured wrong

(best PID values found for this: P=6; I=15; D=0.1)


AFTER - robot knows direction, angle is measured correctly

(best PID values manually found for this: P=4; I=20; D=0.15)


The graph of "AFTER" seems to be overshooting but it is NOT, it is only seen like that in the image because the VERTICAL scale which covers the range of angle is smaller compared to the "BEFORE" which is much bigger.

The PID values couldn't be swapped, meaning I tried each other's values but the simulation was worse than what what is shown above (either the system would overshoot too much or it would become unstable).

131 views0 comments

Recent Posts

See All

Kommentare


bottom of page