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 PoseGraph class 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 in read_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 the ais2klinik.g2o dataset 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 datasets cubicle.g2o and rim.g2o, correcting these datasets will require automating this process, which I may get around to at a later time.
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.