Have you setup a channel option to 39?
Have you setup a channel option to 39?
Sorry for the delay! I was on vacation, and now I am avoiding a hurricane.
I will get back to you soon!
Iam testing the IR-Lock for the first time.
The IR-Lock is recognized by the Pixhawk Pl Heal is 1
But the TAcq is always zero even when the copter starts and lands over the beacon.
The IR-Lock itself can find the beacon I have tested that with the piximon software.
IR-Lock firmware is 1.0.1
The firmware on the Pixhawk2 is 3.5.2.
No Rangefinder is installed. Is it necesarry to get TAcq or px py values?
@Spatz Hi! Yes, a rangefinder is required if you are using IR-Lock and Copter 3.5.2.
Finally back from the hurricane! Thank you for your patience.
Do you have a log file from a precision landing/loiter test?
Thank you so much for your patience! I am back from the hurricane.
Please make sure you are using MarkOne if you want reliable detection performance in bright sunlight. The other beacons are not capable of the same detection performance.
Sorry for the delay! I am back after the hurricane.
@fnoop provided some great feedback regarding the live streaming of . I hope this is helpful.
I wish we could check your IR-LOCK and MarkOne setup in-person, but we are limited to e-mail/forum discussion. The best ways for us to diagnose detection issue are:
(1) Upload a log and video of the precision landing test where you suspect detection issues
(2) Upload a recording of Pixymon video/detection feed
I would seriously enjoy checking those files/videos to try to diagnose the issue.
Regarding the reliability of MarkOne detection performance in different lighting conditions: the only issue we are aware of is when a reflective surface is placed IN FRONT OF the beacon (i.e., clear acrylic placed in front of beacon). Reflective surfaces NEARBY the bacon are completely ok.
So how can we record the Pixymon video/detection feed while on the drone?
I have a Ubuntu companion pc onboard an could record the stream live while
landing. Do know how to record this onboard the companion do you have a tool
Here is an example where the copter near the ground starts to re-climb up a few cm and then finally lands on the ground.
Can you explain this behavior…
here we go just from a flight of today another problem with the IRLock landing.
Here is the bin file:
Sometimes the copter does a correction to the wrong side and sometimes it works fine.
As soon as it does the wrong correction the IRLock is not able to realign the copter twoards
Thank you so much for the video and log. That is very helpful! And I look forward to analyzing them.
Do the video and log correspond to the same flight?
no they don’t. i could upload the log file for the video.
but currently the log file posted above is much more important because this behavior is really really strange and not good if this can happen…
Thank you for the log file. Here are my initial observations. (I can continue looking at it)
The target detection is consistent, indicated by smooth ‘pX/pY’ curves. That is good, since we can focus on analyzing the controls.
I would strongly recommend switching to the latest ArduCopter firmware. This particular flight was conducted with V3.4.6. My main concern is that some of the older firmwares use a newly-developed EKF for estimations in the precision landing controls. I have observed that the precision landing EKF has produced mixed results: great in some cases, and poor in some cases.
In the latest firmwares, you can disable the precision landing EKF by setting the parameter PLND_EST_TYPE = 0 (RawSensor). This parameter does not exist in V3.4.6. The RawSensor estimation type seems to provide more consistent results for a broader range of copter setups.
Also, is there a particular landing you would like for me to analyze? (e.g., “landing prior to 1 minute mark of log”) I am definitely not the expert on the precision landing EKF, but I am happy to make an attempt.
My primary suggestion is to switch to the latest firmware and set PLND_EST_TYPE = 0.
Nice video! Yes, the altitude control was added by the developers in order to ensure that the copter would not continue its descent when the target is not under the copter. The previous controls code would simply command the copter to descend at a constant rate, even if the copter was not directly over the target (due to wind, etc.).
It was motivated in-part by the work done here:
ok thx for your suggestion
switching to 3.5 takes a long time. We have a fleet of copters and to jump up another firmware version, a lot of testing needs to be done to ensure that the new firmware is stable and has no major bugs.
So we can’t simply switch to 3.5 at the moment since we first need several 100 hours flight time with the test units on the new 3.5 firmware…
Yes could you pls look at the landing at 2550s. There it completely missed the pad and didn’t tried to correct its position towards the IRBeacon. It looks like the drone did correct its position into the wrong direction…
Ok. I understand! But it still may be helpful to test out 3.5 just to try out the ‘RawEstimate’ Precision Landing.
I checked the log around 2550s (~42min), and it looks like it is in Auto or Guided mode at this time (rather than Land)?!
yes we fly normally auto missions with a LAND command as the last waypoint. so this was a normal landing as with the LAND mode activated through the transmitter or the Misson Planer.
I looked at all of the precision landings in the log (both AUTO and LAND modes). It seems like the precision landing is working properly in the LAND mode landings. However, the copter behaves differently in the AUTO mode landings. Have you noticed this sort of behavior?
By the way, I am not familiar with how the precision landing controls code was integrated into AUTO_land in V3.4.6
Here are two examples (first LAND, then AUTO):