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.
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: 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.
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).
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.
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:
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.
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?