irlock doesn't work with the irlock Pixy camera

[jonathan84clark]

Using build for px4fmu-v3_default
When I scope the lines I am seeing no attempt being made by the Pixhawk 2 to communicate with the Pixy over I2C.
The Pixhawk 2 initiates communication with an ms4525 over the same I2C bus
I have changed the frequency (which apparently does nothing)
I have changed the bus (tried 0, 1, 2, 3)
I have changed the device path from "/dev/irlock0" to "irlock" no luck

I am testing this by attempting to initialize communication manually with the mavlink console by typing 'irlock start'

The response says "[irlock] failed to initialize device, stopping driver"
After some debuging code I found that it is failing at the probe stage. When it attempts to perform the transfer it responds with an error code -6.

This works perfectly well in ArduPilot.

I am not testing on a drone, just connecting the Pixhawk 2 to my computer (the drone is still being assembled)

Any help on this would be great.

Thanks,

Jonathan L Clark
Software Engineer
xCraft

[roboflot]

The same problem for Pixhawk 4 (Holybro) and IR-Lock (Pixy) sensor.

Pixhawk does not communicate with Pixy via I2C.
The issue is highly likely to be on irlock driver part.

My steps:
0. Check Pixy with PixyMon, interface is set to i2c. Pixy is visible on Raspberry Pi with i2cdetect (with default address 0x54).

1. Connect Pixy to i2c A bus on Pixhawk 4 controller.
2. Use QGroundControl console to command "irlock start"
   It says "failed to initialize device, stopping driver"
3. Connect i2c bus to sniffer made of Raspberry Pi and pigpio.
4. Try to communicate with other i2c sensors: PX4Flow and LW20 Lidar work great. Sniffer shows messages running.
5. Disconnect sensors and start their drivers manually:
   "px4flow start" shows initial message [85-] from controller.
   "sf1xx start" does nothing
   "sf1xx start -a" shows initial message [CC-] from controller. With sensor connected this command shows that Lidar is connected to i2c bus 4.
   So "sf1xx start -b 4" shows initial message [CC-] from controller.
6. Try irlock with bus 4 and then from 0 to 3
   irlock start -b 4 (and so on) no initial messages from controller are displayed in sniffer console.

The power source was checked, Pixy voltage is 5.0V checked.
I tried to power Pixy before, after and from Pixhawk.
I tried to have only Pixy on the i2c bus and all sensors together. The result is the same: controller does not initiate communication.
I tried Pixhawk with 1.8 stable and the latest master.

[ndepal]

@roboflot
I have no experience with the Pixhawk 4. We are using the IRLock Pixy with PixRacers and never had any issues. Do you have any other Pixhawk models at your disposal for testing?
Did you flash the proper firmware on the IRLock Pixy?

[roboflot]

@ndepal
Thank you for your reply! I don't have any other Pixhawk board. But I successfully tested my Pixy with Ardupilot on Navio2 and Raspberry. So the firmware is OK, it also works fine with PixyMon and original IR-Lock MarkOne beacon. I tried to compare irlock and sf1xx lidar (it works OK) drivers on how they initiate i2c communication. But I'm very noob in C++ and it seems for me they have the same headers, includes and i2c class calls. Any advise on where to go deeper in code would be very helpful.

[jonathan84clark]

I actually was able to get this to work with ArduPilot on the Pixhawk 2.1. I used I2C bus 0 as my bus setting.
I also had to put a special magical version of the firmware on the Pixy in order for it to work as an IR-LOCK sensor.
And finally; I needed to have a Lidar connected and working in order for precision landing to work.

We are moving to ArduPilot for future projects that require precision landing. I don't like the fact that ArduPilot has inferior debugging tools compared to PX4 (which has a fantastic CLI that you can use for debugging and testing) but it does seem like ArduPilot has better driver support for sensors and other hardware.

One other thing I noticed is that the I2C ports and how they map to port settings seem to be pretty ambiguous in the documentation for both flight stacks. However after reading through tons of forums I have found that people have had success with I2C in many cases by daisy chaining their I2C devices off the GPS I2C bus instead of the dedicated I2C bus, that is another thing you could try.

At some point in the future I may be revisiting this issue. Ultimately I think that each flight stack needs to clearly document which settings need to be used to access each port. I may even put together some documentation for that.

[roboflot]

@jonathan84clark
That is a good idea to try other i2c ports! Thank you )
As I found out for Pixhawk 4 fmu_v5 the regular I2C_A port is i2c4. There is also UART/I2C_B port which is i2c2 and GPS module port with i2c1.
I'll try them tomorrow and write down here about results.

[hamishwillee]

