Remove objectdb from go2 blueprints

[leshy]

Devs have been running agentic go2, which crashes after a while due to objectdb being in a blueprint - it stores all detections permanently in mem, this is not a production ready module but an experiment, it's not viable as a direction for memory imo

[greptile-apps]

Greptile Overview

Greptile Summary

This PR replaces ObjectDBModule with Detection3DModule in the GO2 detection blueprint to resolve memory accumulation issues that were causing crashes during agentic operation.

Key Changes

Module Replacement:

• Replaced detectionDB_module (ObjectDBModule) with detection3d_module (Detection3DModule)
• Updated all module class references from ObjectDBModule to Detection3DModule
• Added import for SceneUpdate message type (previously not imported)

Behavioral Impact:

• Before: ObjectDBModule accumulated all detections in memory indefinitely via the objects dict, merging nearby detections into persistent Object3D instances. This experimental approach caused memory growth and eventual crashes.
• After: Detection3DModule processes detections frame-by-frame without persistent storage, preventing memory accumulation.

Transport Configuration:

• Enabled scene_update transport that was previously commented out
• All output ports properly configured: detections, annotations, scene_update, detected_pointcloud_0/1/2, detected_image_0/1/2

Lost Functionality:
The ObjectDBModule provided object tracking features that are removed in this change:

• Persistent object tracking across frames (objects dict with track_id)
• Object merging and detection count aggregation
• Agent-accessible object database (agent_encode() method)
• Object lookup and goto capabilities

These features were experimental and not production-ready, as noted in the PR description.

Integration Points

The unitree-go2-detection blueprint in all_blueprints.py continues to reference this detection configuration. The detection blueprint is standalone and not used by the agentic blueprints (agentic, agentic_mcp, agentic_ollama, agentic_huggingface), so there are no downstream impacts on agent functionality.

Confidence Score: 4/5

• This PR is safe to merge with low risk - it fixes a critical production issue (memory crashes) with a clean module swap.
• Score of 4/5 reflects a well-executed fix for a critical issue with minimal risk. The change is straightforward (swapping one detection module for another), all output ports are properly configured, and the scene_update transport that was previously disabled is now enabled. The only concern is that the G1 blueprints may need the same fix applied, but that's outside the scope of this PR.
• No files require special attention - the single file change is clean and complete. However, consider reviewing unitree_g1_blueprints.py in a future PR as it still uses ObjectDBModule.

Important Files Changed

File Analysis

Filename	Score	Overview
dimos/robot/unitree_webrtc/unitree_go2_blueprints.py	4/5	Replaced ObjectDBModule with Detection3DModule to prevent memory accumulation crashes. Enabled scene_update transport that was previously commented out. All output ports properly configured.

Sequence Diagram

sequenceDiagram
    participant Robot as GO2 Robot
    participant Nav as Navigation Module
    participant Det as Detection3DModule (NEW)
    participant Trans as LCM Transports
    participant Fox as Foxglove/Visualization
    
    Note over Det: Replaces ObjectDBModule which<br/>accumulated detections in memory
    
    Robot->>Nav: color_image, pointcloud
    Nav->>Det: global_map (remapped)
    Det->>Det: Process frame detections
    Note over Det: Detections processed per-frame<br/>No memory accumulation
    Det->>Trans: detections (Detection2DArray)
    Det->>Trans: annotations (ImageAnnotations)
    Det->>Trans: scene_update (SceneUpdate)
    Note right of Trans: scene_update now ENABLED<br/>(was commented out)
    Det->>Trans: detected_pointcloud_0/1/2
    Det->>Trans: detected_image_0/1/2
    Trans->>Fox: Publish all detection outputs
    
    Note over Det,Fox: Key difference: No persistent<br/>object tracking or memory growth

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

The G1 blueprints (unitree_g1_blueprints.py) still use ObjectDBModule and may experience the same memory accumulation crashes mentioned in the PR description. Consider applying the same fix to the G1 detection blueprint for consistency.

The G1 detection blueprint (lines 185-261 in unitree_g1_blueprints.py) uses both detection3d_module AND detectionDB_module together, which means it will still accumulate detections in memory indefinitely.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}