IR-LOCK trouble - please help (solved)

Andre-K · September 15, 2021, 8:28am

I installed IR-LOCK on 3DR Solo running openSolo + ArduCopter 4.0.3
The I2C is connected to the bus the battery is using and the bus is OK, checked and re-checked for continuity.
I followed this guide: Getting Started with IR-LOCK Pixy

The IC_LOCK’s LED is dimly RED (which responds to MarkOne by increasing intensity )and I have tried all three PLND_BUS options. logs are here: IR-LOCK - Google Drive

I do not know how/when data is supposed to be logged. (in a specific mode, or always, like any other sensor.)
All “test-flights” are done indoors, no props, over a “MarkOne Beacon V3.0”

Corrado_Steri · September 15, 2021, 8:45am

Do you have a rangefinder installed?

Andre-K · September 15, 2021, 10:10am

No, no rangefinder.
I also connected an logic analyzer to the I2C of PIXY-IR,and I can observe BMS and other traffic, but I see no attempts to communicate with 0x54 (I2C address of PIXY-IR, according to source code in Ardupilot)
Also, this is regardless of PLND_BUS selection.

I have also enabled the “precision loiter” by RC6_OPTION=39 (and I’ve made RC6 go from 1000…2000) - tested by graphing that RC channel.

Corrado_Steri · September 15, 2021, 10:19am

Rangefinder is mandatory. It is written on the very first line of documentation.

https://ardupilot.org/copter/docs/precision-landing-with-irlock.html

ThomasSFL · September 15, 2021, 11:45am

@Corrado_Steri is correct. The rangefinder is required.

This is stated in the first section of the IR-LOCK tutorial, as well as the first line of the AC Wiki. Always read the docs first

https://ardupilot.org/copter/docs/precision-landing-with-irlock.html

Andre-K · September 15, 2021, 12:26pm

so… the device is not being polled unless a rangefinder is present? - this is a huge facepalm, I stopped at “this does not work”

rishabsingh3003 · September 15, 2021, 1:56pm

@Andre-K, the IR lock basically outputs the general 2-D “direction” of the landing target. The device itself does not need a rangefinder to work… but to get the approximate 3D location of the landing target, we’d need a range finder. Inside the code, we can probably use the barometer alt as well for this, but then the landing will not be precise. If you do not want to use a range finder, the only option at the moment is to use LANDING_TARGET mavlink message, with the DISTANCE field filled in.

Andre-K · September 16, 2021, 7:40am

So, I updated the log directory with three new logs.
All using a rangefiner. - and PLND_BUS -1 ,1 and 2 setting (with reboot inbetween)
Yes, the rangefinder is noisy when motors are on, I’ll add some shielding to help that - but this is not the issue right now, the main issue is that the PIXY_IR does not provide any data.

I might have been thrown off by a logging issue in 4.0.3 ? https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L361

but if I upgrade, it seems recent versions have another bug, that is corrected here:

github.com

ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L91


    d) Crosstrack reporting fixed
    e) CRSF message spamming and firmware string length fixed
    f) Display re-enabled on 1MB boards
    g) DShot always sends 0 when disarmed (protects against motors spin while disarmed due to misconfiguration)
    h) DShot fix that could cause main loop jitter
    i) DShot buzzer tone disabled during motor test to remove bad interation
    j) Guided mode accepts position targets at high rate
    k) Longitude wrap fix (allows autonomous flights as longitude wraps between -180 and 180 deg)
    l) Log created on forced arm
    m) MatekF405-bdshot NeoPixel LEDs re-enabled on PWM5
    n) Precision landing init fix (if pilot took control, subsequent landings might not trying to land on target)
    o) Serial port performance improvements using FIFO on H7 boards
    p) TradHeli ground check of yaw fixed (yaw servo was not moving when landed)
    q) Throw mode waits for throttle up to improve reliability
------------------------------------------------------------------
Copter 4.1.0-beta5 30-Jun-2021
Changes from 4.1.0-beta4
1) Enhancements
    a) Arming check of distance from EKF origin increased to 250km horizontally (was 50km), 50km vertically (was 500m)
    b) Position control accuracy improved at very long distances (aka "Loiter bucketing")
    c) Pre-arm check of FLTMODE_CH and RCx_OPTION conflict

What would be a known good, well working ArduCopter version for LOCK-IR ?

ThomasSFL · September 16, 2021, 9:12am

The Precision Landing feature has worked in ArduCopter for many years now (and versions).

Your comm status still shows a PL.Heal of 0, so you have a connection or parameter/setup issue.

Send screenshots of your sensor parameters (click ‘gear’ icon in Pixymon). That will not verify the wiring, but I can check the sensor params.

Corrado_Steri · September 16, 2021, 9:27am

