uzh-rpg / rpg_emvs

Code for the paper "EMVS: Event-based Multi-View Stereo" (IJCV, 2018)
141 stars 51 forks source link

Using other datasets (Prophesee event camera PPS3MVCD) #14

Open grammers opened 3 years ago

grammers commented 3 years ago

I have been trying to use the EMVS on data from a Prophesee event camera PPS3MVCD without success. I have adjusted the code to run on the Prophesee_event_msgs and the topics for our motion capture system. Moreover, looking into the Prophesee ROS msgs and Davis ROS msgs seems to have a similar structure.

The code executes without errors but the output is not the expected. The first observed place with unexpected results is in the Disparity Space Image (DSI). It looks like the event rays are parallel and therefore don't intersect, causing the DSI to lack dense areas.

dsi_prophesee_dataset In the figure above, the right part of the scene should be close to the camera and the left part of the scene should be further back. Changing settings can change how clear the contours are but there are no settings that improve the depth image.

depth_colored

I recorded a dataset that includes geometry_msgs/TransformStamped data from Vicon Motion capture system as well as prophesee_event_msgs/EventArray data from the Prophesee camera.

The event camera is calibrated using the Prophesee camera calibration method: metavision_mono_calibration (https://docs.prophesee.ai/metavision_sdk/modules/calibration/guides/intrinsics.html?highlight=calibration)

Could you please let me know whether there are some constraints on how the datasets need to be recorded? Or do you have any insight into what could be the issue?

Thanks for your time in advance!

guillermogb commented 3 years ago

Hi. I assume you tried the examples in the Readme and they work fine. The question, when the rays are so parallel in the DSI, is... do you have enough (temporal) baseline? If the camera moves only a little one cannot expect to get accurate depth with EMVS.

grammers commented 3 years ago

Yes, the README examples work fine. I will record a new dataset where I make sure I have enough camera movement.

grammers commented 3 years ago

I recorded new data sets with different higher speed movements (of the camera). I played with the configurations, changed the time span, and so on. The best result I manage to get where this (one of the most promising results yet). Screenshot from 2021-01-20 09-43-17

I don't know what else to test, any help would be appreciated. Below are links necessary to replicate what I have done.

The adapted code can be found in this repository grammers/rpg_emvs/tree/prophesee in branch prophesee. There can the .conf I used also be found. The bag file can be found here.

guillermogb commented 3 years ago

The topic /prophesee/camera/camera_info is empty. Do you have the intrinsic calibration of the camera that you used to record the sequence?

grammers commented 3 years ago

Yes, I have hardcoded the camera calibration in main.cpp

guillermogb commented 3 years ago

My guess is that the data is not good... Sorry if it sounds like "blaming others". I inspected the data; see the results and video attached here, recorded at half the speed. The first 1.8 s of data or so look ok, but there is not enough baseline to produce a good 3D reconstruction (results and conf file in the link above). After that, the events look like coming from "washed out" edges instead of sharp ones (I do not know why - maybe there is some bottleneck in the data transmission or acquisition) thus, it appears to me that they are noisy and EMVS cannot do much with them.

Suggestions:

Cheers

grammers commented 3 years ago

I'm having problems finding a good camera bias tuning, to achieve good data. If you wid you're experience can give me any suggestions of how to find them would I appreciate it? The parameters I have are the following.

Name My value in mV Description
bias_pr 1250 impacts the operating point of the event-based pixel front end, mainly the photodiode
bias_fo 1580 controls the pixel low-pass cut-off frequency
bias_hpf 1500 controls the pixel high-pass cut-off frequency
bias_refr 1800 controls the refractory period. It represents a dead time for which the pixel will be kept in rest after an event acknowledgment.
bias_diff 300 controls the reference voltage of the comparators
bias_diff_on 460 controls the thresholds for positive events
bias_diff_off 220 controls the thresholds for negative events

I also have an "activity filter temporal depth" that can be tuned, it is currently set to 2ms.

guillermogb commented 3 years ago

Maybe this is a question for the support team at Prophesee, sorry.