mapping: seed_object_estimate receives centroid in wrong frame when instance2 parent != classifier parent

[coderabbitai]

Summary

When start_binary_classifier_second locks instance 2 from a preserved buffer (binary_classifier.second_locked == True), the code calls seed_object_estimate(instance2_name, instance2_centroid). However, instance2_centroid is expressed in the classifier's parent frame (the parent of instance1_name, resolved inside try_update_binary_classifier_pose), while seed_object_estimate() unconditionally treats the centroid as map-space coordinates.

When it manifests

The bug is a no-op in the current nominal case where both bin_target1 and bin_target2 share bin_frame as their parent (since publish_pose uses the non-map branch for those objects). It becomes actively wrong if instance2_name has map as its parent but instance1_name uses a different frame (e.g. bin_frame): the TF for the second target would be published relative to offset using bin-frame coordinates, placing it in the wrong map location until a fresh live detection corrects it.

Affected code

riptide_mapping/riptide_mapping2/mapping.py – the block inside start_binary_classifier_second_callback that checks self.binary_classifier.second_locked (around lines 318–323 of PR #23).

Suggested fix (from PR review)

Before calling seed_object_estimate, verify that instance2_name's configured parent matches the classifier parent frame. If they diverge, either skip the pre-seed (letting the first live detection provide the correct pose) or perform a TF lookup to transform the centroid into the map frame first.

References

• PR: Binary classifier #23
• Review comment: Binary classifier #23 (comment)

/cc @zehdari