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).
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 
1 Like
If they’re going free like candy I’ll have one too
1 Like
Ha. It has been claimedI 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
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.
I have the same request and made it some time ago. It would be great to have some way of knowing if the beacon has be acquired or not. Having this feature would help us greatly in developing better landing pads and work to make the prec landing as close as possible to 100% reliable.
Having a variable that tells the user if the target is acquired or not in real time during landing would help operator to decide wheter the landing is ok or needs to be done manually. Expecially in confined areas.
We use a companion too, so even a pin on pixy would be ok.
regards,
Corrado
You could stream logs over mavlink by setting LOG_BACKEND_TYPE=3, then look at the PL messages. You can then interrogate the TAcq field that tells you whether you have the target acquired. Ideally you could get this over a mavlink stream without having to look at the logs in realtime - it could be added to SRx_EXTRA3 stream for example.
1 Like
@ThomasSFL Hum that’s weird. I also had a lot of interference in bright sunlight when metal is reflecting the sun. The pixy would get easily confused. Long time ago, I read the the beacon was doing some kind of frequency pattern but I could not verify this… Feedback on this ?
1 Like
Thanks for your suggestion, once i set log_backend to 3 where i can look at logs in real time using mission planner on my pc?
Is there a file written in realtime during flights?
Corrado
I don’t know how it works if streaming to a GCS like mission planner. Normally mavlink log_backend is used to stream to a companion computer onboard, through mavlink-router or dflogger, something like that. When using mavlink-router, it just saves a log file to the filesystem which you can then transfer and load into a GCS for graphing, or you can use something like this:
1 Like
Hi Thomas, we are working on having precision loiter with IR lock. The PLND_ENABLED = 1 and PLND_TYPE = 2. We are getting all the values under PL as it should. But when we put it on prec.loiter it does not hold on to the beacon. It just drifts. Is there anything we are missing out on?
Try
PLND_EST_TYPE = 0
Then it worked for me.
1 Like