#12 Transform sensor testings - unknown problem (part 1)

After learning to use the transform sensor "Angle" option on a double pendulum I have brought that knowledge into the self-balancing simulation and tried to apply it and see whether I could get the robot to stay in an upright position.

In short, it didn't work and in this post I am showing some of the testings which I have done, all failing to make sense. The robot is always flying uncontrollably and the wheels keep spinning. Only one testing/configuration seems to work and I tried giving it a meaning, and some other simulations were very unrealistic but from previous experiences I tried to make sense out of the results I get and see whether the system behaves just like it says (in the past this hapenned with the angle that I thought it didn't make sense from a visual point of view when in reality it made a lot of sense).

I have added that sensor with the option "Angle" enable to sense the angle between the world frame and the chassis of the robot, so the system now looks like this:

The Transform Sensor renamed into Sensor, is supposedly measuring the Angle between the world's frame and the chassis' frame:

Test 1 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0 deg ; Final Value=90 deg ] with manually tweaked PID:

In this test, upon starting the simulation the robot is starting to move to achieve a 0 deg Angle between world frame and robot's chassis, but the robot started spinning uncontrollably and flying away until the 0.5 sec have elapsed an the "Final Value" became the new target to reach, and to some extent this new value, 90 deg, somehow is stabilizing mid-air, because of inertia, momentum or all forces of the world combined together.

The PID controller was manually modified to a [P I D] = [3 - 0 - 0.001]

Video 1/16x speed:

A zoomed in version of this video when the setpoint gets changed and it starts to stabilize (same playback speed):

The Output Graph of this test measuring the error (actual output vs desired output), shows that it is unstable until after 0.5 sec when the Final value kicks in and somehow it starts to marginally stabilize, not to the desired output (which is 90 deg) but to a close value, in this case to 117.1 deg:

Samples from the picture, zoomed in, taken both at 1.996 seconds, where sample1 (yellow point from the graph above) indicates the 117.1 deg meaning that is the actual angle of the marginally stabilized robot, and the 90 deg (blue point) shows the desired one:

In my attempt at trying to interpret the outcome of this test of the simulation I have drawn on a paper the robot at an approximate inclination, and tried to understand what exactly is 117 deg, from where to where, and I came to the conclusion that the natural "UP" is 0 deg here reppresented in Z+, then in a clockwise manner, the following reference angles can be found, such as 90 deg (Y+), 180 deg (Z-), 270 deg (Y-) and 360 deg (which should correspond to the 0 deg), then the Z' and Y' are the axes of the robot:

Checking the Torque graph I can see that the part that is marginally stable also receives relatively low Torque (between absolute vlue of 50 and 150 N*m) compared to when it was trying to reach that Initial Value of 0 deg for the first 0.5 seconds (jogging between 0 and +- 500 N*m, with a maximum of 2.270 * 10^3 N*m at its peak when it changes setpoint, my thought is that the robot "breaks" to try and accomodate the new setpoint). My interpretation of this graph is that the system is still unrealistic, keeping in mind that everything that happened so far happens in a simulated time of 5 total seconds:

Zoomed in graph on the part that has most action, which is in the first 1.5 seconds of the simulation:

Test 2 [ Desired Angle Step Input: Time=0.5 sec ; Initial Value=0 deg ; Final Value=90 deg ] with autotuned PID:

I have tried to change the PID and autotune it and see the results, but I think they were far worse than what I had done manually, because I am trying to make sense of something which I have visually, but the Autotune tries to compute the best values to accomodate the way the system is wired:

The simulation was getting stuck at 0% and the robot was rotating and moving at an incredibly unrealistic rate, even on a slowed 1/256x simulation speed.

I have went to revert the PID changes back, and then continued to make some other tests.

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

In this simulation, the robot tries to reacha 180 deg Angle for the first 0.5 second, and then after that time, it will try to reach 270 deg.

As seen in the video, the robot once more becomes marginally stable for the 180 deg, then becomes more unrealistic when the setpoint of 270 deg gets in:

The Output graph for this simulation is indicated below, with my interpretation of it being quite unknown because it seems to stay within 0 deg and 180 deg range for the Actual Angle of the system:

Test 4 [ Desired Angle Step Input: Time=1 sec ; Initial Value=180 deg ; Final Value=360 deg] with manual input [P - I - D]=[3 - 0 - 0.001]:

In this simulation I wanted to see more of that initial part as it looked like it would balance if I left it longer, so I changed the step time to 1 second with a 180 deg Initial Value, and then move the Final Value to 360 deg to check the behavior of the robot. From what I can see is that, it becomes marginally stable for that 180 deg, similar to the first test done, and then it becomes once more unstable, all this while behaving in a very unrealistic manner:

Checking the Output Graph for this simulation I could notice that it has a very similar pattern like the "Test 3" graph, meaning that it becomes marginally stable for the first step input time, in this case 1 second, and then when it changes setpoint to 360 deg, the graph doesn't follow the Desired Output and stays within the 0 to 180 deg range for some reason. Also another issue is that the Actual Output seems to see the setpoint as 90 deg but the Desired Output has a 180 deg, adding to the oddness of its behavior:

In conclusion I will try to do more tests and try to identify what is the problem and how I can solve it.