Hello, i have been using irlock for quite a while now and i must sat i am very satisfied with it.
My only concern is that to have it working and do its job i have to use Kalman filter option, while everybody seems to use raw data.
If i use raw data landing is less precise and looses it a bit on the last part of the landing, and goes off by 30-50 cm. If i use kalman filter the alignment is more aggressive when the target is first aquired but than the landing is always around 5 centimeters from the beacon.
Now reading all the orror stories about the kalman option going wild on target aquiring i am a bit concerned and would like to know if somebody else is using the kalman option with good results and if people using raw data have the same lower precision in the very last part of landing.
To follow up to @anon67614380 and @d-skinner, the KF estimator option for PrecLand seems to have been developed/tuned specifically with irlock in mind, and is apparently very stable and works very well. However it doesnât work well/reliably/safely for other systems than the irlock and after numerous complaints the raw estimator option was added in.
If youâre using the irlock, or a very fast external sensor system with minimal latency (<=20ms) then use the KF estimator, otherwise use the raw estimator WITH CAUTION. The system as a whole is unpredictable with slower external systems with higher latency, regardless of which estimator is being used and can exhibit wild and dangerous movements.
I have worked with many IR-LOCK users and various copter setups. My answer regarding KFvsRAW is âit dependsâ.
Yes, the KF was developed using an IR-LOCK/MarkOne system. And it was also developed on a particular copter platform.
Some users experience bad oscillation behavior with the KF. Others donât. Some users experience better performance in the final meter of descent with KF. Others donât. Itâs hard to give a definitive answer.
So far i tested it on 2 different copters, one 4X and one 8X. Both around 10kg and on both Kalman looks a bit better.
Raw is a bit shaky on final couple of meters while kalman looks like it decides a traiectory and follows it.
All in all they both do their job nicely and precisely.
@ThomasSFL Do you think that once it works on a particular setup (either kalman or raw) it keeps working or it can all of a sudden do strange things?
The oscillation is almost certainly due to mismatch of the pixi camera frame and the imu buffers - is it possible your pixi/processing system slows down sometimes (or even speeds up?) Arducopter precland is tuned for precisely 20ms delay between the camera taking the image, processing it, transmitting it, and the precland estimator receiving it - I believe this value was chosen because it most closely matches the irlock system. If this capturing/processing/transmitting time differs (eg in different lighting conditions, does the camera exposure length change?), then it wonât match the 20ms delay and then the incoming data doesnât get slotted against the correct imu buffers. This leads to it over or under correcting. It also depends on the nature of the movements that the craft is making - slower, smaller movements are dealt with much easier. If there are larger, sharper movements then this behaviour is magnified if the buffer alignment is out.
Performance in the final meter of descent depends on the tuning of the copter and the vision system. A well tuned system will land spot on almost every time (see the videos GitHub - goodrobots/vision_landing: Precision landing using visual targets - once I had a well tuned system it landed within a few cm every time).
The raw estimator acts on each individual message/vision detection individually so it can appear quite jerky, although if the system is not well tuned it seems to cope better. The KF takes each message and inputs it into the filter so it effectively gets smoothed out over time (is the best I can describe it!), so while it provides better performance on a tuned system, on a not so well tuned system it can make things much worse.
@fnoop Very interesting! Is there a way for the code to dynamically adjust to the camera delay/latency?
I found the KF works much better on our systems (5-10cm accuracy). Raw worked too, it was just much more âlooseâ overall. Especially in the final meter. Could only get accuracy of around 30-50cm.
Both Raw and KF seem to be very âtwitchyâ for me at higher altitudes. Especially the initial reaction of the copter. Itâs very aggressive as soon as it locks onto the target. In some cases I saw the oscillation (more of a âtoilet bowlâ effect) but as the copter descended it slowly reduced. I know this sounds silly but almost as if it was being flushed down a toilet. It seemed to me as though the aggressive initial positioning at higher altitudes actually initiated the oscillation. In any case the final meter was pin-point.
The two improvements Iâd like to help fix are;
The âaggressivenessâ of the initial centering
The oscillation (which may be minimised if we fix the first issue)
The oscillation is almost certainly due to mismatch of the pixi camera frame and the imu buffers - is it possible your pixi/processing system slows down sometimes (or even speeds up?)
We did a very successful timing test of the camera with the MarkOne system before the KF was developed. I will try to find those results (it was a while ago), but we found that the timing was very consistent. This is primarily due to the fact that we donât change the exposure length. Also, the detection algorithm is written such that it is forced to be completed before the next frame begins (at 50fps), and it is very consistent ⌠I will see if I can find those results so I can see if there were any factors that caused noticeable timing variations. I donât think there were any.
@ThomasSFL Hi Thomas, did you find any more info on this? Do you have a specifically fixed exposure length, as opposed to auto? Does your system guarantee the frame result and transmission within 20ms of image capture? It would be interesting to know - myself and others experienced similar oscillations due to timing mismatch although doesnât mean thatâs necessarily the case here.
@d-skinner How are you getting on? The âaggressiveâ initial reaction is to be expected from this kind of system, as soon as it gets a target it tries to center it as quickly as possible - this is a good thing when you are in windy conditions as it has a much better chance of keeping the target in sight! Is it causing you concern or problems? Might your oscillation/toilet bowl effect be just down to loose PIDs somewhere?
@fnoop Hi, could you elaborate what you mean by âa very well tuned systemâ? I really would like to understand this clear so I can try to apply such procedures to my copter.
@d-skinner Iâve been developing a drone delivery system and IR-Lock is a great piece of technology. But I always had to choose Raw Sensor option because the Kalman option was making my copter to fly away after detecting the beacon. It does get too aggressive! I almost lost all my equipment when I tried Kalman option.
From then on Raw Sensor is giving me better results. The only thing that sometimes is annoying is that the copter lands spot on, touch the ground, then climbs one meter high and lands again 50cm away from the Marc One beacon. Why?? It did land correctly, why climb and land again?
Hope this kind of behaviour could be improved. But I am happy with the results so far.
Regards,
This âre-landâ behavior is not likely related to the precision landing. It happens when the drone fails to detect that it has landed. Make sure your vibrations are low and your flight controller is not exposed to flowing air, as those things can contribute to this problem.
If it only happens when precision landing, then it might be caused by the PL position offsets not being relaxed when the drone thinks it might be touching the ground (during LAND_MAYBE). I would think that an accurate rangefinder would prevent this, as long as the RNGFND_GNDCLEAR is set properly.
@fnoop, I know it has been a long time with this thread, but have you found that a successful autotune is good enough on the PID front, or is more advanced tuning required to dial in the landing?