Enforce g2o formatting #5
Conversation
cleanup namespace and whitespace
odometry is ground truth with negligible weight
| const size_t first_pose_id = *pose_ids.begin(); | ||
|
|
||
| // Check for consecutive sequencing of pose IDs | ||
| size_t prev_pose_id = first_pose_id - 1; |
There was a problem hiding this comment.
@adthoms This will cause overflow because prev_pose_id is unsigned and first_pose_id is nominally zero.
| @@ -22403,6 +22403,7 @@ EDGE_SE2 7285 7286 0.628132 0.0065 0.009066 102.196 3.89037 9.59586 105.601 8.07 | |||
| EDGE_SE2 7286 7287 0.52826 0.000141 -0.002814 100.995 1.65564 3.57699 105.323 1.86886 248.159 | |||
| EDGE_SE2 7287 7288 0.481197 0.000464 0.019296 101.345 2.64031 0.816055 106.074 2.28584 273.897 | |||
| EDGE_SE2 7288 7289 0.620686 0.02638 0.08998 103.967 5.06454 -25.856 108.448 -16.176 302.116 | |||
| EDGE_SE2 7289 7290 69.372726 240.060823 -0.504155 1e-06 1e-06 1e-06 1e-04 1e-04 1e-04 | |||
There was a problem hiding this comment.
I'm not sure about adding this edge because it will change the optimal cost and solution (although probably in a negligible way), and so might confuse others who just want to access the original dataset to test other solvers.
For now, I think leaving the dataset unchanged but printing the errors in dpgo as you have implemented is a better way to go.
There was a problem hiding this comment.
Also, it's possible that the consecutive ID assumption is only needed by odometry initialization and chordal initialization. So one could potentially just improve these initialization implementations without changing the dataset, but I will need to confirm this is the case.
Issue Addressed: #3
Description: @yuluntian In DPGO's implementation, there is an inherent assumption that only monotonically increasing sets of consecutive pose IDs, starting at index 0, are valid (i.e., {0,1,2,...,N-1} where N is the number of poses). This is particularly evident in the way the
PoseGraphclass updates its number of poses, as this class only considers the maximum pose ID in its updates (e.x., ID sets such as {0,1,5,10,20} and {1000,1001,1002,...,N-1001} would be invalid). Given this, I have enforced the formatting of g2o files inread_g2o_file()while also providing log error messages when odometry is discontinuous (there are no checks in read_g2o_file for continuous odometry given DPGO's current design of separating odometry measurements outside of this function). On updating the datasets to suit DPGO's g2o formatting requirements, I have (manually) updated theais2klinik.g2odataset as it only contained one missing odometry measurement (likely, this discontinuity reveals two distinct odometry chains, and thus I have set the weight of this edge to be negligible). For datasetscubicle.g2oandrim.g2o, correcting these datasets will require automating this process, which I may get around to at a later time.