Precision Landing Help needed

I am trying to get IR-Lock to work on RC7.
I see there are plenty of new parameters introduced with 3.5 - however I cant find a description yet in the wiki. In particular:
@ThomasSFL pointed me to the Arducopter developers to seek for assistance here.

1 Like

I guess you looked at this:

And here are the details concerning PLND_LAND:

As for Channnel 7 , you might refer to precision loiter== mode 39?


Super helpful- thanks!

Next question about the PLND_BUS parameter:
what does

  • default bus
  • internal I2C
  • external I2C
    mean and what is the difference between internal and external I2C?

My IR-LOCK seems only to work when I set it to “internal I2C”, otherwise I receive a Bad Vision error during startup

Take a look at this

1 Like

Thanks for the hint. Does this mean that IR-Lock and precision landing is not supported with the Pixhawk2 and AC3.5 since it uses the external I2C bus?
@OXINARF can you help here please.
Is there anyone who successfully uses IR-Lock along with the Ph2 and can speak about what setting they use?

Hi Steve,

IRLock should work ok on the PH2. It’s just that the PH2 has 2 I2C ports exposed so it can be connected in a couple of ways. I think the default I2C port is part of the GPS port on the PH2.

Got it working with RC8.
Therefore I connected the IR-LOCK to the I2C2 port of the Ph 2.1 and I set the PLND_BUS parameter to 0 (default bus).
It works perfectly fine with that setup in LAND mode, however I dont get it working in LOITER mode.

@rmackay9 I recall one of your videos showing the IR-LOCK in action with a drone following a rover in loiter.
What do I need to do in order to get the IR-LOCK precision landing also enabled in Loiter mode?

Got it finally working in Loiter.
Trick is to configure a switch on one of the servo channels and set the channel option CHx_OPT to 39

Next problem:
the copter recognizes the beacon, but starts to oscillate in roll and pitch and to bounce by 3-5 meters over the beacon as soon as I turn on PrecLand Loiter. The IR-LOCK is mounted correctly. The copter is well tuned, and rock stable in all flight modes otherwise.
Any idea anyone?

1 Like


Could you post your flight log? You need to look for the pX and pY values in the PL entry. This helps for both Loiter and Land modes. Also, what sonar are you using? And at which speed are you descending? I found that at lower landing speeds the IRLOCK becomes more accurate.



Here are the dataflash log files of Loiter and Land mode testing. The graph shows the heavy oscilliation in pX and pY direction in PrecLand Loiter as well as land mode as soon as the beacon is in range. Any insights are appreciated - Thanks!
Copter 3.5 RC8
LidarLite connected via PWM (works 100% smooth)

Precision Landing in Loiter mode:

120.BIN (4.0 MB)

Precision Landing in Land mode:

114.BIN (1.2 MB)


It seems a little weird that the IRLOCK is not working for you since you have clean readings from LIDAR and you get a target acquired from as high as 20 m (my IRLOCK never detects my beacon until I am around 5 m or less). The only thing I could say is that it seems that your vX and vY are too sensitive: when pX is negative, your vX has a high positive value, which is too much and makes pX overshoot, then vX has a high negative value and pX overshoots again and so on. I’m not sure if that’s something you can tune with a parameter, maybe @ThomasSFL has a solution to this issue.



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,

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.