<< return to Pixycam.com

IRLock Lidar interference

Pixy Software
#1

Hello, completely new here.

*edit: this question is not IRLock specific but is about how the camera process each frame

I’m making yet another precision landing system on a drone using IRLock + IRLED(not the beacon) and Garmin Lidar Lite V3, both on same I2C.
Problem: The Pixy is picking up lidar flashes.
I tried working at 25Hz and discarding half of the frames which I trigger lidar measurement but Pixy still occasionally detect lidar flashes from upto 80cm.
The lidar only flash when commanded and takes less than 10ms.
Tried adjusting timing but still not 100% gon
*both sensors are running on ROS on RPi3

Can I2C possibly lose sync and grab the bad frames? I think I had better result with SPI but I2C is cleaner.

From my understanding, Pixy process each frame and puts data in a buffer waitng to be read which gets flushed/replaced every 20ms(50Hz).
What happens when the data is being read while new data arrive?

Thank you.

#2

Hello Pitt,
When you say “flashes”, I assume you are talking about data from Pixy that is somehow influenced by the lidar system. Is the data slightly wrong, but formatted correcly, or is the data more or less corrupt?

Can I2C possibly lose sync and grab the bad frames?

This is not something I have heard happening with i2c and Pixy.

What happens when the data is being read while new data arrive?

The new data is queued up to be read later.

Can you describe your setup? What size pullup resistors are you using for i2c? How long are the cables? What i2c clock rate?

Edward

#3

The camera is working perfectly fine, no corrupt data.
The problem is that it is detecting infrared laser “flash”(short pluse) emitted by lidar.
In other word, it is picking up avoidable noise and provide false data.

What I’m trying to do is, since Pixy works at fixed 50Hz or 20ms between frames,
1.trigger lidar. Pixy should clearly see the laser and saved as a block waiting to be read.
2.wait for Pixy to process next frame after laser stopped, discard the previous frame
3.read the new clean frame
Repeat
This does not work…on I2C.

Pixymon capture:
1536207187287-1
3 dots in triangle are LEDs that need to be followed
A white dash slightly below is the laser emitted by lidar

Setup:
1536207174296
Both sensors are connected directy to Raspberry Pi3 GPIO and external 5V supply!

Edit: uploaded pics…twice

#4

Hello,
One challenge is that asking Pixy for new data doesn’t affect when Pixy will begin its next frame. Each frame is grabbed and processed at fixed intervals. You may need to discard more data to be sure that the laser is not part of the image. In other words

    turn_off_laser();
    set_timer()
    while (get_timer()<discardInterval)
       read_pixy_data();  // don't do anything with the data (discard it)

    read_pixy_data();  // data good here

This is pseudo code of course. By increasing the discardInterval value until the data is good, you should get where you need to be.

Hope that helps :slight_smile:
Edward

#5

This corresponds to my experiments.

Do you have any explanation on why SPI gives better result?
I got bad frame in at as low as 5%(of all read blocks) on I2C but easily 0.1% on SPI.
Also, when connected to Pixymon and SPI, I got the connection message flushing on Pixymon as if it’s reconnecting rapidly.

I’m currently using SPI(3 extra cables) and have almost no interference so I may stick with this.

#6

What clockrate did you use for SPI and I2C? Perhaps the clockrate for I2C is lower. 100Khz for I2C and 1Mhz for SPI is typical.

Edward

#7

Exactly
100k i2c
1M SPI

I did make sure the total read time is well below 20ms.