#13 Transform sensor testings - unknown problem (part 2)

Continuing to do different tests by changing different values, from Step Input, PID, changing the damping, and masses, nothing was showing progress, so my thoughts were that maybe there was a block where there shouldn't be, a block that could be making things unrealistic, so as my starting point for this issue, since the graphs were indicating a range between 0 - 180 degrees I have deleted the conversion block and tried to keep my system in radiants.

Here, after the testings I also explain my own assumption/theory of why I believe this system doesn't work.

Following tests are done in RAD (radiants) instead of DEG (degrees).

For the purpose of having repeating similar tests but with different circumstances, such as in this case without a gain block converting radiants to degrees, I have made a drawing to keep in mind the values for the main "directions":

Test 5 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0 ; Final Value=1.57079633] with manual input [P - I - D]=[3 - 0 - 0.001]:

When I run the simulation like that, which in this case being in RAD, still having done the equivalent in DEG already, I could notice straight away that the robot doesn't start flying away in an unrealistic and uncontrolled manner, but keeps 0 rad as supposedly the "up" position setpoint and then after 0.5 seconds it goes to the 1.57079633 rad (90 deg) and appears to be satisfied in terms of setpoints from this simulation (simulation done at 1/16 speed):

Upon checking the Output graph with the Error between the Desired Angle vs the Actual Angle, shows that the actual angle is following well the Desired one, and gets to stabilize/balance there. I have taken 2 samples along the stabilized output to check how stable it was, and it appeared to be no oscillations at all after getting to that angle:

The torque graph shows a sudden increase at the mark of 0.5 seconds then gets back to 0 Torque because it stabilizes on the desired angle. (The sudden increase is because the system isn't tuned automatically, and I just left it with the PID values used so far) - vertical values indicate the N*m values and the horizontal part of the graph indicates the time, in seconds:

Test 6 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=1.57079633 ; Final Value=3.14159265] with manual input [P - I - D]=[3 - 0 - 0.001]:

This simulation showed me that I was correct to assume that 0 rad is the natural "up" and pi rad is the natural "down" because in this simulation, once it reaches pi/2 rad setpoint, stays there, and after 0.5 sec it tries to reach the "down" position and drags the robot in a direction, but of course in reality too it can't reach an upside-down position, so this simulation makes more sense compared to when I was using the gain block converting from RAD to DEG, but I still can't explain why is that. This simulation is also run at 1/16 speed:

Checking the Output graph I can see that for some reason the Actual Angle managed to somehow get beyond pi/2 radiants, but it is impossible, because as seen in the video, there is a "Floor" and the robot cannot go beyond that unless it falls off from it, or would fly away, and none of those hapenned, so my assumption is that for some reason, the bouncing effect could have made the graph pick up an angle beyond that point, I have taken 2 sample points again, this time one is on the Actual Angle and the other one is on the Desire Angle showing that it never reaches that desired setpoint (vertical values reppresent the radiants and the horizontal ones reppresent the time in seconds):

Test 7 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0; Final Value=4.71238898] with manual input [P - I - D]=[3 - 0 - 0.001]:

In this simulation I noticed that the robot was staying in upright position, then when it needed to go to 3pi/2 rad position (or 270 deg) it started going in clockwise rotation, perhaps trying to reach all numbers up until then, and instead of going in a realistic way to the supposedly new setpoint of 3pi/2 rad in anti-clockwise manner to reach the shortest route possible, it took the longest (video is in 1/16 speed):

The robot seems to want to go from 0 rad to 3pi/2 rad in a clockwise manner, for an unknown reason:

The Output graph accurately what is happening and that the Actual Angle never reaches the setpoint of the Desired Angle because (my assumption) it tries to go clockwise to reach it, so in the next simulation I can try to put -1.57079633 rad (-90 deg) which technically it should mean the same as the current one, but in the attempt to make it go anticlockwise:

Test 8 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0; Final Value=-1.57079633] with manual input [P - I - D]=[3 - 0 - 0.001]:

In this simulation I tried to make it go anti-clockwise to the desired value of 4.71238898 rad (270 deg) by changing the value to -1.57079633 rad (-90 deg), however it is not behaving in the expected way, making me confused of why this isn't working as intended. Video runs in 1/16 speed:

The Output Graph shows an interesting outcome, where the Actual Angle seems to try and mirror the Desired Angle's negative values but on the positive side. I am not sure why this is hapenning, this can be seen from the first sample taken which shows that it reached and was stable for a very short period of time at around the mirrored -1.57079633 rad. Perhaps this bheavior could be related to the fact that when I had the gain block to convert rad to deg, it had the limitation of going only between 0 and 180 degrees on the graph:

Test 9 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0; Final Value=0.17453293] with manual input [P - I - D]=[3 - 0 - 0.001]:

In this simulation I decided to try something close to 0 radiants, and I have used the equivalent of 10 degrees, which is 0.17453293 rad and it appears that the system behaves perfectly normal, and my expectation was that the robot should move "forward" and it did move, of course since the PID has values which I manually put in it has jogging but this tells me that there is something wrong with how the angle is perceived after pi/2 rad (or 90 deg). Video is 1/16 speed:

Checking the Output Graph I could see that the behavior was a more appropriate one, however it was showing that it was becoming slowly unstable if the simulation went on to continue:

I have tried to go to the PID controller and try to autotune it, but it was giving me an error, possibly because the issue still persists and there has to be something wrong still with the system:

My conclusion, after further tests is that while the values are from 0 rad to pi/2 rad everything works as intended, however when I try to simulate outside of that range, or trying out negative values, the simulation behaves unrealistically. I will try to make further tests by trying to identify the main issue.