Differences

This shows you the differences between two versions of the page.

--- rip_report [2016/04/15 23:57] – joaomatos
+++ rip_report [2016/04/21 21:04] (current) – joaomatos
@@ Line 124: / Line 124: @@
 {{::final_structure.jpg?direct&500|}}
+   * **Day 6**: I'm trying to find what is limiting the balancing on the NQC code. The Simulink code is running smooth ( see video ). I'm using the same algorithm on the NQC code. What i did today:
+   * 1-> I tried first with my original code to do a little gain tune , because the Simulink gains did not work with the NQC code.I could not tune the 4 gains to improve the balance the way it was needed .So i start to look for possible mistakes on the code.
+   * 2->Testing the interval between loops: Using a single task and a single function ( void ) returning the pendulum and motor angle and position the time between loop was 2.2ms . Using two tasks , one for balance and one to get the pendulum and motor angle and position the time between loop was 5.8ms. I'm now using a single task to balance and two functions ( one to handle the pendulum variables and one to the motor variables). The time between loop sounds OK .
+   * 3->I checked if my references was the same of the Simulink model (Positive/Negative turning direction of the sensors ). It was everything OK , so in theory using the same gains the balance should be pretty much the same.
+   * 4->Checking the input sent to the motor: I made some test and i observed that even using the same gain to the Pendulum position and the motor position , the input sent to the motor was a little different ( maybe the precision of the variables -float on the NQC and double on the Simulink - and the rouding methods - the input sent to the motor is integer.
+{{::capturar.jpg?direct|}}
+  * 5->I tried to fix the input issue: first i tried to do a gain tune to make the two input to be the same on the same conditions ( same motor angle and pendulum angle) - NO SUCCESS , always a little difference (1~3). But at least the difference got a little smaller.I had to change some variables type ( ex: on the Simulink , the block that get the angle send an integer value , and i was using a float variable on the API to get the angle ( using this sensor from mindsensors the API is the same as a regular motor (MotorRotationCount).
+  * 6->With the time between interval OK and the Positions gains "OK" , i tried to do a gain tune again to make the balance better - no major changes. So i jumped to the next problem , the velocity calculation.
+  * 7->I started to change the methods to calculate the velocity. I) using the dt as the CurrentTick - PreviousTick (API's from the Bricx program ) II) Calculating dt with a function to handle the time between loops ( similar to the code of the WhipBalance that we used on class ). III) Calculating three values in a row and taking an average. IV) I'm now working on using the average of previous values (similar to the code of the WhipBalance that we used on class), i will use an average of 5 previous values to calculate the velocity.
+ **USING SIMULINK**
+ {{youtube>QZF4qI7ozn0?medium}}
+**Day 7:**
+  * I'm now calculating the velocity using the average from 4 previous values and the balance got significantly better but still not as good as running on Simulink (using the exactly the same gains). The balance can get better with a little gain tuning - which i'm trying right now. I thought that the interval between loop was OK , but i think this can be causing the Simulink to balance better ( see the two videos on the Building Tutorial Tab ) .Another thing that is different is the motor behavior . Running on Simulink we can't notice the motor "input spikes " , it accelerate and break very smoothly . Runing on NQC we can notice the motor "input spikes" . For example , using the Simulink it looks like if the motor was turning foward with power of 40 and it needs to change to 60 , it will accelerate and break to reach the new value , and using the NQC code it looks like if the motor was turning foward with power of 40 and it needs to change to 60 it will change from 40 to 60 instantly - so we can notice the "input spike" . There is an API on the Bricx that can control the OnFwd and OnRev using PID constants, however i tried to use it and it does not change the balance at all.
+----
+----
+**WEEK 7 **
+ Now that the NQC is running smoothly the next steps are:
+  - Finish the swing up control.
+  - Fill up the spreadsheet with the necessary parts for the RIP Box.
+  - Do the a detailed version of the building instructions
+  - Do the step - by - step coding in the Bricx Command Center
+  - Explain the theory behind the NQC code
+  - LQR Theory - how to find the gains