-
Notifications
You must be signed in to change notification settings - Fork 100
The plot window
PID-Analyzer generates a separate plot window per log. If there are several logs in a single file, these will be separated. Additionally, each plot is saved as a png image which makes it easy to compare previous results or share and compare with others.
The typical plot looks like this:
- Each column belongs to the denoted axis.
- The first row (a) shows the PID-loop input and the gyro signal. The loop input consists primarily of your stick input but also includes everything the firmware does to it before it reaches the PID-loop. This is necessary to make the analysis independent of your rates and flight mode.
- Following is a representation of the applied throttle (b). The red line marks the TPA threshold at which the dynamic PID attenuation is applied, if set.
The third row (c) depicts the continuous response for the whole log and is the heart of the analysis. Each column of pixels corresponds to a region of +-1s and is the momentary response at that time. The colours belong to the ‘viridis’ colourmap of matplotlib, reaching from 0 to 2. The response is calculated via Wiener deconvolution of loop input and gyro. Momentary deconvolution of non-periodic signals requires windowing of the signals: The chosen window function is a Hanning window of 2s length (hence the +-1s 😉)-
starting with vers. 0.5 this row depicts response vs. throttle. Especially useful to tune TPA!. Here is how to read it:
The color scale is ranging from 0 to 2 (dark blue to yellow), identical to the response line plot. If some throttle values are missing, there was not enough data. If some lines look jaggy, there often just was too little data for proper averaging (like here >40% throttle).
- In the last row (d) you see the averaged response of your quad. The light blue (or orange) cloud around the line can be interpreted as an error margin. The wider it is the less reproducible your quad reacts. Especially external perturbations during flight will cause a broader error. Artefacts of the line that are way smaller than the error usually should be neglected and have little meaning. If you did two rolls for example and the cloud is visible in two separate regions, the average will be somewhere in between. This means your quad behaved differently during both rolls and due to the limited number of samples it is not possible to determine ‘the most common’ reaction (of two things). With more samples (rolls in this case) the average will be more meaningful.
- On the right edge (e) in vertical orientation some additional information is printed. Here you find the model name and firmware version as well as possibly relevant information for discussion and debugging.
The response of your quad does not only depend on your PID settings but also on the quad geometry and setup. An H-frame for example usually has a higher moment of inertia on the pitch axis. This will be visible in a slightly slower rise (d.1) compared to roll even if the PIDs are set so an equally aggressive tune. That’s also the reason why pitch PIDs usually end off at higher values. Comparison of stretched and wide X setups would be interesting here!
On yaw the mechanics are significantly different: Any change in the angular momentum of the motors and props is directly transferred to body of the drone. This is responsible for the really fast response in yaw and will even be there if you spin your motors without props or try to fly your drone in vacuum. The second effect is the difference in drag of oppositely spinning props. This is more indirect, depends on the speed of airflow and affects the rotation of your drone on a lager timescale.
My interpretation of the small oscillations in yaw (d.4) is that they are causes by a magnetic spring effect (backlash) in the motors as they are on the same time scale as the rise time and change/disappear at higher average throttle (higher throttle --> more current --> ‘stiffer’ spring). Note that the D on yaw is always printed as 20 because it’s still noted like this in the firmware and logs, even though the yaw PID has no active D-term!
Unknown external perturbations make it impossible to calculate the response at that time. The artefacts at c.3 for example are caused by floor contact and ground effect during take-off and landing. Assuming these artefacts are of random nature, their influence on the final result should be minimal.
If there is little to no input as at c.2, the derived information is also meaningless and neglected for analysis.
There is more to come.