We have had irlock working since 3 years ago on every released firmware. Maybe they made it better lately but has been working fine on 3 years old firmwares for us. So i think you have it misconfigured or misconnected somehow.

Andre-K · September 16, 2021, 12:15pm

Please see attached screenshots of configuration.
screenshots_pixymon.zip (49.3 KB)
The one setting I am not sure about, is PLND_BUS (So I am testing both 1,and two)
I also tried current release candidate Copter 4.1.0-rc2 - no joy.

As for connection:
The SF11C lidar is connected using I2C to the SDA/SCL pads of the IDC connecotor of teh PIXY-IR board.
SF11 Works, and I also see I2C traffic from the Solo battery and other devices on those pins.
SCL/SDA is verified to not be swapped, but if they were, the whole I2C bus would be down.

ThomasSFL · September 16, 2021, 1:29pm

@Andre-K Based on your screenshots, you still haven’t followed all of the tutorial steps.

Please see ‘restore default parameter values’ in Step[1] of tutorial pictured below.

The docs/tutorial is your friend

(also, if you are still having comm issues after following the IR-LOCK tutorial, I would recommend not also putting the rangefinder on the I2C bus)

@Corrado_Steri
@rishabsingh3003

rishabsingh3003 · September 16, 2021, 1:35pm

Hi @ThomasSFL,
I remember with my experiments, I had followed the “restore default parameter values” step.
The data out port was still = 0 (which seems to be the case for @Andre-K"
Setting it to 1 immediately fixed the problem. We should document this,
“Users facing problem with IRLOCK connection should check if the data out port is = 1”

ThomasSFL · September 16, 2021, 1:50pm

@rishabsingh3003 If you have the correct firmware installed (from IR-LOCK tutorial), then ‘restore default parameter values’ will definitely change the data out port. You can test and verify this with the correct sensor firmware.

If you do not have the correct firmware installed, then it will not change the data out port. (or it may even change it to ‘0’, if it was manually set to ‘1’)

@Andre-K

Andre-K · September 16, 2021, 3:26pm

@ThomasSFL We certainly did the “restore default parameter values” Also, If I remember correctly, doing so made the video much darker.

Will set the “data out port = 1” tomorrow.

As @rishabsingh3003 - says, please do not get to eager on the “RTFM” approach and try to investigate that possible bug.

Does the rest of the values look good?

ThomasSFL · September 16, 2021, 4:46pm

@Andre-K If you install the correct sensor firmware (from the tutorial), and then click ‘restore default parameter values’, it will definitely change the data out to I2C. The order of instructions in the tutorial is important.

After you complete this process, let me know what happens. Send screenshots of the sensor params again.

Andre-K · September 16, 2021, 5:35pm

As we know, the documentation is a frustrating mess.
Dear @ThomasSFL
if you enter: https://irlock.readme.io/v2.0/docs
you see “2.0” in the URL… and “latest” in upper right corner-
then you scroll down to " Sensor Firmware & Software"
…and the URL is no longer mentioning 2.0
but then I get to see two links that lead to “https://irlock.readme.io/docs/firmwaresoftware-links”
clicking on those, brings me un-intuitively to https://irlock.readme.io/docs/getting-started
…feels like I have navigated away from the 2.0 which I was asked to use…

now I see PC software and Firmware for Markone 1.0.1 - NOT IR-Lock.
Screenshot from 2021-09-16 19-25-59

and the text says “Use the dropdown menu at the top-right to ensure that you are using the latest version of this documentation. (v2.0)” - which seems to be long gone.

This is probably fine for you, as you know exactly what you need, for for a new customer, this is confusing, expensive(in terms of hours) and very annoying.

Can we please cut to the case, and provide me with a link to the correct firmware for PIXY-IR, (if the one we’ve used is wrong)

This is the file-link we used - found on the webpage after hopping thru hoops.:
https://cdn.shopify.com/s/files/1/0599/7905/files/firmware_IRLOCKpixy_1.0.1.hex?9716859623190133140

ThomasSFL · September 16, 2021, 5:52pm

@Andre-K Other users follow the tutorial just fine.

Just slow down and read each sentence one-by-one. If you need clarification on a particular instruction, feel free to ask.

Andre-K · September 17, 2021, 6:14am

@ThomasSFL Can I have clarification of the exact place/URL to the firmware for the IR_LOCK ? - the one that apparently is somehow different and set the communication parameter correctly?

Andre-K · September 17, 2021, 6:41am

By any chance; the place that contain the software, has a title saying “IR-Lock Firmware” - not a link, and then MarkOne_1.0.1.hex firmware…
We have MarkOne 3.0
Is that Markone_1.0.1.hex firmware for some/older MarkOne, or is it oddly named IR_LOCK firmware that hints that it is looking for use with MarkOne ?
This is ambiguous at best, but this is the other possible source of firmware I see.

Screenshot from 2021-09-17 08-36-30