Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about left update after LM optimization #54

Open
Joweay opened this issue May 9, 2024 · 4 comments
Open

Questions about left update after LM optimization #54

Joweay opened this issue May 9, 2024 · 4 comments

Comments

@Joweay
Copy link

Joweay commented May 9, 2024

Dear author, thanks for your excellent work.I read the paper and the code recently, but some questions in my mind.
firstly, it is why the position left_update left multiply dR, specifics in damping_inter function? as I think the dR is not necessary.
the second,why do the transformation which transfer x_states to the pose relative to es0.
image
image

@Zale-Liu
Copy link
Member

(1) You can see the left update in the paper. [dR & dp // 0 & 1 ] * [R & p // 0 & 1] = [dRR & dRp + dp // 0 & 1]. It is the update in SE3. (2) We just want to keep the first pose unchanged. Of course, you can use other manners to fix the first pose (e.g., set the parts corresponding to the first pose of the Hessisan matrix into identity.)

@Zale-Liu
Copy link
Member

Of course, we recommend you use the right update. It is similar to yours.
rightupdate

@Joweay
Copy link
Author

Joweay commented May 27, 2024

(1) You can see the left update in the paper. [dR & dp // 0 & 1 ] * [R & p // 0 & 1] = [dR_R & dR_p + dp // 0 & 1]. It is the update in SE3. (2) We just want to keep the first pose unchanged. Of course, you can use other manners to fix the first pose (e.g., set the parts corresponding to the first pose of the Hessisan matrix into identity.)

thanks for your patient reply.
1.after learning about your explanation, I understand the reason that left dR with p when do the updating.
2. why fix the first pose unchanged? the reason is the experience from the experiments or some theory consideration.
3. I also read the BALM_old code and papers. in the balm_old code, state updating adopt left update, but the position don't left multiply the dR, there maybe is a small bug, details is as following
/***********************************************/
cv::solve(matA, matB, matX, cv::DECOMP_QR);
for (int j = 0; j < jac_leng; j++) {
dxi(j, 0) = matX.at(j, 0);
}

    for (int j = 0; j < slwd_size; j++) {
        // left multiplication
        so3_poses_temp[j] = SO3::exp(dxi.block<3, 1>(6 * (j), 0)) * so3_poses[j];
        t_poses_temp[j] = t_poses[j] + dxi.block<3, 1>(6 * (j) + 3, 0);
    }

/***********************************************/

@Joweay
Copy link
Author

Joweay commented May 31, 2024

(1) You can see the left update in the paper. [dR & dp // 0 & 1 ] * [R & p // 0 & 1] = [dR_R & dR_p + dp // 0 & 1]. It is the update in SE3. (2) We just want to keep the first pose unchanged. Of course, you can use other manners to fix the first pose (e.g., set the parts corresponding to the first pose of the Hessisan matrix into identity.)

thanks for your patient reply. 1.after learning about your explanation, I understand the reason that left dR with p when do the updating. 2. why fix the first pose unchanged? the reason is the experience from the experiments or some theory consideration. 3. I also read the BALM_old code and papers. in the balm_old code, state updating adopt left update, but the position don't left multiply the dR, there maybe is a small bug, details is as following /***********************************************/ cv::solve(matA, matB, matX, cv::DECOMP_QR); for (int j = 0; j < jac_leng; j++) { dxi(j, 0) = matX.at(j, 0); }

    for (int j = 0; j < slwd_size; j++) {
        // left multiplication
        so3_poses_temp[j] = SO3::exp(dxi.block<3, 1>(6 * (j), 0)) * so3_poses[j];
        t_poses_temp[j] = t_poses[j] + dxi.block<3, 1>(6 * (j) + 3, 0);
    }

/***********************************************/

sorry! the question 3 is my fault that i did not notice that the derivation is based on SO3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants