EDIT 2019-07-03: NOW SOLVED. If you’re using a Holybro Pixhawk 4 with Copter 3.6.9, and an IRLOCK Pixy camera connected to the I2C A port, set the PLND_BUS parameter to 3 (this is currently not a named parameter in the firmware). This will probably work with IRLOCK compatible versions of Copter older than 3.6.9 as well, but I have not tested this. Credit to Fabian below for finding the solution.
First of all, thanks a lot to Thomas Stone who’s been helping us with the issue described below via email
Has anyone managed to get the IRLOCK precision landing system to work with a Pixhawk 4 FC, and any of the ArduCopter firmware versions?
The Pixy is working on its own fine and detecting the MarkOne V3 beacon just fine. Our problem is, we can’t get our IRLOCK Pixy camera to communicate with the flight controller successfully (It’s being powered via I2C, but something is wrong with the signal). In Mission Planner, this problem produces the “Bad Vision Position” message, and it appears in the .bin file as the PL HEAL value being 0.
We’ve tried everything we can think of: we’ve been through every relevant part of the various different documentations we can find, tried every combination of sensible (and not so sensible) PL parameters, and tried three different Pixy firmware versions, including obviously the latest and recommended one.
The Pixhawk 4 has a 4 pin “I2C A” port, and a 6 pin port labeled “UART & I2C B”, and we’ve tried running the Pixy off of both these I2C ports, and in each case, have tried all three options of the PLND_BUS parameter (DefaultBus, Internal I2C, External I2C).
Here are our FC firmware details:
FC: Pixhawk 4
FC Firmware version: 3.6.9 Pixhawk 4. We’ve also tried 3.6.3 FMUv5 (what we were on previously)
Lidar: Benewake TFMini (working with the FC and giving sound readings)
I can post more details about the Pixymon settings, but given everything we’ve tried, I was really just hoping to find out first if anyone knows for certain that the IRLOCK system can work with the Pixhawk 4 plus ArduCopter?
Hi Tom,
I have exactly the same problem. Pixhawk 4 and 3.6.9. It is said that it would possibly work with the i2C of the GPS port, but I have not give it a try…
Fabian, thank you so much for this information; it reassures that I’m not losing my mind!
In my googling around for a solution, I had come across the same github issue about PX4 + IRLOCK that you linked, and suspected it could be the root cause of the issue, but thought it could also just be caused by some other issue in the PX4 stack.
But as you’ve got the same issue as me in ArduCopter, my guess would be that their issue is also our issue: that is, that the FC is looking for the Pixy through the GPS port.
Furthermore, I notice that later in the github issue, Daniel Pettenuzzo links a pull request, and it is confirmed by others that his changes allow the Pixy to be detected on the I2C A port after running the command “irlock start -b 4”.
When I have the time, I’ll try and rewire my GPS port to test if it works with the Pixy, but I think there’s probably reason enough to raise this as an issue, as not being able to use the dedicated I2C ports is pretty inconvenient.
Hi Tom,
I just bridged the I2C A and I2C GPS together. With plnd_bus = -1, the message “Bad Vision Position” is gone. But now the compass is not working anymore! I will wait until this error has been fixed by firmware update.
Please keep me up to date if you know something new.
Thanks for doing that check Fabian. I’ve opened an issue on Github and cited this discussion.
I’ve just done a quick check, and even though we know that the communication on the I2C A port doesn’t work for the Pixy, there is still voltage at the SCL and SDA pins of the I2C A port, and so something may be configured to communicate on the port. As such, when you bridge the connections as in your picture it’s possible that that the I2C A port is sending some unwanted signal to the Pixhawk via the GPS port, and that this is messing up the signal chain.
A different way to try the splitting would be to ignore the signal pins on the I2C A port completely and just split the I2C signal of the GPS port. I reckon it’s safest to still power the Pixy from the I2C A port so as to not run too much current through the GPS port. So in your picture, this would mean de-soldering the additional wires you’ve connected to the I2C A port, and instead connect them directly to the Pixy’s signal pins, and severe the connection from the Pixy’s signal pins to the I2C A port’s signal pins. I’ll try and give this a go today.
Thanks for your reply! I am glad that we work together on the problem.
The I2C A port works (at least except the IRLOCK), after all I connected the LW20 in the same way as the IRLOCK there in parallel. But only the LW20 works. However, recently the LW20 recognizes whether it is connected via I2C or serial. Maybe that bothers the IRLOCK somehow. I will try to connect the IRLOCK alone.
Using the GPS SCL and SDA pins only sounds good! But you can use the same pins for power supply. All I2C ports on the board share the 5V.
Tell me if it worked and your Pixhawk still finds the external compass afterwards!
@Michael_Oborne: Could you please add this note to the parameter settings in the Mission Planner: For pixhawk 4 and probaly for pixhawk 2 also, the plnd_bus is 3. This will certainly save people a lot of work.
Just tried this, the Bad Vision Position message is gone! I’ll give this a test when I can. Well done on figuring this out, I hadn’t thought to try unnamed parameter values for PLND_BUS. Thanks a lot for helping out with this I’ve closed the issue request and put a note of the correct parameter value in a comment.
I know you got this working already, but I recently got an IRLock running with a Garmin Lidar Lite V3 both using I2C on a Pixhawk 2. Had I seen this earlier I would have offered some help. I set PLND_BUS to 0. I followed all the directions from these two sites. Took some finagling but I eventually got it to work:
A stupid problem I had (my fault) was that I couldn’t see all the precision landing (PLND_) parameters because PLND_ENABLED needed to be set to 1, then power cycle the board to see the remaining parameters. I didn’t power cycle the board so the expanded parameter tree was never even accessible until I figured that out.
Thanks for chiming in with your use case. The first thing I looked at when trying to do this was the IRLOCK readme you linked, which was very helpful in getting the Pixy and MarkOne working with each other, but didn’t succeed in getting the Pixy to communicate with my Pixhawk 4, hence this thread.
It’s unfortunate (for me), that there is very little information for using the Pixhawk 4 with ArduPilot, and that the documentation is largely modeled around the Pixhawk 1 and 2. I recognise that the Pixhawk 4 is primarily designed to run PX4, and if I’d known how the Pixhawk open hardware project actually works when I started out I’d have probably made a different choice of Pixhawk than the 4; it was quite difficult to get started with when I had no prior experience of the software.
@tbrs2, @Ian_Joyce, @Fabian,
This thread is very helpful to me. I plan to implement Lidar for object avoidance and some type of localized beacon, such as IR for precision “docking” for an agricultural rover. How well do your respective implementations work in full sunlight?
I haven’t been able to test the IRLOCK extensively yet, as I’ve only just been able to get it working with the FC, so unfortunately don’t have any use cases to share with you, and so can only parrot what the documentation says. IRLOCK claims that with the right settings, the Pixy will not detect sunlight.
Incidentally though, I did test the IRLOCK properly for the first time today, and experienced this instability problem:
or at least I’m pretty sure it’s the same issue. If anyone reading this can share some insight on that thread please do!
Thank you for the hint on the PLND_BUS . I am using Pixhawk 4 mini, I2C 2, and had to set it to value 2, and then both the IR Lock and Lighware LIdar worked (both were not working before).
Dear all,
I’ve been desperately trying to my IR-Lock on My Pixhawk4 V5.
There are few questions marks :
1°) Connected on I2C A : PLND_BUS=0 ?
2°) Pixmon : using Pixmon on windows 1.0.2 pixy firmware 1.0.3
that’s confusing as the hex is named “firmware_IRLOCKpixy_1.0.1.hex”
or “MarkOne_1.0.1.hex”
So here
Data out Port = 0 ?
=> PL - Heal always = 0 as well as all other values in consequences.
Can anyone help me to connect my Ir-Lock on I2C ?
Settings on pixmon (versions & values)
Settings on pixhawk
=> how to monitor in real time (mission planner) if I2C communicates or not ?
Hello,
We finally acheive to make the IR-Lock running so here is a retex: (if that can help someone)
Well, The Pixmon used was Pixmon on windows 1.0.2
(Latest do not support Ir-Lock firmware).
The “Data out port” set to 1
Firmware : we tried both “firmware_IRLOCKpixy_1.0.1.hex” or “MarkOne_1.0.1.hex"
Clearly this first one was working much better (more stable position corrections really smooth)
Regarding Arducopter in mission Planner we used PLND_BUS = 3.
I have to admit that we would have never try “3” if we did not read that post, so thanks.
We are running ArduCopter 4.0.6
=> It work really good so far, i will try limits.
Also to answer to my question
François we can visualize in real time in mission planner (CTRL+F) VISION POSITION all 3 block to turn green.
Hey i can’t visualize my plnd message in real time, in ctrl+f menu i don’t have the vision position menu, did you do something to get it ? Also, where did you get the firmware_IRLOCK_1.0.1.hex ?
I’ve closed the issue request and put a note of the correct parameter value in a comment.
so here is a retex: (if that can help someone)
we can visualize in real time in mission planner (CTRL+F) VISION POSITION all 3 block to turn green.