GenX320 Active Marker Biases Cause no Negative Events

When the GenX320 is configured using the Active Marker bias preset, or by manually tuning the bias_hpf parameter above a value of ~87, it appears to prevent events with a negative polarity. With this bias configuration applied my program only receives events with a positive polarity.

This isn’t the case using the same bias settings for the GenX320 running on a Raspberry Pi and using the Prophesee driver. Does anyone have any ideas about how to correct this on the OpenMV platform?

Without negative events it becomes impossible to demodulate active marker IDs.

Hi, did you try running their active marker script?

They show off a video demo using this script which works to track the marker.

Yes, this program runs fine but also exhibits the issue I’ve described where no negative events are received. The image that’s produced has only white event pixels shown and no black negative event pixels.

I’m trying to not only detect but also decode the ID of each active marker. To do so the on-off pulse modulation sequence needs to be observed in the event stream.

Above: OpenMV with active marker biases set and LED blob tracker running. No black pixels in output histogram means no negative events.

Above: OpenMV with default biases, black and white pixels shown. Receiving both positive and negative events.

Above: RPi with active marker biases set. Output shows white (positive event) and light blue (negative event) pixels. This is rendered with the default Metavision SDK color scheme, different to OpenMV’s greyscale method.

With some more testing on the OpenMV I have observed up to 1 negative event will every now and then come through in the data, but it’s clear that something is wrong. On the RPi there are an approximately equal number of positive and negative events when doing active marker tracking.

I’ll have to ask Prophesee. They sent the PR for that code.

Sent them an email.

Thank you! Hopefully they have a simple fix that can be applied to resolve the issue.

Hello,

could you precise if you use the original Active Marker board from Prophesee or did you program the LEDs on your own?

To receive more events, we suggest disabling the AFK filter (if it is not the case yet), as it filters out some events: csi0.ioctl(csi.IOCTL_GENX320_SET_AFK, 0)

Also, please note that the example script**genx320_histogram_mode_grayscale_led_tracking.py** uses a histogram mode and not an event mode used in Metavision SDK/OpenEB, thus events are post-processed into a histogram. Therefore, the outcome is quite different, and the resulting data are not comparable with the data from Metavision SDK (on your screenshot).

Hi Natalia,

I am using the active marker board from Prophesee that comes in some of the dev kits.

As for the camera, it is running in event mode and has AFK disabled. Here is some example code that can reproduce the problem and print a count of the positive and negative events. If I comment out the active marker bias line of this code the sensor produces both positive and negative events. With active marker bias set, it produces only positive events.

import csi
import image
import time
from ulab import numpy as np
img = image.Image(320, 320, image.GRAYSCALE)
events = np.zeros((2048, 6), dtype=np.uint16)

# Initialize the sensor.
csi0 = csi.CSI(cid=csi.GENX320)
csi0.reset()
csi0.ioctl(csi.IOCTL_GENX320_SET_MODE, csi.GENX320_MODE_EVENT, events.shape[0])
csi0.ioctl(csi.IOCTL_GENX320_SET_BIASES, csi.GENX320_BIASES_ACTIVE_MARKER)
csi0.ioctl(csi.IOCTL_GENX320_SET_AFK, 0)

clock = time.clock()

while True:
    clock.tick()

    event_count = csi0.ioctl(csi.IOCTL_GENX320_READ_EVENTS, events)
    pos_count = np.sum(events[:event_count, 0] == 1)
    neg_count = np.sum(events[:event_count, 0] == 0)
    print("Read %d events (pos=%d neg=%d)" % (event_count, pos_count, neg_count), end="\r\n")

    img.draw_event_histogram(events[:event_count], clear=True, brightness=128, contrast=64)

    img.flush()

    print(event_count, clock.fps())

For example, here is an output line with active marker biases not set:
Read 819 events (pos=446 neg=373)

And an example with the active marker biases set:
Read 707 events (pos=707 neg=0)

Hi,

thank you for providing all the details and the code example.

Please, note that the active marker biases were tuned in purpose to generate only ON events due to the software algorithm used for the marker tracking.

If you would like to see OFF events, you can adjust the biases (in your case, you can decrease the negative contrast threshold bias_diff_off to make the sensor more sensitive to negative light changes). Here is an example for setting biases one by one and you are free to tune them for your purposes:

csi0.ioctl(csi.IOCTL_GENX320_SET_BIAS, csi.GENX320_BIAS_DIFF_OFF, 31) #127
csi0.ioctl(csi.IOCTL_GENX320_SET_BIAS, csi.GENX320_BIAS_DIFF_ON, 58) #78
csi0.ioctl(csi.IOCTL_GENX320_SET_BIAS, csi.GENX320_BIAS_FO, 50) #50
csi0.ioctl(csi.IOCTL_GENX320_SET_BIAS, csi.GENX320_BIAS_HPF, 127) #127
csi0.ioctl(csi.IOCTL_GENX320_SET_BIAS, csi.GENX320_BIAS_REFR, 0) #0

Hi Natalia,

I was able to get around even on and off events after putting the bias_off value lower as you suggested. What I find odd is that the same bias settings on the Raspberry Pi don’t produce the same results. I can tune the bias_off setting much higher on the RPi before losing off events. For example bias_on and bias_off both set at 50 on the RPi produce about even numbers of on and off events. Do you know what the cause is for this discrepancy on the OpenMV platform?

Lastly, I was able to rework my active marker decoding algorithm to use only on events and to time the gaps between rising edges. This is all you need to effectively decode the marker ID since each symbol starts with an pulse of light followed by different lengths of off time. This allows me to use the default active marker bias settings for the OpenMV.

Indeed, this is strange. Which optics do you have on your raspberry kit ? M6 or M12 mount ?

Great that you managed to find a workaround (indeed ON events are enough) and we are sorry for slow response.

Hi Natalia, sorry for the long delay I have not been able to work on this project for a long time and am coming back to it now.

The RPi kit has a M12 lens, it is from the GenX320 starter kit that Prophesee sells.

Unfortunately this issue of not providing negative events while under active marker bias settings on the OpenMV platform is coming back to be an issue again, despite my initial work around. Do you have any updates on fixing the problem?