Hi all,
We’ve been doing some tuning on our very large (>400kg) quadrotor platform and looking at enabling AltHold.
Prior to these higher risk tests we want to make sure that the EK3 is accurately understanding the vehicle states (POSZ, VELZ, ACCZ primarily).
Vehicle configuration:
Flight controller
Cubepilot Orange Plus
Firmware
Arducopter v4.5.7
Vehicle
QUAD X
Sensors
Dual GNSS: 1x HERE4 blue, 1x HERE4
1x downward facing Benewake TF03 LIDAR
Other notes
Heading is being derived from moving baseline from the dual GPS
EK3 altitude source is set to GNSS due to very poor barometer data (down to size of platform/airflow/location of FCC)
EK3_RNG_USE_HGT is set so that we can use LIDAR for altitude reference in EK3 to hopefully mitigate GNSS altitude drift.
EK3 primary is using IMU[2] instead of [0] due to higher magnitude vibrations in IMU[0] and [1].
Problem description:
Before moving further with developments in AltHold and Loiter we want to make sure the EK3 is accurately representing what is happening to our vehicle. We’ve messed around a lot with different sensors and configurations to optimise our altitude estimations and we’re onto a good combination now. (The blip at 03:07 is due to us hitting a safety restraint)
We’ve also managed to quite severely filter the accelerometers to reduce the relatively low frequency (due to platform characteristics). The size of the platform means that setting the INS_ACCEL_FILTER down to below 5Hz feels acceptable due to the very slow dynamics.
The problem that we have is that our VELZ (or VD or climb rate or CRt or whatever you want to call it) still looks very noisy and is not reflecting reality as well as we’d like.
The magnitude of the noise isn’t totally unreasonable and early tests in althold have shown it tracking the desired climb rate reasonably well, but it definitely seems to struggle with small changes in the setpoint vertical velocity.
I’m primarily trying to understand if there’s anything we can do to clean this signal up. I understand that the GNSS is being used as the primary VELZ sensor in the EK3, and this also shows some of that noise, but in the ‘fused’ output from the EK3 it seems to have even more noise still.
I’ve tried some tests where I mess around with EK3_ACC_P_NSE, EK3_VELD_NSE, INS_ACCEL_FILTER, all of which didn’t have a significant impact on the output from the EK3.
The vibration levels are high, but by what I’ve read online, they are not of ‘unsafe’ or particularly bad levels.
My questions:
- Can the GPS VZ be improved? It almost looks like it’s suffering from vibrations. Does anyone know if the HERE4 units use their internal IMUs to generate the VZ output?
- Are there any parameters that will significantly alter the VZ output from the EK3? So far I haven’t found that any of the noise parameters had much of an impact on the velocity output and I’m wondering if this is normal…
- Is any of this actually a problem? I may be striving for perfection here in a scenario that is actually workable. We’ve seen a huge improvement in the quality of our data in recent hardware and configuration upgrades and maybe the magnitude of noise in the VZ is actually tolerable or within the expected magnitude.
Any insight would be greatly appreciated. Here is the log file that all of these images have been pulled from.
1 post - 1 participant