Servers by jDrones

Autolanding multiple code issues. Condition for UAV landed?

(Pompe Cukor) #1


Hi guys. I would check the code myself if I was able to, but its all chines to me. As you know buy now, I setup and tune a new pixhawk airplane almost every week. Do multiple take of and auto landing test before shipping them. I use Lightware lidar and reverse thrusting on all. Quite confidently can say, more than anyone here. I am guessing most DIY people would land in FBWA. However my planes are mostly for people that cannot fly.

This way I can really noticed discrepancies that I can only associate to coding. I will list them here and hope to get some input. I can add logs and video too, I have a few of those. In the mean time just take it from me, from performing 6 auto landings per day that these ARE issues.
Again remember that I have both reverse trust and lidar use enabled. Just mentioning this as it might only be related to this particular subroutine of the code. PS this is the reason I cc MagicRub. Firmware is 3.8.2.

  1. Land then disarm. This function only work 50% of the time. I wonder what the condition for this is. That is when does the UAV consider itself landed. I have a feeling that this is related to No2. issue as well.
    I have this set to 10 seconds. About every second landing on average, the plane does not auto disarm. Even if I wait 5 minutes.

  2. Lidar is almost more hassle than not. I thought I knew how it worked, but now I am no longer sure. So would appreciate some input. I use Lightware, which so far has be incredibly good/correct with the AGL. So that is definitly not an issue. I was under the impression that if lidar is available, and setting is set to use lidar alt for landing, then it is 100 used for landing. Now I have a feeling that it is not really the case and only used to correct offset or something like that.
    The reason I say this is that on multiple occasion the motor/prop would still spin even after the plane hit the ground and the lidar is showing 10cm AGL. Mean while flare is set to 2-4m (depending on UAV weight).
    I was under the impression that throttle is basically 100% disabled after passing the flare point, what is when lidar gives AGL lower than 2-4m (whatever is set in the parameters).
    This point I think is somehow related to the first one. It seems to me that for some reason a “marker” or “milestone” is skipped for whatever reason and the UAV does not realize that is is on the ground, static.
    If lidar use is enabled and lidar is providing data correctly. Then why would it not consider itself landed when AGL is 10cm?
    The curious thing is that the messages reported in the mission planner, would say, lidar engaged at… and pre flare and flare and so one. But still it would land while stll trying to fly. Making me think that it does not consider it self on the ground yet.

  3. This has been mentioned before and MagicRub was kind enough to open a issue on github for this. So I am just repeating. If there is the slightest of elevation which would make the new landing slope 5 degrees different from the old one, then the offset is corrected in the barometer and the landing is repeated. The problem is that the offset correction is taken from a bad place. That is not the touch down point, but rather somewhere on the approach. So the repeated landing in cases tries to dive into the ground. Sort of like the scene in Die Hard 2 :frowning:

I will add some concrete examples shortly. In the mean time, I am really interested in the answer to question one…

Thank you.

(Pompe Cukor) #2

Upon closer look in the logs. What I see is the most, if not all of these occasions, when the UAV lands and then throttle up or keep spinning the throttle. It shows a message of “Do_land_start: 1”. That is wants to restart landing for some reason. Even thought it is already sitting on the ground.

I will upload dataflash of three landings with same symptoms.

(Pompe Cukor) #3

EDIT:…Removed other these logs to avoid confusion. See log in the 7th post, just above the video:

(Pompe Cukor) #4

(Pompe Cukor) #5


I think I figures out the problem finally. This has been driving me crazy.

On normal lidar/rangefinder assisted landings, the lidar is engaged at a certain stage and is used for the landing instead of the barometric alt (correct? or is is just used for validation?).
You can see a message in mission planner and the telemetry log too “Range finder engaged at…”

This issue is. if the landing is restarted based on parameter: LAND_ABORT_DEG
Then a new “virtual” ground level is saved on the AP. This is is called Land_AltO. This if obviously an offset from the real ground level. Problem is that this many times is set incorrectly, for example it there is a and elevation of even just a tree under the plane at the time is marks to use this lidar.
Then when coming around for a new landing, it would ignore everything and use the sum of the Barmetric alt and Land_AltO to decided where the ground is. Completely ignoring whatever the lidar tells it, all the way to the end of touch down.
That is the “range finder engaged” phase gets skipped entirely on the second landing attempt and this is the problem. This is what I see from all my logs that ended with a restart. And this explains all the problems that happened there after.

As you can imagine, it the offset was made incorrectly. Then you have a guaranteed crash on the second landing even thought the lidar keeps giving correct altitude az 50Hz update or so.

so long story show, on the long run this issue will of course solve this more or less, but for a more immediate solution I think if would be good to add a line to start to use the range finder again on the second approach and save a few people from unfortunate crashes.

(MagicRuB) #6

I looked at the log, I’m seeing the message. Can you help me out with the timeline a bit? Show me 1 log (instead of 3) that shows the problem. I’m also seeing multiple flights in a single log too. You do a long flight, come back and land. Then takeoff for a short one and do the abort there.

(Pompe Cukor) #7

Thank you for taking the time.

Here is a log that explicitly shows the problem. Just look at the end, the landing.
Yes, I do multiple flight when testing. Sorry…
Just look at the end of this one. I also explained in the video, maybe you did not get the message, so I will post it here aswell.


(Pompe Cukor) #8

I think we can all agree that the final flare is missing during the second attempt.
It is set to flare at 4m (not time based), yet does nothing, even tough the lidar is spot on.

As I said, I don’t know the code (what is actually supposed to happen when the message says, lidar engaged at Xm), but the issue is obvious. Something is wrong when AltO is changed in flight. And the flight protocol only takes AltO+Baro as the reality and not the lidar.

(Andras Schaffer) #9
  1. Rangefinder does engaged at the second landing. (See message at 1195 sec)
  2. Alt offset was set to -6.659 meters, so your landing point altitude moved to -6.659m
  3. Flare alt was set to 4 meters.

The issue is that during the landing the difference between rangefinder and baro alt slowly decreased to almost zero. So when fused altitude (and real as well) become zero, you were still 6.659 meters above the modified landing point altitude (AltO moves all mission point altitudes). This is why your plane never went to flare stage.

Based on the code, it assumes that the offset will remain constant during the second land. (doesn’t use rangefinder alt, but use it as a correction to baro alt).