Summary
start_binary_classifier_callback in riptide_mapping/riptide_mapping2/mapping.py currently accepts any two existing mapping objects as object1_name/object2_name without checking that they share the same parent frame. The seeding logic (seed_object_estimate, maybe_seed_binary_instances) computes/uses a centroid derived from TF lookups performed relative to the first instance's parent frame (see try_update_binary_classifier_pose, which transforms detections using instance1_name's parent). If object1_name and object2_name are configured with different init_data.<object>.parent values, the second target's pose/centroid will be seeded in the wrong reference frame, producing an incorrect TF/pose for instance 2.
Rationale
The current implementation implicitly assumes both classifier targets live in the same parent frame. This assumption is not validated at the API boundary, so a caller could pass a valid pair of mapping objects that violates it, leading to silently incorrect seeding.
Affected areas
riptide_mapping/riptide_mapping2/mapping.py
start_binary_classifier_callbacktry_update_binary_classifier_poseseed_object_estimatemaybe_seed_binary_instances
Suggested fix
- In
start_binary_classifier_callback, look up init_data.<object1_name>.parent and init_data.<object2_name>.parent and reject the request (return success = False with a descriptive message) if they differ.
- Alternatively, if mixed-parent pairs must be supported, transform the computed centroid into the second object's parent frame before calling
seed_object_estimate for it.
Acceptance criteria
start_binary_classifier_callback rejects object1_name/object2_name pairs whose configured parent frames differ (unless mixed-parent support is explicitly implemented with correct frame transforms).- Existing valid same-parent classifier flows continue to work unchanged.
References
Requested by: @zehdari
Summary
start_binary_classifier_callbackinriptide_mapping/riptide_mapping2/mapping.pycurrently accepts any two existing mapping objects asobject1_name/object2_namewithout checking that they share the same parent frame. The seeding logic (seed_object_estimate,maybe_seed_binary_instances) computes/uses a centroid derived from TF lookups performed relative to the first instance's parent frame (seetry_update_binary_classifier_pose, which transforms detections usinginstance1_name's parent). Ifobject1_nameandobject2_nameare configured with differentinit_data.<object>.parentvalues, the second target's pose/centroid will be seeded in the wrong reference frame, producing an incorrect TF/pose for instance 2.Rationale
The current implementation implicitly assumes both classifier targets live in the same parent frame. This assumption is not validated at the API boundary, so a caller could pass a valid pair of mapping objects that violates it, leading to silently incorrect seeding.
Affected areas
riptide_mapping/riptide_mapping2/mapping.pystart_binary_classifier_callbacktry_update_binary_classifier_poseseed_object_estimatemaybe_seed_binary_instancesSuggested fix
start_binary_classifier_callback, look upinit_data.<object1_name>.parentandinit_data.<object2_name>.parentand reject the request (returnsuccess = Falsewith a descriptive message) if they differ.seed_object_estimatefor it.Acceptance criteria
start_binary_classifier_callbackrejectsobject1_name/object2_namepairs whose configured parent frames differ (unless mixed-parent support is explicitly implemented with correct frame transforms).References
Requested by: @zehdari