Is there something like pitch / roll compensation for lidar measurement in copter 4.0 ?
If so, my feeling is, that it doesn’t work: When i pitch or roll, the copter looses height although the motors would be powerful enough to compensate this.
Yes there is and it is enabled. But there is EK2_RNG_USE_SPD: Range finder max ground speed if your speed is above it then it will not use rangefinder.
I know this parameter. It’s default is 3 m/s and i’m flying indoor, so i don’t think i can get beyond this limit
Then let’s see a flight log. That will show the truth.
1 Like
Here is a log. You see clearly a loss of altitude twice after roll or pitch is applied.
https://drive.google.com/file/d/1Kn3r4jZPgV9tYkkRMO2mx5YrPfcjjZOK/view?usp=sharing
It seems you forgot to set ek2_alt_source to 1. EKF uses baro as a primary alt source (ek2_alt_source = 0) plus take AccZ into consideration as well, which shows upward acceleration due the strong pitch and roll.
I choosed baro as primary alt-source as advised here:
http://ardupilot.org/copter/docs/terrain-following.html#terrain-following
Altitude drops also when pitch or roll is used not that strong, so i think AccZ is not the problem here. EKF should be able to handle that anyway.
I did not observe this issue in 3.6.x with VL53L0X lidar but only in 4.0 with VL53L1X. Sure that tilt compensation is enabled in that driver ?
Tilt compensation is not in the driver but in EKF.
Using baro indoor is not a good idea.
1 Like
The EKF is definitely having trouble estimating altitude while you’re doing your crazy maneuvers, but not because of the rangefinder:
Here, you can see that the rangefinder reading (red and green) is not changing much as you maneuver, so the angle compensation is working. But the altitude estimate climbs a lot, even though the rangefinder and the barometer don’t show that. You don’t have GPS, so the only remaining source of altitude information is the accelerometers, so they must be the culprit.
Where did you mount your flight controller? If it is not near the center of gravity, this may be caused by the centripedal acceleration from your maneuvers. If the FC is mounted above or below the CG, you can try changing the INS_POS1_Z parameter to tell the EKF to expect these forces.
There’s definitely some coupling that is causing pretty big Z accelerations while you pitch and roll:
That said, I’m not sure how “normal” it is to see ±3 m/s^2 in Z while doing fast maneuvers like this.
Thank you Rick for your detailed explanation.
Maybe my flightcontroller is a bit off the CG, 3-4cm.
If i read this , i’m not sure wether setting INS_POS1_Z would bring an improvement …
Quote: “The compensation is only partial because ArduPilot can correct the vehicle’s velocity and position estimate but it does not correct the acceleration estimate”.
I’m still wondering, what causes that negative acceleration the EKF obviously assumes: My flight maneuvers, as crazy as they may be, only lead to positive AND negative Z accelerations, which should sum up to zero in very short time…
The Z acceleration from rolling and pitching will always be in the same direction, regardless of which direction you’re pitching, so it won’t add up to zero. The direction of the Z acceleration is determined by whether the IMU is above or below the CG.
This appears in your log, as the oscillations don’t seem to be centered around -9.8. The lower peaks hit -12, while the upper peaks are only -9.0 or so. That would definitely make the EKF think it’s accelerating upwards.
Ah, I didn’t realize this (I’ve never actually used the position compensation). Too bad. That said, you should only see this kind of error during crazy repeated maneuvers like in this log. I’m pretty sure the EKF will deal with sharp maneuvers just fine as long as they aren’t repeated for a long time.
Before trying to find complicated explanations for this altitude behaviour with EKF stuff, let’s first try to diagnose this obvious : your barometer. It is notoriously known that these small barometer chips are very sensitive to light and air dynamic variations. Because of your manoeuvers, the air flow on you baro varies from different angles. This problem of altitude loss when moving the vehicule because of air flow on the baro is known for a long time. The way to mitigate this is mechanical : ensure you cover your baro with foam (that let’s air through), cover the baro to avoid light on it, encase the baro within two discs (that assumes the use of an external baro as you can’t do that with the autopilot) as described here : https://diydrones.com/forum/topics/effects-of-frame-design-on-barometer-performance-and-all-other
Hugues, if you look at the first graph in Anubis’ post, you see that baro-alt (CTUN.BAlt) does not increase at all as well as CTUN.SAlt
So the only explanation for the increase in CTUN.Alt are the accelerometers as Anubis said.
But i have another question for you:
I’m using an external baro, so i could do the mod described in your link quite easily.
Do you have experience with that ? What diameter should these plates have and what distance ?
I can’t find the topic back but if I’m not wrong, Leonard Hall did this experiment. If he reads this post, he might post his link again.
Am I correct that a UA that went through Autotune successfully does not require to set INS_POSx_Z?
During Pitch and Roll autotune, it will learn.
I… don’t think so. These values are based on the hardware configuration of the drone, so I don’t think Autotune will try to estimate them. In fact, if your flight controller is not near the CG of the drone, I’d strongly recommend setting these values before doing Autotune.