Did you change the altitude main sensor in EKF?
I did not change anything at the EKF
EK2_ALT_SOURCE 0
EK2_RNG_USE_HGT 70
I would set
EK2_RNG_USE_HGT to -1
Thanks for the hint.
Unfortunately, the problem isn’t solved.
(3.6.10-rc1 otherwise works fine)
Throttle=blue, Baroalt=red, rngfnd-alt=green showing “1”, if above range.
Mode Poshold
it this a TFMini Problem? I also encounted once… my drone was expected to reach 6m in auto mode, but when it reached about 5-6m, it suddenly climbed no stop…
I’m curious, so I try to investigate. This is the plot that is interesting me :
From what I understand, RCIN.C3 (purple) shows that the order is to climb, and the altitude is following this order. But what I try to figure it out, is the moment when the Lidar stop to send altitude, RCIN.C3 is around 0 (1500), but it goes like a skyrocket. The transition seems to be the cause.
The altitude estimation should not use the lidar above RNGFND_MAX (300) * RNG_USE_HGT (0.7) = 2.1m. And the phenomenon happened at 10m according to the lidar and 16m according to CTUN.Alt …
The barometer (green) is coherent with the lidar (yellow), but there is a serious gap between altitude sensors and the CTUN.Alt, I don’t know why …
Besides, it doesn’t seems to be a high vibration issue.
@imnobodyet : Can you provide your log to have a look ?
It seems that you are facing what is described here : https://github.com/ArduPilot/ardupilot/issues/9616 and this one https://github.com/ArduPilot/ardupilot/issues/4697
you mean 3.6.10-rc1 fixed the problem when rangerfinder output abnormally, like a constant low value?
Im’ also experiencing this,
From what I can see and guess the logic with sort of reverse engineering:
ALTHold with TFMini - uses the TFmini as main alt source
Mission with TFMini with relative height - The TFMini is completely ignored only baro is used
Mission with TFMini with terrain for height - Again like althold TFMini is used as main alt source.
Now it gets interesting - On a terrain mission if you go out of the TFMini range (about 4.5-6m outside) arducopter complains about “no terrain data” and failsafe.
No way that i found to feed terrain data, my guess is WPNAV_RFND_USE makes the TFMini the only input for terrain and arducopter can’t make the switch to regular terrain data beyond rfnd range.
On the simulator in a mission there is no alert about “terrain data” and on a terrain mission going up beyond rfnd range it will just keep going up forever.
Now the best part: on a hybrid mission with relative and terrain waypoints (mission planner doesn’t support this although height type is set per command and not per mission)
On the simulator it is sometime posssible to start mission with relative, going down to terrain from beyond rfnd range no alert about height is issued and arducopter will stop at the specified height which i set inside the rfnd range, but in real life it behaves different it will issue “no terrain data” just as I move to a terrain mission command when it is currently beyond rfnd range.
(in the simulator this works even in a negetive relative to home height)
Needed - Allow mission planner to set height type per command (possible in qground control)
Allow to go down to a height inside rfnd range from a height outside of rfnd range.
Sorry for the long post 
I‘m flying a lot of missions with terrain following, using a SF11 with WPNAV_RFND_USE=1. I can confirm, that if the actual height above ground exceeds RNGFNDx_MAX_CM, Arducopter goes into failsafe and aborts the mission. Have you ever tested this with TF mini? Maybe it would help to find the problem.
By the way… There is already a issue to allow the mixture of rangefinder values and terrain data: Copter: allow terrain following in Auto to mix range finder and terrain database altitudes · Issue #10257 · ArduPilot/ardupilot · GitHub.
But one question: you wrote
Till now I thought that ArduPilot terrain following is not supported by qGroundControl at all at the moment? I had a short communication with @DonLakeFlyer some time ago to find a way to allow the use of a rangefinder in qGroundControl missions, but as far as I know, it is still not possible?
Bg,
Stefan
This looks like a bug to me in our TFmini driver. It looks like the range is being reports as 1m in the logs when the lidar is going out of range. I’m pretty sure I have a TFmini around so I’ll try and recreate the problem. I think you could likely recreate the issue yourself as well by pointing the lidar at the sky and see what it reports in the ground station.
EDIT: Ok, I see this TFmini is setup to use the Lightware Serial driver and this is driver has a bug in it in Copter-3.6.10 (and earlier). We just discovered (and fixed) this bug a few days ago and it will go out with Copter-3.6.11. Sorry for the troubles! A solution may be to use the TFmini driver (set RNGFND_TYPE = 20) although I’m unsure what changes that will require in the sensor itself.
By the way, there’s some discussion above regarding the EKF parameters in particular EK2_ALT_SOURCE and EK2_RNG_USE_HGT. The EKF is not involved in terrain following. These two parameters should nearly always be left at their default (see warning on this wiki page and this wiki page).
Sorry to be forceful about this but this misconception comes up constantly and I often see people giving bad advice about modifying the EKF parameters in discussions about terrain following… although the advice above is to set the parameters to their defaults which is good advice.
Very true! I have never changed anything in the EKF settings, and terrain following with the SF/11 works very good - loiter and mission auto.
At the moment, I’m flying at 40m AGL above wineyards with terrain height differences >40m. And it works perfect.
1 Like
Thanks for solving the problem @rmackay9 .
With 3.7.0-dev(6b1046f0), the TFMini driver now reads 100 meters if the laser-range is exceeded (instead of 1 meter as before). The height control now works when exceeding the laser-range.
1 Like
How can we have a mixed mission with some out of TFMini range waypoints?
I want to fly high somewhere and then make my drone hover at 2m from the ground.
The current state of QGC and support for MAV_FRAME_GLOBAL_TERRAIN_ALT is as follows:
- QGC does not support sending terrain heights to the vehicle
- QGC does not allow you to create a new mission which has waypoints using MAV_FRAME_GLOBAL_TERRAIN_ALT
- If you download an exising mission from a vehicle which is using MAV_FRAME_GLOBAL_TERRAIN_ALT the QGC ui will work correctly and allow you to edit the mission.
I could allow ArduPilot missions to allow the usage of MAV_FRAME_GLOBAL_TERRAIN_ALT on new mission but my concern is confusion over not supporting sending terrain heights to the vehicle. Although currently QGC will warn you if you upload a mission with MAV_FRAME_GLOBAL_TERRAIN_ALT about the terrain height ot vehicle not supported thing.
I’m hoping that soon terrain height vehicle sending support will bubble to the top of my list. Specifically because I want to change where we are getting terrain heights from anyway. So while I’m in there might as well do the rest.
For me (and maybe some others), this would be nice, because I know what I‘m doing and my UAVs are equipped with range finders.
But of course, generally you are right. Maybe that can be confusing.
The whole terrain following thing seems to be confusing to many users, as the lot of irritations about ekf settings and so on are showing.
How this is solved in the „yuneec version“ of QGC? Anyone who knows?
Yuneec runs PX4 not ArduPilot. It only supports the “(Abv Terr)” version of Altitude which has the heights manually set to be the specified amount above terrain.
I posted this in the Lidar lite v3 offset value issue thread, but this thread seems to be more alive.
" I have just purchased a Garmin Lidar-Lite V3 with a manufacture date of 2019/02. I have used a Maxbotix sonar on a Tarot Iron man 650 with a pixhawk 2.1 Cube (Black) (Recently replaced by Profinc). I replaced the sonar with a TFmini which sorta seemed to work, but there was confusion around the rangefind max point. I have experienced runaway climb in AltHold. I thought the greater range of the Lidar Lite V3 would help, but this discussion has given me pause. The mission for the craft is sheep herding in AltHold, and if the AP is suddenly told that Alt has jumped up, it could be very dangerous. This discussion seems to be circular among several venues and threads with no apparent resolution. Does anybody know where it stands?"
Phil