Yes, if you provide a log file, somebody should be able to look at it.
I just did another flight to get a .Log file.
I did a flight in Loiter mode at 2.5m where there is not a problem then after I programmed a mission in AUTO mode ( Terrain at 3m ) which does not work .
File Log : Fichier .Log
Can you please send me your waypoint file? If you prefer email, PM me.
Je n’avais pas enregistré le fichier Waypoint lors de ce vol, mais voici presque une copie du vol demandé très simple:
Ce qui est vraiment bizarre, c’est qu’en mode Loiter, cela fonctionne parfaitement, je pensais que le mode Auto utilisait le mode Loiter pour le vol, non ?
No one can help me, please ?
I’ve looked at your log. Here is how the altitude data looks like:
The red line is the rangefinder reading
The green line is the desired altitude based on the rangefinder reading (notice it disappears when you switch to AUTO)
The orange line is the altitude calculated by the EKF after fusing the different sensors (baro and rangefinder)
The blue line is the altitude data calculated from the barometer.
You can find that altitude data in the CTUN message (described in details here)
First thing that’s odd is that the green line (desired altitude based on rangefinder) disappears when you switch to AUTO. I converted your .bin log into a .log file to take a look at it packet by packet (with a simple app like Notepad). Here is what I see:
DSAlt becomes NaN when AUTO is activated.
My guess is it’s because it’s trying to use the SRTM terrain data that seems to be missing here):
@line = 37861 (in LOITER mode): note the “NaN” is TAlt , “2.480771” is your desired rangefinder alt in loiter mode:
CTUN, 319143978, 0.1584907, 4.422665E-05, 0.1564572, 0.1453676, 6.024798, 6.140826, 6, 2.480771, 2.56, NaN, -8, -7, 80
@ line = 67194 (in AUTO mode): your desired rangefinder alt has become NaN (=TAlt) which might explain why it’s not following rangefinder readings anymore:
CTUN, 545619893, 0.1468592, 6.400049E-05, 0.1446142, 0.1449793, 5.574391, 6.29668, 6.6, NaN, 2.26, NaN, -72, -71, 80
In your waypoint file, try changing “Frame” from “Terrain” to “relative” to see if that changes anything.
Another option: based on the graph above, the EKF relies on the baro data and seems to not give much weight to the rangefinder data. You could try to play with RNGFND_GAIN (increase it) see if that has an influence.
If that doesn’t work there are other options we can look at.
Thank you Clem,
I’m going to redo a flight by putting “Frame” to Relative and I would post the new Log file.
I thought that the RNGFND_GAIN only acted on reactivating the drone for this reason that I did not touch it, I will also see if this has an effect .
I have a understanding question:
I always thought, that during terrain following the rangefinder values are NOT fused tinto the EKF?
Maybe we can ask @rmackay9 to bring some light into this question?
Thank you very much!
1 Like
I didn’t have time to do it this week, I hope to be able to retest this week.
Previously I had tested with Relative mode but the rangefinder did not work either.
I just tested in Relative mode here is what I get :
Then with the mode Terrain and the RNGFND_Gain to 0.8 :
And with the RNGFND_Gain to 1.2 :
As we can see as soon as I activate the Terrain mode the Rangfinder is cut in Auto mode whatever the value of the RNGFND_Gain.
I had a look at the log and I think the issue is that the rangefinder’s maximum distance has been set to 7m (RNGFND1_MAX_CM = 700) but in the mission, the altitude above terrain has been set to “8”. This will lead to a terrain failsafe being triggered.
Extra points to @fingadar for remembering that the EKF is not involved in terrain following!
It is strange because I make in general my tests at 3m in height, I enclose the last .log file 2020-05-2710-32-32.log which corresponds to the last test to be carried out in Frame Terrain and with the RNGFND_Gain to 0.8.
The problem is still present yet I am much less than 700cm from my Rangefinder_max ?
I’ve had a look at the log and it is a bit odd that it’s not climbing to 3m based on the rangefinder. Instead it seems to be descending.
Some things that would be good to try:
- disable BendyRuler avoidance by setting OA_TYPE = 0
- revert to 3.6.12 (or similar) to see if the proper persists or if this is a regression
By the way, a few other things:
- RNGFND_GAIN has no effect in Auto mode. It’s only for Loiter, AltHold, PosHold etc.
- The CTUN.DSalt becomes NaN in Auto mode. This is a known issue that we hope to resolve in future versions. In case it matters, it’s not really a bug, it’s just that the way AP doesn’t terrain following (aka surface tracking) is different in autonomous modes (like Auto, Guided, RTL) and more manual modes (like Loiter, PosHold, etc)
EDIT: thinking about this more, I’m pretty sure this is an issue in BendyRuler that we’ve fixed in Copter-4.0.4-rc1 that has just started beta testing.
2 Likes
Thank you Rmackay9
I just did a test this morning and everything works fine as soon as I deactivate BendyRuler, it’s perfect !
1 Like
Would it be possible to activate the RNGFND_Gain parameter also in AUTO mode ?
Thank you
@rmackay9 , There is still an issue where the altitude RangeFinder does not work in auto mode when OA_TYPE is enabled with BendyRuler.
I have tested it on ac 4.0.5 stable and 4.1.0dev
Is there any other solution?
Hi, Sir good morning,
Your problem is resolved or not sir. I am also working with this feature only now. if you are ok with will resolve this issue.
Thanks and regards
Mohan
Hi, Sir good afternoon,
follow this link (https://ardupilot.org/copter/docs/terrain-following-manual-modes.html#terrain-following-manual-modes).
set
- CHx_OPT-75(surface) (place chX switch at low, and make mission)
Note: reduce the OA_MARGIN_MAX as possible to your drone.
Try with different alt like(2,3,4 etc)
Thanks and regards
Mohan