Precision Landing Help needed

My off the cuff guess is that the lens on the ir-lock camera has a different field of view from the standard. You’re definitely using an IR-Lock sensor and the lens that it came with? It’s not a PixyCam is it?

Thank you @rmackay9 and @Javiercerna.
Randy yes, its an original IR-LOCK, which was working well before connected to a Ph1 with 3.4 installed. The only change on the quad since then is a Ph2.1 and the upgrade to AC3.5 RC8.
Javier, you described the behaviour exactly.

wProblem found.
With AC 3.5, there is a new parameter PLND_EST_TYPE: Precision Land Estimator Type
which is default set to 1 (Kalman Filter)

Either the Kalman Filter implementation is bogus, or not compatible with an IR-LOCK sensor.
When you set this parameter to 0 (raw sensor data) IR-Lock works brilliantly well in Precision Loiter and Precision Landing mode.

@rmackay9 this needs to be documented in the wiki or fixed. With the Kalman filter enabled, the drone starts randomly bouncing in X and Y direction by several meters with increasing speed as soon as the beacon comes in sight. (see logs in my post above) At lower altitudes, this can become a serious issue and potentially harmful to people standing
Video showing the bogus behavior:

Yes , there is a name for that @Fnoop called it the Psychotic Wasp
PR are opened for that issue and there is no implementation yet , so you are better run RAW ESTIMATOR
For more, you can join the Vision channel on Gitter, https://gitter.im/ArduPilot/VisionProjects

1 Like

So you could have told me before :wink:
the Kalman setting needs to be disabled or at least documented in the wiki-
Seriously, this defect can turn into a safety risk when you enable precision loiter at lower altitudes with people standing nearby.

You can imagine when I tested it in my garage in GPS Denied with optical flow, when I set the switch , this Psycho Wasp started chasing me !!!
This is the day I called my garage the Thunder Drone.

You can read more details on @Fnoop excellent blog :
Maverick - vision_landing

How did you tune the exposure of your Pixy ?
I agree the EKF type isn’t the best but it doesn’t always behave like that.
Usually it happens when your Pixy lock multiple different targets and switch between them. The EKF then go into Psycho Wasp crazy killer mode :slight_smile:
Try decreasing the exposure setting at the minimum needed to see the IR beacon and try again.

Yes, it is dangerous, potentially very so, and no-one (capable) seems interested in fixing it. I agree the wiki should show a warning to the effect that it’s really a developer feature, or at least ‘buyer beware’. At least it’s turned off by default, so you have to know what it is and deliberately turn it on and configure it.
The EKF gurus have mentioned a potential rewrite of the EKF or turning it into a more generic library, so hopefully in the future we’ll benefit from that.

The problem in your video looks to be a tuning or latency issue. Actually there seem to be several bugs in the precland system, this is fairly low down the ‘dangerous list’. There is a lot more dangerous behaviour than this, when it randomly shoots off in random direction at high speed, or what looks like the attitude correction is really wrong (usually due to incorrect latency) and it corrects in the opposite direction (usually into a wall or tree, in my case).

@fnoop thanks. Actually the fix is easy, just set
PLND_EST_TYPE to zero (raw sensor data) in the parameters default and everything works just fine.

@Kiwa21 no has nothing to do with exposure settings. My pixi is well tuned and was ok with AC 3.4 before.

I flew a number of batteries today w/o any problems with est_type set to zero. Even under gusty wind conditions the copter stood precisely in the air.

An example of precision loiter followed by precision landing working fine now:

@fnoop @Kiwa21 @Javiercerna @ppoirier
Thank you for your comments!

@mtbsteve Thank you for your investigation into this! Unfortunately, I haven’t had much time to test the EKF code.

It is very helpful that the devs have included a ‘estimation type’ parameter (i.e., PLND_EST_TYPE). If there is an issue with the EKF estimation, the underlying issue can be difficult to diagnose. So it is good to have the ‘raw sensor data’ alternative (PLND_EST_TYPE = 0).

@mtbsteve

Thanks again for your work. We owe you! If we sent you a free SF20, do you think you would use it?

Most of our commercial precision landing projects use a Lightware rangefinder (SF10/A, SF20, LW20), due to their high level of performance, and robustness against IR interference.

Lol , if @mtbsteve dont want it, I’ll take it :wink:

1 Like

If they’re going free like candy I’ll have one too :wink:

1 Like

@ppoirier @fnoop
:sweat_smile: Ha. It has been claimed

I would like to thank for this post since it helped me to configure my copter correctly to use IR-Lock with the Cube. After sunset I tried to fly the copter in windy conditions to test the sensor. Wind is blowing hard from right to left, you can see the copter inclination to the right to keep the aircraft in position. Takeoff was in Stabilize, then Loiter, then Land. For such conditions, precision landing worked flawlessly. Thanks @ThomasSFL and the Team!

Great work @samucs !!

We owe you, both for this video and for your wiki material that I still need to upload.

The video does a great job of showing off the latest features in the precision landing controls code, especially the variable ascent/descent speeds corresponding to the precision landing accuracy.

If you can post your .param file to this thread, that would be great. It seems that many people are having trouble with the PLND_EST_TYPE. This parameter should probably be set to ‘0’ in many/most cases (corresponding to ‘RawSensor’ estimation, rather than ‘KalmanFilter’ estimation).

Best,
Thomas

Hy

@ThomasSFL I would like also to report several very successful landings like the three landings shown below.



However we still like to improve the device and we hope that we can work together.
In conditions where the sun is really strong we still have several landings where the IRLock failed to recognize the beacon.

One of the main problem is that we don’t know during descent whether the IRLock has recognized the beacon or not.
I know we can’t transfer this via MAVLINK since the protocol has no more room for such information.
So might it be possible to directly get this info out of the PIXY via the additional pins. Like a HIGH or LOW signal just representing found beacon or still don’t see beacon.
That would immensely improve the development and error handling during flight without looking every time after landing at the logfile to see how well the beacon has been recognized.

The HIGH or LOW signal can either be measured by the PIXHAWK directly or by a companion computer in my case.

So is the firmware that is currently on the PIXY opensource can I have a look and even change the suggestion by myself?

Andy

Hi @Andreas_Krauchi

The best first-step is to upload the log files from your precision landing tests (especially the ones in which you suspect poor detection performance). We would like to analyze them.

We typically do not receive concerns regarding MarkOne detection performance, even in bright sunlight. So I hope we can diagnose and solve what may be causing the issue.

Here is a playlist of videos demonstrating reliable detection in bright sunlight conditions.

Best,
Thomas

Hy @ThomasSFL

We have hundreds of log files however they don’t help you at all since we have around 80% good landings and 20% bad landings at the exact same spot exact same settings BUT only weather has changed (earlier in the morning, during noon, cloudy conditions, during sunset, during high and low temp etc.)
The problem we’re facing is that the landing pad made out of wood probably reflects a portion of the IR at certain angles, temperature etc. HOWEVER to further investigate this we need a direct feedback from the PIXY whether the IRBeacon has been detected or not. So we can hover for 40min above one spot of the landing pad and wait while the light changes etc. and see how the detection of the beacon changes. At the same time we can change the ground and more refection or put some plackets etc.
That’s why I asked you if you can help us to get this feedback out of the PIXY (probably change the firmware or open the firmware for us that we can change it ourselves) but you haven’t yet answered this question…

If you like to talk to use directly I sent you also some E-Mails over your website we’re a drone company trying to implement this system for commercial flights etc.