Rover Perception & Tracking

An autonomous rover needed to detect and track objects reliably enough for the ROS 2 navigation stack to act on, using a camera and a 3D depth sensor that did not agree with each other about where anything was.

What was the rover being built for — a competition, a field task? State what the perception stack had to deliver for the mission to succeed.

• Coordinate frame drift — camera and depth sensor reported different positions for the same object, so detections could not be trusted downstream.
• ROS 2 Humble contract — output had to fit the existing nav stack's topics and message types rather than define its own.
• Hand-labelled data — the training set was annotated in Label Studio and trained in Colab, so dataset size was bounded by available labelling time.

Add the hardware — which camera, which depth sensor, what compute is on the rover — and the real-time rate the nav stack expected.

ArUco markers provide a shared reference both sensors can see, letting the camera and depth streams be resolved into one coordinate frame before detections are published to the nav stack.

Draw the ROS 2 node graph — nodes, topics and message types. This is the diagram an interviewer will ask you to walk through.

Why ArUco markers for the sync rather than extrinsic calibration or an ICP-style alignment? Why YOLO over a classical detector, given the compute budget? Name what you rejected.

Multi-sensor sync via ArUco markers and 3D depth eliminated the coordinate frame drift, and the detector was integrated with the ROS 2 Humble navigation stack.

This is the one section holding the project back — it currently has no numbers. Detection mAP, tracking rate in Hz, drift before and after in centimetres: any one measured figure here would put this project on the same footing as the lane follower.

What breaks first — lighting, distance, motion blur, marker occlusion? Naming a known limitation reads as engineering judgement, not weakness.