We are currently testing altitude mode with our self-built drone (FMUK66 and LidarLitev3). We notice that the odometry.z and local_position.z values are really inconsistent while flying, which causes the drone to not actually keep altitude.
The log file of such a flight can be found at: https://review.px4.io/plot_app?log=86cdc638-33f7-4d31-8ed1-12ff3ebd63b5 .
We were wondering if this can be caused by vibrations or can there be some other issue? We did set all the settings to use the Lidar as the height estimator.
I am new to this forum as well. I’m curious about this thread and will follow it as it develops. A few questions to clarify my understanding:
Is the LidarLite active and the data being fed to EKF ?
I see that the GPS altitude estimate is varying quiet a bit, especially in the initial and final stages, however the barometer does not seem to reflect this. Any hypothesis why ?
Since I can’t see the LidarLite data and assuming that it is being fed into the EKF, did you try increasing confidence on LidarLite and decreasing confidence on GPS and Barometer ?
I’m interested in seeing what others have to say about the vibration spectrum.
The LidarLite is indeed active and set as primary source of height data for the EKF.
I think the reason why the GPS height is varying so much, because the log I linked was an indoor test flight. About your suggestion to increase the confidence of the LidarLite and decreasing the confidence of the Barometer, this is something we thought about but didn’t really know how to do. Since we are pretty new to PX4 as well. If you would have any suggestions, they are more than welcome.
There are a few things on your log that seem a bit odd to me. First of all, it states that you are in stabilized mode, in which altitude is not controlled. Which would explain why the drone didn’t keep altitude.
Also, on your altitude plot there is no “Fused altitude estimation” line which is always present on our flights:
Not sure if this is supposed to disappear when using a lidar, but I reckon it indicates that the height estimator is really confused by contradicting signals and is unable to produce a valid estimate. Your horizontal GPS precision is around 5m… Could it be that altitude mode was rejected before arming due to no valid altitude estimate? If this was the case, there should be some warnings though, maybe you can review the .tlog file if you were connected to a GCS ? (Redirecting to latest version of document (master))
I can’t help you with the EKF fusion part, that’s outside of my knowledge
Yes, vibration levels are extremely high - look at the vibration metrics plot (high in the red zone) and acceleration power spectral density (all yellow - which is not what you want).
As the others told you already. Two problems here: No fused altitude estimation and excessiv vibrations. You may want to change the cutoff frequencies aswell. Therefore do a logging of the flight with high rate logging enabled.
We managed to get the vibration levels to around 0.025 by adding an anti-vibration pad underneath the flightcontroller.
My bad for uploading a flight log in stabilized, we also checked this mode out for the vibrations.
Even though the vibrations are significantly less now, the altitude flight mode still doesn’t keep height very well. We will try the high rate logging to see if we can get any more information out of this.
An altitude flight log with the new vibration levels is linked here: https://review.px4.io/plot_app?log=ec3e8195-1da1-4590-8b86-aa70ae362288 .