@jonathan84clark @roboflot

Would love your help with any required documentation for I2C.

One other thing I noticed is that the I2C ports and how they map to port settings seem to be pretty ambiguous in the documentation for both flight stacks.

Generally speaking I've been told that for end users I2C should be pretty much plug'n'play. You can either attach direct to an I2C port or via a splitter. However if there is something missing (and I'm sure there is), particularly for I2C peripheral developers/debuggers we should certainly add that.

As a summary of what we have now:

• I2C Bus Overview (Devguide)
• User guide
  • various docs for peripherals that use I2c - e.g. SFXX Lidar
  • Pinout docs on peripherals - e.g. Pixracer

[F1nsk]

I have the same issue with the PX4, running the newest firmware. I will try changing I2C ports, and report back if it makes any difference.

[roboflot]

The first try was lucky! I got IR-Lock (Pixy) working on Pixhawk 4 (fmu_v5) with GPS port i2c.
Here is screenshot with "irlock start", "irlock info" and "irlock test" output.
And here is PDF doc with Pixhawk 4 connectors pinout for reference.
So the issue is in I2C ports assigning in firmware.

And now I'm thinking on how to make a tricky wiring and share this port with original GPS module.

[jonathan84clark]

Its too bad it has to work like that. I2C is supposed to be plug and play. It seems inconvenient to have to re-wire the GPS port to work as I2C.
I know that ArduPilot doesn't have any issues using the I2C bus in the center of the Pixhawk 2.1. I wonder if there is an issue in PX4 with that particular port?

[hamishwillee]

@bkueng This highlights possible problem with I2C driver. Essentially pixy IR-lock camera works on the GPS connector I2C port on Pixhawk2 but not on the "dedicated" I2C port. Is there some thing we can do to help these guys help us find root cause?

[bkueng]

Is there some thing we can do to help these guys help us find root cause?

Yes we can change the default port or scan all ports. @DanielePettenuzzo is the right one for that :)

[DanielePettenuzzo]

@jonathan84clark @roboflot With this PR you can start the driver with the -b argument on any bus: #10673. It is explained inside the pr. I will also implement the -a argument to scan all busses. Let me know if it works.

[roboflot]

I've just installed the latest master and I confirm IR-Lock successfully starts with "irlock start -b 4" on I2C A port. No tricky wiring needed! Holybro Pixhawk 4 FMU_v5.
I also tried my other sensors together with IR-Lock on the same bus (PX4Flow and LW20 Lidar) and they all work fine.
@DanielePettenuzzo The "-a" option (like in sf1xx lidar driver) will be very helpful. Thank you )

@ALL Thank you guys a lot for your help!

[hamishwillee]

Thanks @DanielePettenuzzo (and @roboflot for testing).

@DanielePettenuzzo @bkueng This is cool, but even if you add the -a option it isn't very "plug'n'play". What I'd love to see is landing estimator and irlock driver in firmware by default, and driver/module startup configured via parameters. Any chance of that happening?

[Crowdedlight]

I can confirm the changes made it possible to start irlock on "I2C 2" with irlock start -b 2 on pixkhawk 2.1. I am working together with @F1nsk and we got it running now. We will be doing a test-flight in a couple of weeks to confirm it works "in the air".

Thanks for fixing it!

[DanielePettenuzzo]

@hamishwillee I can add the -a option in the driver so that we can then use a param in the startup script. When the param is enabled we start the driver with the -a flag so all available busses are scanned.

[hamishwillee]

@hamishwillee I can add the -a option in the driver so that we can then use a param in the startup script. When the param is enabled we start the driver with the -a flag so all available busses are scanned.

That is awesome. This should be default behaviour for every sensor and peripheral (ie user should be able to turn things on an off through UI). Only exception would be fmuv2, where they might have to uncomment the drivers.

[F1nsk]

Has anyone been able to make IRlock work, while flying?
When I use the CLI command Irlock Info It outputs; read errors which increments while the beacon is being detected.

[jonathan84clark]

Hmmm. I have been able to get it to work flawlessly with ArduPilot.

One thing you should do is make sure you put the right firmware on the Pixy. https://irlock.readme.io/docs/firmwaresoftware-links
That issue actually held me up for a week. I figured that the Ir-lock system would actually have ir-lock firmware on it. I mean, it makes sense right? (IR-LOCK Pixy, IR-LOCK firmware). But no, you need to install a special magical version of firmware on the Pixy for it to behave like an IR-LOCK sensor for PX4/ArduPilot.
Go through the setup steps on that link. Then after that see if you get communication with no errors. You also need to have the correct bus (at least I did for my code and mine was 0). In ArduPilot you need the PLND parameter set to 2 for IR-LOCK.

