Is it set to Raw or Kalman?
Thank you for your input.
Some clarifying questions:
(1) What do you mean by AC 3.9? (I think the latest release is still 3.6._)
(2) Was PL on this copter previously working with another AC firmware?
(3) Is the sensor rotated 180 degrees in both tests? (i.e., when PLND_YAW_ALIGN is set to 180, AND when PLND_YAW_ALIGN is set to 0)
I look forward to your responses. However, my initial recommendation is to align the sensor at 0 degrees and set PLND_YAW_ALIGN = 0.
Thanks for getting back Thomas!
- sorry, a typo - I am on AC 3.6.9.
- This is a new build, not flown with IR Lock before. However I was using the same sensor on other copters with AC 3.4 and AC 3.5 w/o problems before.
- Yes. There is not enough space to mount the IRLock at 0 degrees. Therefore I need to rotate it with the YAW_ALIGN parameter.
I have set PLND_EST_TYPE = 0 (Raw)
EDIT: the documentation in the code https://github.com/ArduPilot/ardupilot/blob/master/libraries/AC_PrecLand/AC_PrecLand.cpp
says that PLND_YAW_ALIGN is menat to be entered in cdeg - centidegrees?? That would mean to enter a yaw alignment of 180 deg as 18000 - correct? However the range allowed in MP is only 0-360.
I am a bit suspicious of the YAW_ALIGN parameter. I have never used it (i.e., I always mount the IR-LOCK Sensor at 0 degrees).
And yes, you may be correct in your code observation:
// Apply sensor yaw alignment rotation float sin_yaw_align = sinf(radians(_yaw_align*0.01f)); float cos_yaw_align = cosf(radians(_yaw_align*0.01f));
I can confirm that the PLND_YAW_ALIGN parameter works fine.
I have set it now to 18000 to compensate for my 180 degrees rotated IR Lock mount and precision landing works perfectly well now.
What distracted me is the incorrect documentation in MP about the yaw angle to be between 0 - 360 deg instead of 0 - 36000 in cdeg.
I have just experienced what appears to be this exact same issue.
I’m running 3.6.9 on a Pixhawk 4, and had just figured out how to get the Pixy to communicate with the flight controller successfully (the I2C configuration is a bit different on a Pixhawk 4).
Once I got it working, I took it out to test, and when switching to land mode, I observed the same initial jerkiness that @samucs did. The jerkiness lasts about 2 or 3 seconds, with copter looking out of control and as though it’s going to flip itself (as in samucs video), then the copter begins to descend, but does not land very accurately. You can see it trying to make adjustments but they’re way too small.
I was using PLND_EST_TYPE=0. As suggested above, I will try setting this to 1, and if that doesn’t work, I can try a clean install. But I’d be really interested to figure out what is causing this, as it seems to be an issue multiple people have had.
I had also recently updated the firmware from 3.63 FMUv5 to 3.6.9 Pixhawk 4, so it could definitely be the case that’s it’s something to do with the parameter saving when updating vs a clean install.
I’ll recover a log file and post a video tomorrow, but it looks like it’s the same issue.
Good Day @tbrs2 ,
Thank you for your message. Can you provide a .log/.bin file from your flight?
Thanks for getting in touch Thomas. I’ve emailed you a .bin file (was too large to upload here).
Thanks! I sent a reply.
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.
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,
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.
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?
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
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.
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
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.
Good Day @NiharikaPatel,
I don’t see an attached log file.
I apologize here is a link to it.
The file is private