I’m building an Android MVP called LocateItNow GLOBAL that uses YOLO-based object detection to connect detected objects with a physical zone and camera view.
The current MVP uses YOLOv8n on-device and is designed around a simple idea: detection becomes more useful when the system also remembers the spatial context in which an object was seen.
Current flow:
-
Select a physical zone
-
Scan using the phone camera
-
Detect common objects with YOLO
-
Associate detections with the active zone and view (Left / Center / Right / Back)
-
Store the detection locally with time/location context
-
Search the resulting logs later by object or zone
The project is currently Android/Java and local-first. YOLOv8n is being used as the lightweight MVP detector rather than as a claim of final production-level accuracy.
I’ve attached a short recording of the current working MVP.
I would particularly value technical feedback on:
-
Improving mobile detection reliability without making inference too heavy.
-
Handling repeated/identical objects within the same physical zone.
-
Confidence-threshold and duplicate-detection strategies for practical indoor use.
This is still an MVP, so critical technical feedback is welcome.
Demo Video: https://youtube.com/shorts/FBUdYewvW98?feature=share
Thanks for explaining the MVP. I’d prioritize reliable sightings over logging every frame.
For mobile reliability, first verify camera rotation, RGB conversion, resizing/letterboxing, and box-coordinate mapping against your exported model’s preprocessing. Benchmark input resolutions on the actual phone using indoor recordings, measuring missed objects as well as latency. I’d also require several consistent observations before saving a sighting; “seen in 3 of the last 5 processed frames” is a starting experiment, not a universal setting.
For duplicates, separate overlapping boxes within one frame from repeated sightings across frames. YOLOv8’s NMS handles the former; its confidence and IoU controls are explained in the prediction documentation. It does not deduplicate your database records across time. I’d keep a session-local object ID and update last_seen rather than insert another record each frame. Don’t merge solely by class and zone—you could collapse two real chairs into one.
For temporal association, the tracking documentation describes ByteTrack as a lightweight baseline, although integrating that tracking logic into your Java pipeline is separate from exporting the detector. Treat those IDs as temporary, not permanent identities across rescans. For visually identical objects, I’d preserve separate sightings or request user confirmation when identity is ambiguous.
Tune confidence thresholds on labeled indoor clips, potentially per class, and use a stricter rule for creating a saved sighting than for maintaining an existing one.
Which Android inference runtime, input resolution, and target phone are you using?
Thanks — this is very useful and directly relevant to the issues I’m working through now.
The current Android MVP is using a YOLOv8n .tflite model with the TensorFlow Lite Interpreter runtime, and the detector input is currently 320 × 320.
The app is written in Java and uses CameraX for the live camera pipeline.
Your distinction between within-frame duplicate boxes and repeated sightings across frames is especially helpful. At the moment, I’m treating this as a location-memory problem rather than trying to establish permanent object identity, so the idea of session-local IDs plus updating last_seen fits the MVP well.
The multi-frame confirmation idea is also something I want to test, because the goal is reliable sightings rather than logging every frame.
I’m also interested in testing whether ByteTrack is worth adding at this stage, provided it does not make the Android pipeline too heavy.
Current test phone: Xiaomi Redmi Note 10 Pro (M2101K6G).
Thanks again — this gives me a much clearer direction for the next reliability pass.
Thanks for the details. ByteTrack is worth a small A/B test, but I wouldn’t make it a prerequisite for the MVP. Keep the current 320 x 320 detector fixed and compare your simple session-local association against ByteTrack on the same clips. Measure duplicate saved sightings, incorrect merges, and added processing latency on the Redmi rather than assuming the overhead will be negligible.
The Ultralytics ByteTrack implementation runs separately from detection, using Kalman filtering and box association; integrating it into your Java app is separate from the .tflite model. Its low-confidence association stage is particularly relevant: don’t discard all weaker detections before tracking, since those can help maintain existing tracks. Keep your stricter confirmation rule for saving sightings.
For CameraX, the image-analysis guidance explains STRATEGY_KEEP_ONLY_LATEST to avoid queuing stale frames, and requires releasing each ImageProxy with close() after processing. I’d also reset temporal association when the user changes zones or starts a new scan, and include slow pans, brief occlusions, and two identical objects in your test clips. Those tests should help determine whether ByteTrack earns its integration cost.
Thanks, Paula — this is very helpful.
I’m going to keep the current 320 × 320 YOLOv8n detector fixed for the next reliability pass and first implement a simple session-local sighting confirmation layer rather than making ByteTrack a prerequisite.
The immediate plan is to test:
- multi-frame confirmation before saving a sighting,
- updating an existing session sighting instead of inserting repeatedly,
- resetting temporal state when changing zones or starting a new scan,
- and verifying the CameraX analysis flow so stale frames are not being queued.
I’ll also build test clips around slow pans, brief occlusions, reappearance, and two identical objects in the same view.
Once that baseline is stable, I can run an A/B comparison against ByteTrack on the same clips and measure duplicate sightings, incorrect merges, and added latency on the Redmi Note 10 Pro.
Your point about allowing lower-confidence detections to help maintain an existing track, while keeping a stricter rule for creating a saved sighting, is especially useful.
Thanks again — this gives me a clear way to evaluate whether ByteTrack actually earns the extra complexity.
Iqbal
That sounds like a well-scoped next step, Iqbal. One detail I’d make explicit is when a missing sighting expires: allow a short grace period for brief occlusions, then stop associating new detections with it while retaining the saved history. Treat an ambiguous reappearance as a new sighting rather than forcing an identity match.
For your baseline, I’d record elapsed time as well as processed-frame counts when tuning that grace period. When you later compare ByteTrack, its track_buffer setting controls lost-track retention in frames. (docs.ultralytics.com)
Feel free to share the baseline results here, especially any clips that still produce incorrect merges.
Thanks, Paula — that’s a useful refinement.
For the baseline, I’ll explicitly model a confirmed sighting through a short lost-sighting grace period rather than expiring it immediately on the first missed detection. During that grace window, the sighting can still be maintained if a matching detection returns; after expiry, I’ll stop association and preserve only the saved history.
I’ll log both processed-frame counts and elapsed milliseconds while tuning this, so the behavior is not tied only to frame count if device throughput changes.
For ambiguous reappearance, I agree that the safer rule is to start a new sighting rather than force an identity match.
That should also give me a cleaner baseline for a later ByteTrack A/B test, especially when comparing duplicate sightings, incorrect merges, brief occlusions, and reappearance behavior against ByteTrack’s lost-track retention / track_buffer logic.
I’ll share the results once I have the first controlled clips tested.
iqbal
That sounds ready for testing, Iqbal. When you share the results, include the confirmation rule, grace-period duration, and observed processing rate alongside each clip’s expected and saved sighting counts.
I’d also distinguish new sightings created intentionally after expiry from unwanted duplicates during continuous visibility, so your conservative reappearance policy isn’t counted as a failure. A short clip with its timestamped sighting log would be useful for reviewing any remaining incorrect merges.
Thanks, Paula — that distinction is very helpful.
I’ll structure the baseline results so each test clip includes the confirmation rule, grace-period duration, observed processing rate, expected sighting count, and actual saved sighting count.
I’ll also separate intentional new sightings created after expiry from true duplicate sightings created during continuous visibility, so the conservative reappearance policy is not counted incorrectly as a failure.
For any clips that still produce incorrect merges or duplicates, I’ll include the timestamped sighting log alongside the video.
That should give us a much cleaner baseline before deciding whether ByteTrack adds enough value to justify the extra complexity.
iqbal…
Sounds good, Iqbal—this is a well-scoped baseline. I’d keep the implementation fixed for the first test pass rather than add more complexity now. Once you share the results, we can review the remaining failure cases and identify which ones are worth targeting in the ByteTrack comparison.