Add manual extrinsic calibration #1
Conversation
nickcharron
left a comment
nickcharron
left a comment
There was a problem hiding this comment.
thanks for all this work! Most of it looks good at first glance, I haven't gone through it in detail but I'll stamp it anyways to unblock. I'd like to try out the calibrator myself soon though and I may have more questions or feedback then. Also, it would be cool to have a similar calibrator that works for cam-lidar using our colorizer code. I might need to do this in the near future
| publish_interval: 100 | ||
| settings: | ||
| /manual_calibration/adjusted_extrinsics/idx_start: | ||
| is_repeat: false |
There was a problem hiding this comment.
what does is_repeat do? can you add that to the docs?
There was a problem hiding this comment.
is_repeat essentially republishes the selected topic. This should always be set to false when using this tool as we only want to publish clouds when a parameter changes. I will make a note of this
| ``` | ||
|
|
||
| This will bring up a custom rviz window, where `/manual_calibration/reference_cloud` and `/manual_calibration/candidate_cloud` topics are subscribed to and visualized. The `reference_cloud` and `candidate_cloud` topics have constructions of the user specified reference sensor and candiate sensor, respectively, published over a window of size `window_size` from a starting index `start_index`. These manually adjustable parameters are available in the rqt_ez_publisher window that opens upon launch, with `x,y,z,roll,pitch,yaw` parameters available for manual extrinsic calibration. When checking off `save_data`, reference and candidate clouds are published as shown below. | ||
|
|
There was a problem hiding this comment.
save data just saves or publishes the cloud results? How do you save the calibration?
There was a problem hiding this comment.
I will change save_data to publish as this option simply publishes the clouds when any of the the parameters (i.e. start_index, window_size, x,y,z,roll,pitch,yaw) changes (see Algorithm 3 in the IEEE submission for specifics). Right now, there is no way of actually saving the calibration since this was sufficient for the paper. Ideally, there would be functionality to write calibrations to a file, though that would take some developement which I unfortunately cannot spend time on right now. The hand calculations take only a few minutes to do, though for someone not familiar with the code structure it would be a good feature.
|
Before merging, should the current main branch be tagged a v1.0.0? Since these changes depend on a revised libbeam, we should finalize a v1.0.1 of libbeam and then have a corresponding v1.0.1 tag for map_builder. Of course there is some refactoring required in the Modify poses PR and ideally new tests would be made befiore a v1.0.1 tag of libbeam is made. A new docker container for libbeam would also have to be created, which should also be done in this PR before an official tag is made. |
2 participants
@nickcharron any questions let me know
This PR does the following: