I’ve been flying arducopter since version 3.3. Back in 2017 I tried precision landing with IR-Lock on Cube Black running Nuttx and Copter-3.5.7. Hundreds of auto missions were flown with that setup with no problem at all, until today.
With Copter-3.6.9 on Cube Black running ChibiOS, IR-Lock is not working:
Pixy camera is detecting the beacon just fine.
Pixy camera LED turns red as usual when detecting.
Pixymon shows the target being detected.
Pixy camera is connected to I2C1 port of SpektreWorks carrier board.
Lightware SF20 rangefinder is connected to Serial2 and working.
Below are the parameters used to work on Copter-3.5.7 on Cube Black.
With Copter-3.6.9 though, if PLND_BUS is 0 (zero), Mission Planner reports “Bad Vision Position”. If it’s set to -1 or 1, the report goes away which indicates it’s getting data from the sensor. The problem is when the mode is changed to LAND… the copter goes out of control and would crash without a human intervention.
The video below shows what happen when mode is changed to LAND. The pilot quickly change the mode to LOITER to regain control to prevent a possible flip and a crash.
This is also happening with Copter-3.6.6. Should I assume IR-Lock is not supported yet on ChibiOS? If that’s the case, how can I revert back to Nuttx and Copter-3.5.7? Hope someone can help me to understand what is going on.
I have IR-Lock working with 3.6,8 quite well. But I had to change PLND_EST_TYPE to 1 (Kalman Filter).
I made one observation: The first position correction (in the moment when the sensor recognizes the beacon) was smoother in 3.4. With 3.6.8, it seems to be quite hard. The copter nearly „jumps“ to the position above the beacon. But besides that, it lands smooth and very precise.
The advice to set PLND_EST_TYPE = 1 (the default) is probably a good idea. Maybe try that and see how it goes?
Re moving back to 3.5.7 (NuttX), I wouldn’t expect any change in behaviour when moving back to 3.5.7 because we haven’t changed anything in this area as far as I know between the two versions. Still, 3.5.7 is available from MP’s Install Firmware, “Pick Previous Firmwares” link. Older firmwares are also now available directly from firmware.ardupilot.org but it seems 3.5.7 is missing so I’ve raised an issue to get that fixed.
We haven’t heard of any issues with IR-LOCK Precision Landing with ChibiOS. However, it is probably a good idea to follow @rmackay9 advice and see what happens when you try a previous firmware (NuttX).
Typically, PLND_EST_TYPE = 0 is the most robust/stable setting. However, you could give PLND_EST_TYPE = 1 (EKF estimator) a try.
I didn’t see anything strange in your logs (except for the obviously abnormal controls behavior). Your IR-LOCK sensor is detecting the MarkOne beacon. And your rangefinder is providing altitude readings. See log image below.
This is to report that I was unable to find the cause of my Copter precision landing issues. It must be some configuration we set wrong. In the end, we decided to do a clean install of Copter-3.6.9 and configure everything from scratch. Nothing was changed in the Pixy camera, it’s still running the same MarkOne firmware as before on 3.5.7.
After the clean install, the results came back to be outstanding! I’m a big fan and love IR-Lock solution
Oddly enough I just experienced the same issue today and had some of the same thoughts you did. Since this was my first flight using IR-Lock using 3.6.9 with chibios. As soon as I went into land, there were some massive instabilities that looked like they may cause a crash, so safety pilot took over. On the second flight, the instability was slightly smaller and the vehicle recovered but seemed to descend with some really jittery and abnormal/overactive control (The best I can describe it as was very violent twitching at maybe 3-5Hz). We did not allow it to continue like this for more than a few seconds.
Upon reverting to a known stable 3.5.5 that I have flown with IRLock countless times, the issue was gone and precision landing worked great. I chalked it up to either chibios or a 3.6.9 issue.
Your saying that you just reloaded firmware and it started working again?
I did not try that with 3.6.9, but did attempt multiple flights all with the same result, rebooting the pixhawk between each flight. The stranger thing is that the logs of the plnd variables did not look too abnormal.
I am having a hard time believing this is coincidence as I use the IRLock very often and am quite experienced in its use. And it sounds like we both experienced the same or similar issue. I will try reloading 3.6.9 firmware and flying, but I’m not sure that rules out a potential issue with IRLock in 3.6.x firmwares.
Hi~ @ThomasSFL
I have use GPS with IR-LOCK to do precision Loiter is awesome,
i want to only use IR-LOCK to do precision Loiter, (No GPS)
but It was very windy at my city.
if i use gimbal with ir-camera to do precision Loiter, is batter?
thank you~
Thank you for your message. This seems like a different topic. You can contact me directly at this link or at thomas@irlock.com
In short, if your copter experiences a large amount of pitch/roll, you may need to select a wider-angle lens and modify the lens model. If you use a downward-facing gimbal, you will need to modify the sensor angle geometry in the code.
Attached are 3 logs from the flights. It may not be immediately apparent what was happening from the logs as they do not appear that out of the ordinary. Unfortunately I do not have footage of said flights.
As stated before, the first flight had some massive instability on initiating landing, leading to manual takeover. The second and third flights had similar instabilities that the vehicle recovered from and during descent exhibited a violent twitching, leading to manual takeover. I have never seen behavior like this and after reverting to 3.5.5 firmware, the instability and twitching were no longer present.
Note: Some parameters were changed between each of the 3 flights. Between First and second flight I changed the PLND_ACC_P_NSE param from 2.5 to 0.5. Between the second and third flights I changed from EKF3 to EKF2. I was just attempting to eliminate possible causes of the weird behaviors. None of the changes fixed them.
I briefly inspected one of your logs. The Precision Landing seems to be performing as expected. It could potentially be improved, but it definitely does not exhibit the issue experienced by @samucs.
You could try PLND_EST_TYPE = 1 and see if that works better on your copter (sometimes 1 works better, and sometimes 0 works better).
Also, your PL readings are a bit ‘jumpy’. You may want to check the vibration/flex in the mounting of your IR-LOCK Sensor. Also, use Pixymon to make sure your lens is optimally adjusted for the best MarkOne detection quality. https://irlock.readme.io/
@ThomasSFL
I wish I had a recording of how the first flight looked (the one you took a look at the log for). It appeared nearly identical to what was seen in the video in the initial post on this thread. That’s the main reason I even took the time to post. My issue was solved by reverting to 3.5.5 and It could be as simple as suggested by the original poster that I just had to re-upload firmware.
I just find it odd that we both saw something very similar upon the same upgrade from an earlier build to 3.6.9 chibios. In my experience on monday, flights with identical params on 2 different firmware builds perform vastly different. On 3.5.5 everything was smooth and performed normally. On 3.6.9 visually the craft looked like it was going to crash and was incredibly jittery/twitchy. On log analysis It was not easy to see the same signature we saw visually (although you may see it if you look at the pitch/roll plots see below image). I thought it was pretty puzzling and worth mentioning.
We are quite experienced in using these sensors and other custom precision landing solutions. We have a small fleet of identical aircraft all using the same frames, sensors, and firmware. So we know that the configuration used on these aircraft work consistently. I was concerned after seeing such a bizarre result upon testing our upgraded firmware and also to see that the top post on the forum related to an issue that sounded strikingly similar.
When I get a chance, I will try to replicate this result and provide a bit more evidence (i.e. video) if it occurs again.
@James_Megariotis
We appreciate the input. Have you tried re-uploading the firmware? If that solves the problem, then @rmackay9 may be able to comment on that (I am not sure why re-uploading firmware seems to solve issues).
It is worth noting that the issue in @samucs’s case (before re-uploading) was particularly severe. The roll/pitch went up to ~35 degrees
@ThomasSFL
Yes we have had a few instances in the past where reuploading inexplicably solved an issue. Never understood why.
Also I did notice his looked more severe but just figured it might be related as I have never seen IRLock precision landing behave like that before.
We plan to re-run the 3.6.9 testing at some point in the near future. I will be sure to record as to provide some visual evidence, as it looked far more alarming than it does from log analysis. I will keep you updated If we can replicate this event or get any additional information.
Hope this is a helpful thread, and let me explain what I did to solve my problem. It was not just uploading the firmware. First, we spent hours trying to understand what was going on, but with no luck. Then we started to isolate the whole setup:
Copter-3.6.9 was re-uploaded to the Cube connected to a carrier board from SpektreWorks.
Params from IRIS were loaded using Mission Planner.
Then we configured all params needed for the hexacopter from scratch.
Lightware rangefinder was configured for SERIAL2.
IR-Lock sensor was configured for I2C2.
Just one Here GPS connected.
With this setup, after all calibrations done, the first flight was quite good as you can see in my “Solved” video. After that we started to connect the other peripherals (companion computer, a second GPS for blending, LEDs, 4G telemetry, etc). Then we went for the second test, and it was all good.
With that said, the solution in my case was probably to erase the Cube, re-upload a brand new firmware with brand new params, and then reconfigure and calibrate everything. It’s vague, I know. But unfortunately I was unable to find the cause.
Let me know if you can do the same and share the results.
Kind regards.
Uploading the same firmware shouldn’t resolve problems I think. In fact, some ground stations will refuse to upload the exact same firmware.
What’s far more likely is that some configuration is changed one way or the other. For example in this case it looks like @samucs has completely wiped all parameters and started again. If we had a dataflash log from before and after we could more precisely pin down which parameters have been modified.
Need to join the club here unfortunately.
I just maidened my new Tarot 650 build with IR Lock and AC 3.6.9.
I experience the same behavior as the OP.
As soon as IRLock detects the Markone beacon during LAND or in PrecisionLoiter mode the copter starts bouncing around.
My IRLock mount is rotated by 180 degrees (due to spacing reasons I had to turn around the IRLock sensor)
In order to adjust the orientation, I set the PLND_YAW_ALIGN parameter to 180 degrees. However this has no effect on the issue.
Here is the log with PLND_YAW_ALIGN set to 0:
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.
