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: https://irlock.com/pages/startirlockpixy
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.
@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.
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.
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.
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.
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”
@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 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.
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.