This is somewhat time-sensitive, so I’d love any quick help (but I do understand that this is a volunteer-made program, and I’m so thankful for that )
I have an issue when flying in AltHold or Loiter. The throttle response is very poor and upwards acceleration is low. I’ve adjusted the parameters mentioned on the AltHold page to no avail, and sometimes, it’ll lower altitude even at full throttle.
When flying in stabilize mode, it does just fine – it can go upwards very quickly. I’m using a Mateksys opflow + lidar sensor. I understand it has a limited range, but I should never be able to go full throttle and have it dip.
I’ve linked 3 logs (4 MB limit). Log 16 is probably most helpful.
With just the barometer? No, I haven’t. I tried barometer operation around a year ago and had catastrophic results. Looking at log 16, it seems like the barometer altitude is incredibly noisy – not a good thing to trust althold to:
This is a good find. The altitude controller uses all sensors at its availability to fuse an accurate estimate. What that means is, the barometer data is still being fed into the altitude control (most likely as the primary sensor by default).
Personally, I would find a way to fix the barometer noise. Best way would be to enclose the autopilot a bit better (still some open gap for air) - mainly trying to shield it from propeller air flow and wind.
Secondary option (not recommended) to change EK3_SRC1_POSZ parameter to use LiDAR as its primary measurement (instead of baro). Would probably do this for SRC2 and SRC3 if those are set to barometer as well.
Also for what it’s worth there are thousands of users that fly daily under the default parameters for altitude source with and without a LiDAR. The key is to ensure minimal barometer noise by slightly enclosing it and/or keeping it well distanced from propeller airflow. Some open cell foam over the barometer sensor (similar to a wind sock on a microphone) may help as well if you can’t enclose the autopilot.
I cannot enclose the Pixhawk. It’s mounted on a small-ish 5 inch frame and the margins are very tight, which would certainly explain the baro noise. I also think that foam would likely not be enough, given the close constraints:
But I will try foam-ing it if the below doesn’t help:
It looks like the parameter you’re referring to is EK3_SRC1_POSZ: Position Vertical Source¶
I have changed SRC1 to use the LiDAR, but I didn’t realize that EK3_SRC2/3 were… even a thing. I’m guessing they’re essentially for redundancy? I’m willing to risk it ; I will try changing those to LiDAR.
The advice above is all good except for the suggestion to use Lidar for the vertical position source. It is really not a good idea to change the EK3_SRCx_POSZ to lidar unless you’re flying indoors with a completely flat floor (e.g. no tables, chairs, boxes on the floor).
From looking at the logs I think there are perhaps two problems:
the barometer altitude is suffering from interference during takeoff. Increasing the length of the legs may help too.
the lidar is not providing reliable distances. I guess you’re trying to use a very short lidar that is part of the optical flow sensor? I understand the temptation but these lidar pretty much never work and I think we have warnings on the wiki recommending a separate lidar. If we don’t I’m happy to add that.
I concur with @rmackay9 - I should have made it more clear that changing the EK3_SRC#_POSZ parameter was more of a last resort effort if you could not get the baro working and could 100% ensure that the LiDAR was always in range.
Because I am flying in a small indoor space, I decided that changing EK3_SRCx_POSZ was worth trying. Yes, I know that was really not recommended, so to anyone reading this in the future, carefully consider the risks.
Still, it did work alright. The sensor got pretty noisy past about 4ft up and wouldn’t fly much higher (and, no, this isn’t the max rngfnd parameter limiting it), but that was just enough.
I built this quadcopter for a CTSO competition. I just got back from the state conference and was able to qualify for the national conference, so I will absolutely be making changes to improve performance. I think the opflow sensor was limited because of poor lighting conditions, among other issues that I’ll figure out later.
Great thanks for the update. Nice to hear of a situation where using the rangefinder for the Z-axis position source worked! By the way, the EKF will fall back to the baro if the rangefinder fails so it hopefully won’t be dangerous at least.
)