[VTOLDavid]

Has anyone been able to make IRlock work, while flying?
When I use the CLI command Irlock Info It outputs; read errors which increments while the beacon is being detected.

Same here, I tried precision landing from mision and it does a normal landing. I installed on pixy the firmware provided by IR-Lock . Did you solved it? What I am doing wrong?

[F1nsk]

From the log I can see irlock detects the beacon, but it abandons precision landing on it because it times out. I thought about disabling the Kalman filter but it is not an option in the px4 stack - as far I am aware.
So I haven’t solved but I’ve ran into more issues.
My group and I will do a field test end of this week. I’ll follow up with the results, if any.

[VTOLDavid]

Hi, here is a log not doing a precision landing? Any idea why the errors?
https://logs.px4.io/plot_app?log=8d0f69b5-3556-492a-ac9c-fb98d601ace8

[LorenzMeier]

@ndepal Could you have a look?

[ndepal]

@VTOLDavid The reason why the precision lander is timing out during the horizontal approach phase is that it is not able to control the horizontal offset to < 0.2 m (PLD_HACC_RAD) within the required time (PLD_SRCH_TOUT). This is a requirement to proceed to the next phase of precision landing, the descent.

This may be due to poor position control performance.
I also notice that you're trying to initiate precision landing from quite far up and with a rather large horizontal offset to the beacon. While the beacon is still detected successfully, the horizontal transition takes more time because of this.

Things you can try:

• initiate precision landing at < 10m agl, < 2m horizontal offset. In this situation the default timeout parameter should be sufficiently large.
• improve position control performance through tuning
• increase the timeout parameter PLD_SRCH_TOUT
• increase the horizontal acceptance radius PLD_HACC_RAD. If this is necessary, I'd also expect a worse than optimal precision landing accuracy.

[VTOLDavid]

Thank you! I will test it today.

[VTOLDavid]

After some tuning It landed perfectly, even with the beacon moving.

[ndepal]

@VTOLDavid glad to hear that. What did you end up tuning? Perhaps it's worth adding your learnings to the precision land user guide.

[F1nsk]

@VTOLDavid it would be awesome to see your tuning parameters.

[VTOLDavid]

We flew with a little quad we use for tests. It was not properly tuned in position so that was the first thing we did. We limited angular speed to 100deg/s, we suspected that fast changing angle was not helping with beacon detection.
We started with this values:

PLD_FAPPR_ALT=1
PLD_HACC_RAD=0,8
PLD_MAX_SRCH=5
PLD_SRCH_ALT=7
PLD_SRCH_TOUT=100s

LTEST_MODE=Stationary

All others parameter related with precision landing were as default.

We tested the precision landing sending this command from Qgrouncontrol command line:
commander mode auto:precland

We have to test if using the mission command we get the same result. Theoretically it should be the same.

Later, we decreased PLD_HACC_RAD to 0.6, increased PLD_SRCH_ALT to 20 and LTEST_MODE to MOVING.

We moved the beacon once the landing descent had started from 20m and it followed the beacon and landed over it. Moving the beacon to fast made the drone to lose it and climbed to 20m again. I supposed that once at search altitude it would actively search, moving in spiral or following a circumference but it stayed in hover until the time PLD_SRCH_TOUT=100s was over and then landed normally.

We probably test a wider angle lens since it loosed the target quite easy.

I would share a proper log but I forgot to remove the log config file from the sd card and loged landing_target_pose and vehicle_local_position.
https://logs.px4.io/plot_app?log=b0a446c3-7363-4596-aa1f-3ee3df01ba0a

[beenjamminnallday]

Hello, any chance some of the logs posted by @VTOLDavid are still available? I'm having the same issue. I'm trying to compare results before trying out his tuning values.

[beenjamminnallday]

PS: Using @VTOLDavid 's values, my drone lands precisely within a reasonable radius every time.

What I did to get it working without having to build my own version of px4 to have the irlock driver and landing target estimator module running:

• MAVLink console to /fs/microsd/etc, if the folder doesn’t exist create it. Create a file called extras.txt in the said folder and add irlock start -X & landing_target_estimator start . Reboot.

• These were my variables, generally I found search alt and final approach altitude seemed key, tune these until it works for you:

LTEST_MODE = Stationary
RTL_PLD_MD = Required Precision Landing
PLD_BTOUT = 5
PLD_FAPPR_ALT = 1
PLD_HACC_RAD = 0.8
PLD_MAX_SRCH = 5
PLD_SRCH_ALT = 7
PLD_SRCH_TOUT = 100

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-june-14-2023/32616/1