IRLOCK and I2C

I am playing around a bit with an Irlock sensor. So far i haven’t be able to make it work.

Looking at the logs it seems that the apm doesn’t talk to the sensor itself because none of the PL (precision landing) variables seem to register anything, including Heal that should go to 1 if the sensor sees the target.

Now what i want to test is lowering the I2C speed from 1Mhz to a lower value. Since i know the system works on Pixhawk, is there anybody that knows what speed Pixhawk uses the I2C bus at?

Also lowering the Navio 2 I2C to a lower value can cause any prob?

regards,
Corrado

At the current state of the code, you should be fine setting a lower speed. Looking forward to seeing your results!

tried 400khz by modifying /boot/config.txt but still no joy.

i2cdetect sees the sensor at address 54 with no problems as it should be.

Any advice is accepted :smile:

Corrado

Okay, it seems like it’s a Pixhawk only feature at the moment. Is there any chance you want to add support for this sensor yourself? Otherwise, I reckon I might be able to adapt the driver by the end of next week.

You mean even if i run 3.4-rc1 the PL features has not been implemented in the Navio porting?

I can try doing it myself with some guidance :slight_smile:

Corrado

So, here’s what I would do.

  1. Inspect the IRLock interface in AP_IRLock library. As you can see in AP_IRLock.h it’s a PX4-middleware dependant feature.
  2. Look into the implementation of AP_IRLock_PX4. It’s pretty obvious what’s going on there, namely the driver reads a struct irlock_s from file descriptor obtained from PX4 Middleware stack. This struct is the only thing that really matters. We need to populate it somehow.
  3. How it’s populated? That’s a good question! The answer lies in an another repository. Apart from boilerplate code the driver is extremely small (less than 100 LOC).
  4. Take a look at read_device method. This is where all the meaty stuff at.

These links should help too: official IRLock docs and ArduPilot docs on that matter.

If you’re feeling adventurous, you can also come up with a isolated IRLock example like this one. This would be great for the community and also would make it easier to debug the driver.

This is a rough step-by-step tutorial what and how can it be implemented.

This is wayyyyyyyyyyy beyond and above my capabilities, i guess i have no other options than wait for you guys to release support for it, hoping it’ll come soon.

Corrado

Sure! But you’re exaggerating, though. It’s not that difficult! I kind of laid out everything that’s gotta be done. As I said before, I guess someone in our team will have time for that not earlier than next week.

Hello there any news?

I would be more than happy to beta test and i think a lot of people would be interested in this system since it is a relatively low cost precision landing device.

Corrado

No, there are no updates on this. As I said we are busy with other stuff with higher priority. We may get to it eventually, but this is not something we can get working on soon.

Understand you are interested only in the reach stuff, all the rest are small probs that people have to manage themselves.

Thanks for the support.

Corrado

Please, let’s be a little more friendly and polite :slight_smile: We’re doing our best to support our users.

I feel kinda responsible for the way you feel. That’s why I hacked this driver today after work.

Unfortunately I won’t get an opportunity to test it on the real hardware before the weekend or the beginning of the next week.

After bench-testing we usually try testing every new piece of hardware in air. If you want, you can go ahead and test it out on your own risk before our flight tests which we cannot schedule on every request. Otherwise we wouldn’t have really got anything done. As we’ve said before we have many tasks of a higher priority on our plate right now.

Take care and once again I encourage everyone to not feel that agitated. You know, I guess this all’s gotta give everyone some pleasure, right?

1 Like

ohhhh wow that’s soooo great…thank you I was also looking forward for irlock support;

“I want it now” (in different variations) are just not the right words if somebody wants something;
Sarcasm is very impolite and especially if somebody asks for something it should not be used;

I really think @emlid is giving great support, much better than 99% of companies; using their support forum to threaten or discredit them is just wrong; criticism can be made - but politeness should be held up like in real-life… @george.staroselskiy fulfilled your wish quite fast - @Corrado_Steri although you were really impolite…you should really thank him - more than 99% of people wouldn’t after your last post;

Actually I contacted Irlock a few hours ago - because they have a picture of Navio2 on their homepage and irlock is more expensive than Navio2 and landing is their main feature - and asked them to implement Irlock into Navio2;

Anyway I greatly appreciate your time and your support is outstanding;

I will test irlock as soon as i get it…

1 Like

Didn’t mean to be unpolite, just understand reach is main focus based on forums attention to the topic.

That been said, i’ll be more than happy to risk our machines to test the driver.

Corrado

Hello, is there any news on this?

Corrado

Any news about the “hacked driver” you did 2 weeks ago after work?

Corrado

I understand that emlid has decided to help you out but have you tried contacting IRLock and ask for support such as panky as done?

Yes, contacted IRLOCK too. Asked them if they could even get in contact with Emlid.

Corrado

In all honesty IRLOCK should be doing the heavy lifting of integrating it, and making it a general purpose driver vs a PX4 middleware. If emlid can provide you with a hacked up driver to test kudos to them.

If anyone can explain why they made it a middlewear I would be interested to hear.

I gave them the link to this forum and i hope they read it and try to go forward with it and answer your question about how they implemented it too.

regards,

Corrado

1 Like