After studying the EPnP source code and demo code last week, it is time to start hands-on coding. The aim is to integrate the EPnP code into the object-in-video that I made during the recess week, in order to obtain the estimated camera translation and rotation.
Calling the function compute_pose() triggers a break point when the program runs. This problem is rectified by keeping the number of correspondences constant throughout the entire code instead of setting it to be the number of correspondences found in every frame.
Intrinsic properties of the camera is an important component, which are the uC, vC, fU, fV (uC, vCare the coordinates of the projection, and fU, fV are the focal lengths). Previously, I have used values 160 and 120 for uCand vCrespectively with the ratio aspect of 4:3 in mind, and 200 (this value is chosen randomly) for both fU and fV. Movement of the camera during testing is simulated by moving the object for detection instead of moving the camera itself. This is the idea of moving the entire environment rather than moving the camera. The change in translation when I shift the object is in the correct direction. Eg. When I move the object downwards, simulating the camera being elevated, the translation of the y-axis increase.
However, the intrinsic property used for testing is wrong. The Camera Calibration program that came with the OpenCV library is then used to determine the intrinsic property. Once again, the camera pose changes printed on the screen are in the correct direction. However, only by augmenting an object can I determine whether those values are truly correct.