During the last few days and weeks I tried to use the IRLock with an MaxSonar EZ4.
The first time I used it worked for several landings (6 times).
However during the last few attempts the PL didn’t worked or the position change was very fast and therefore the copter missed the target.
I looked at the logfiles however I just see that the IRLock often can’t “see” the beacon and I can’t understand why.
The lens is properly focused and there was no wind at all so no drift…
Can someone else spot a problem or give me some hints what else I can try?
I will be happy to check the logs as soon as I can (I’m not at the office right now).
We do not receive many complaints about the MarkOne/IR-LOCK detection performance. The reliable detection in all lighting conditions is actually its best feature!
When there is a detection problem, it is almost always a result of the lens adjustment/focus. But I shouldn’t get ahead of myself. I haven’t checked the logs, or asked about your setup.
(1) How did you adjust/focus your lens? And did you insert the set screw after adjusting the lens?
(2) Do you get the desired detection range when you view the sensor output in Pixymon? i e., if you can reproduce the detection issue in Pixymon, that would be very helpful.
Also, if you are in the US, I would be happy to check your sensor and beacon personally. (You could ship them directly to me)
We strongly recommend the SF10/A, SF20, or LW20 rangefinders. They have produced great precision landing results for commercial projects, when paired with MarkOne/IR-LOCK.
This does not rule out the possibility of also having a detection issue, as well. But we definitely need to solve the rangefinder issue.
By the way, there were older versions of the flight code that did not require the use of a rangefinder. (https://irlock.readme.io/) It defaults to BaroAlt when the rangefinder is not present. This may be helpful for preliminary diagnostics.
thx a lot and uuuh yes the sonar data is very bad…
This is my big mistake I always checked the BAlt instead of the SAlt and thought that the Sonar does a good job… Sorry for that I nee to fix the sonar somehow or buy one of those expensive other rangefinders…
I also use the IRLOCK with a EZ4 Sonar. I have improved a little bit the response of the sonar, mostly from this post, but as mentioned in the comments and by @ThomasSFL, it would be best to use a better sensor in the long run. If you insist testing the IRLOCK with this sonar, I would recommend you also apply these tips from the Maxbotix page:
ok I have now installed a LIDAR and yeah hmm its better but still not "perfect"
I attached a log with 15 landings you can see that from time to time the LIDAR is not working well (3times)
During the landing the camera looses the beacon from time to time is this normal?
Logfile: http://www.quadcam.ch/data/flight14.zip
thx! I will try this today.
What kind of Rangefinder do you have?
Once the IR Camera locks to the Beacon does it loose the beacon again or is stable locked?
As I told you before, I’m still using the EZ4 sonar because for now it’s cheaper and works on certain conditions. As soon as I can, I will buy a rangefinder and replace the sonar. In my tests, once the IRLOCK locks to the beacon it always lands correctly. What used to happen to me and I also saw in your videos is that sometimes the IRLOCK doesn’t lock at all and lands in another spot. I solved that by reducing the landing speed as mentioned in my last response.
thx a lot for the video.
looks nice so I give it a try and will report back.
Had some pretty good landings the last few days however this IR beacon
is really big
Are you considering to make a smaller version?
@ThomasSFL Hi, you’ve said earlier in this conversation that earlier versions of ardupilot did not require rangefinder and used barometric altitude instead. Do you know the thinking behind this change, was it because it was unreliable/dangerous?
There’s an issue open to restore it:
It would be nice to get some input if it’s not a good idea
@fnoop
Thanks for the question. I was one of the ‘devs’ that worked on the early precision landing code, so I hope I can provide some helpful input (however, I am not as familiar with the EKF implementation).
The precision landing code estimates a x- and y-distance from the landing target, and then tries to reduce these x/y-distances to zero by moving the copter toward the target. The altitude-from-target measurement is very important in finding the x/y-distance estimation. In most circumstances the most accurate and simple way to get the altitude-from-target measurement is to use a rangefinder.
You could also use the barometer to estimate the altitude-from-target, but the barometer measurements can ‘drift’ over time. Or the altitude of the landing area may be significantly different than the take-off area (and thus, the baro altitude would not correspond to the altitude-from-target).
The commercial precision landing projects that I have worked on typically use a laser rangefinder. We recommend the Lightware products due to their robustness against IR interference. Also, a good laser rangefinder is almost always going to be more precise and accurate than a barometer.
So, to answer your question, it is ok/safe to use the barometer altitude in some cases (e.g., low baro drift and limited ground level changes). But a good rangefinder is MUCH better for precision landing and precision loiter. And, as you have noted, I think the latest code does not allow precision landing to be activated without a rangefinder.
In our earliest testing/development, we actually used the baro (w/out rangefinder) a lot. But these were short test flights, typically over level ground.
Also, please check some of our videos to see how accurate the precision landing can be with the proper setup.
Actually, the size of the beacon is typically not the limiting factor with regards to precision landing accuracy. The LED array on the MarkOne beacon is only ~5x5cm. Wind compensation and controls optimization are typically the bigger issues.
We have produced customized MarkOne beacons for special projects. The size could be reduced, but that would also reduce the detection range.
