I’ve been having the same issue when testing precision landing using an Aruco tag and a camera, so it’s not an IR-Lock issue it seems. I haven’t been able to find the cause yet but I suspect it might be related to Loiter settings.
Good Day @Ammarf,
Do you have .log/.bin files. Also, it would be helpful to save the .param files (before and after modifications). It seems that the issue was related to mis-configuration of parameters; however, this has not yet been fully investigated because we don’t have all of the before-and-after logs.
Best,
Thomas
For those others still struggling with this issue, I think we’ve found the solution to our version of the problem.
Like other people in this thread, we were seeing very violent motions from our drone when initiating the precision landing, enough to make us worried the drone was going to crash itself.
When analysing our .bin files, we saw that the TAcq (Target Acquired) Boolean was always 1. Upon thinking about it, this didn’t make sense, as there were times in our flight that the drone was landed away from the MarkOne beacon. It turns out, that in the outdoors, the Pixy was detecting targets everywhere! We’d done the calibration indoors so that the MarkOne beacon appeared slightly blurred at a distance, but our exposure setting on the Pixy was set to 13 (we’d never changed it), and this meant that when we went outdoors with more light, the Pixy was always detecting targets in the surroundings.
We’ve just set the exposure to 1, and recalibrated the Pixy with the MarkOne outdoors, and now, quite reliably, the only target being detected is the MarkOne. We did this in bright sunlight in a car park, and the Pixy was still detecting some targets in the form of the bright spots of light reflecting off of cars, and we couldn’t get rid of this, but everything else was fine, and I reckon the precision landing will work as expected now (though we haven’t been able to test fly since the change).
If this really is the cause of other people’s issues too, then it would beg the question of, why are people only starting to see this issue now? Was the default exposure setting in the Pixy firmware lower in previous versions?
Anyway, if anyone else wants to try and see if this fixes their problem, you want to open up Pixymon with the Pixy plugged in, and find the “Exposure” setting. See what it is and maybe try reducing to the minimum you need. We found 1 was fine.
Hope this helps,
Tom
Thank you for posting the update @tbrs2
If you are getting false target detections, you have missed a step in the IR-LOCK tutorial (linked below). After flashing the correct sensor firmware and clicking ‘restore default parameters’, you will not get false detections. Also, you will not have access to the sensor’s exposure settings. Instead, your param screen will look like the image posted below.
Again, the MarkOne/IR-LOCK system will NOT have any false detections if the sensor is flashed with the correct sensor firmware. If you do experience this sort of issue, please message me. I can probably resolve the issue fairly quickly.
@ThomasSFL
I’ve done a lot of IR-Lock landings during the last weeks. As mentioned above, I had to change PLND_EST_TYPE to 1 (Kalman Filter).
Now, I have done one observation: Whenever the decending position during landing is a bit far away from the beacon, the copter corrects its position. So far, so good.
But it does this with a extremly high acceleration and speed since AC3.6. During this “jump”, the copter tilts to very high angles.
I take a guess, that some of the problems described here in the thread are a consequence of this behavior. I can imagine, that a not very well tuned copter will begin to oscillate in that moment.
I’ve done a download link for the log: https://www.dropbox.com/s/vfddxad8gayyadi/2019-08-21%2012-07-40.zip?dl=0
Is it possible to slow down the movement of the copter when acquiring the beacon?
Thanks,
Stefan
Good Day @fingadar,
Thank you for posting the logs.
I don’t think you are experiencing any issue similar to what is originally posted in this thread. The original issue was solved with a configuration/parameter correction. And there was another issue which was caused by a mis-configuration of the sensor.
Your copter is moving to the beacon, so that is good.
You can try setting PLND_EST_TYPE = 0, and you will observe different PL control behavior.
Also, if the PL controls are still based on the Loiter controller, modifying the Loiter tuning parameters would change the PL control behavior (but I don’t know if the PL and Loiter controller are still directly connected).
I hope this is helpful
Best,
Thomas
Thank you for your answer, @ThomasSFL.
I originally used PLND_EST_TYPE = 0. But with the change of AC from 3.4 to 3.6, the landing precision was worse than using PLND_EST_TYPE = 1, so I changed this.
I‘m still absolutely happy with the reliably and precision of IR-Lock. The difference is below 10cm.
Just the first correction move sometimes is to extreme for me. And this happens since AC 3.6. Maybe this has to do with the new Loiter behavior?
I‘ll look at my Loiter parameters if there is anything to change.
Best,
Stefan
1 Like
Hi @ThomasSFL @rmackay9 I just tried the precision loiter and land feature on my Iris+ AC3.6.9 and it seems like the loiter works but the land does not. While I set it to land it does not seem to acquire the target even though we placed it just below the drone. The loiter does not seem to follow the IR lock linearly, it does swing a little but that maybe because our PLND_EST_TYPE is 1.
These are the parameters
| RNGFND_TYPE | 20 |
|---|---|
| RNGFND_MIN_CM | 30 |
| RNGFND_MAX_CM | 1000 |
| RNGFND_GNDCLEAR | 10 |
| PLND_ENABLED | 1 |
| PLND_EST_TYPE | 1 |
| PLND_TYPE | 2 |
Please find attached the log of the mission green is the target acquired and red is the altitude from the rangefinder
.
Any advice/suggestions would be appreciated.
Thank you
I apologize here is a link to it.
https://drive.google.com/open?id=1aN8nsn7lShR2g9b2JGvoJciTQCkWaznC
Thanks,
Niharika
I granted you access. Please let me know if you can view it now.
Thanks
Hi @ThomasSFL I apologize, I could view it on one machine and on the other it seemed like there was nothing in the logs. The machine it did work on had Mission Planner 1.3.66 and the one it dint work on had Mission Planner 1.3.68 . I tried to read the log from the SD card directly on MP 1.3.68 and it still does not have any contents. That’s the only difference I can think of even in the image you posted it does show the CTUN.SAlt(MAX:7 and Mean:3) but its not plotting it on the graph for some reason I have posted a picture of TAcq and CTUN.SAlt reading from my rangefinder on my previous post. Let me know if you need me to take a screenshot of other params. Im not sure how else I could share the logs with you.
I don’t have access to the log, but it looks like it does have contents. In the Mission Planner log grapher, uncheck “Use Time.” It looks like the log contents do not have a timestamp, so the grapher doesn’t work if you have Use Time checked.
1 Like
The log is showing sporadic target readings from the sensor. This most-likely indicates that you do not have the sensor configured correctly.
Please double-check every step in the tutorial, and use Pixymon to confirm that the MarkOne beacon is being detected reliably. You should not get any false detections when the sensor is configured correctly.
Best,
Thomas
Ok I can re calibrate and test it out. Thank you
So I did some tests today and the copter just drifts off when I switch to Land mode. The log looks fine to me but I might’ve missed something (the copter drifted and ran into a wall on the first test). I’m using navio2 btw.
Your SAlt is only showing an altitude of ~1 meter. You should test at ~10 meters.
Best,
Thomas
I was trying to use ir-lock with the realsense t265 for indoor navigation purposes which is why I couldn’t test from higher altitudes. I ended up changing PLND_EST_TYPE to 1 and setting PLND_YAW_ALIGN to 18000 instead of 180 and it worked beautifully, perfect results almost every test. Thanks a lot for your time!