Mustafa Sepen Robotics Software Engineer

Project 02

Njord Autonomous USV

ROS 2 autonomy for an unmanned surface vessel — Njord Challenge 2025

Role
Software team — mission logic, mapping, docking
Year
2025
Platform
Unmanned surface vessel
Event
Njord Challenge 2025 · NTNU
Result
4th of 11 international teams
Team
Team Navi, Türkiye
Team Navi’s unmanned surface vessel afloat in Trondheim harbour: twin blue catamaran hulls, a white instrument deck carrying the stereo camera housing and electronics enclosure, and two GNSS antenna masts.
The vessel at Nyhavna, Trondheim — twin hulls, instrument deck, stereo camera and dual GNSS masts.

The problem

Nyhavna, Trondheim · August 2025

The Njord Challenge asks a small unmanned surface vessel to complete a marked course, avoid obstacles, and dock itself — outdoors, on water, against real buoys, with no operator in the loop.

Team Navi built the software for that vessel: a ROS 2 stack running perception, mapping, mission planning, navigation and docking. It placed 4th among 11 international teams at NTNU in August 2025.

Official competition results (opens in a new tab)

The system

Perception → mapping → mission → navigation

YOLO detections and ZED stereo depth become labelled obstacle and gate positions in a map frame. Task state machines turn those into waypoints and Nav2 goals. Nav2 plans and tracks, and a relay forwards the resulting velocity commands to MAVROS and the vehicle autopilot.

The primary route consumes YOLO detections alongside registered ZED depth and camera intrinsics. The median of the ten closest positive centre-row depths produces a labelled map-frame point using the synchronised MAVROS odometry pose. Red and green detections populate an occupancy grid and define gate midpoint waypoints. Classical OpenCV depth-edge processing estimates dock geometry and the empty berth side for the docking task.

A separate, earlier route implements custom A* planning with B-spline smoothing and a lookahead heading tracker. It is not established as the final competition navigation path, and it is documented as an alternative rather than the primary one.

Architecture

Two navigation routes, kept apart

Njord USV autonomy architecture. ZED RGB feeds YOLO detections which, with ZED depth and intrinsics, are projected into the map frame. Classical depth-edge dock detection feeds a PortInfo transform. Gate, cardinal and docking mission logic combines these with GPS waypoints and MAVROS odometry to issue Nav2 goals planned with NavFn A-star and DWB, relayed as velocity commands to MAVROS, alongside an earlier custom A-star and lookahead controller route.
The diagram separates the Nav2 mission route from the earlier custom controller. Diagram from the project repository.

Engineering work

My contributions, as evidenced in the repository

This was team software. Five people built and integrated the stack across perception, mapping, mission logic, navigation, docking and simulation. The repository documents individual contributions against source diffs rather than inferring them, and these are the ones attributed to me:

  • Integrated a ROS A* planner with spline smoothing and a lookahead heading tracker — an integration of established algorithms, not an invention of them.
  • Added spatial filtering for repeated mapped obstacles: distance-based rejection of duplicate detections in the occupancy-grid node.
  • Extended the gate mission and waypoint integration — gate and GPS queue transitions, and the subsequent task-map refactoring.
  • Developed cardinal-mark mission handling, including corrections to the north/south direction mapping.
  • Developed the docking mission logic and dock-geometry interfaces — the PortInfo message, port TF callbacks, and the task approach and exit state logic, built on the team's existing depth detection.
  • Extended GPS-to-local-frame integration with MAVROS odometry subscription, readiness handling and local offsets.
  • Added the Njord simulation geometry — real-scale buoy definitions and docking world revisions in the VRX overlay.

Key engineering challenge

Turning detections into a map

A bounding box is not an obstacle. It is a rectangle in an image, and the mission logic needs a position on the water.

Bridging that gap is where most of the difficulty sits. A detection has to be paired with the registered depth image, reduced to a single robust range — the median of the ten closest positive centre-row depths, rather than a single pixel that might land on the sky behind the buoy — and then projected through the camera intrinsics into a map-frame point using the vessel's synchronised odometry pose at that instant.

Two things then have to hold. The pose used for projection must be the pose at the time of the frame, not the latest one, or every obstacle is placed with a lag proportional to boat speed. And the same buoy seen across many frames must resolve to one map entry, not a smear of near-duplicates — which is what the distance-based spatial filter is for.

Docking works from the other direction. Rather than a learned detector, classical depth-edge processing estimates the dock's structure and publishes three geometric points plus an estimate of which berth is empty; the mission code builds a target pose from those and advances through its navigation states.

Result and scope

What the placing does and does not establish

Team Navi placed 4th among 11 international teams at the Njord Challenge 2025 in Trondheim.

Stated limitations

  • This is a development implementation, not a production-ready stack.
  • The public copy has passed static checks but has not been built or run — in ROS, in simulation, or on a vehicle — during its preparation for release.
  • Known issues include unchecked Nav2 action statuses, coordinate and TF assumptions, disabled grid bounds checks, and command arbitration gaps on dock exit.
  • The competition result does not establish that docking, obstacle avoidance or any particular control mode ran successfully during the event.
  • The frameworks the project builds on — ROS 2, Nav2, MAVROS, the Stereolabs ZED wrapper, YOLO and VRX — are external dependencies, not team work.

Field testing

Real vehicle, on the water

The clip shows the real vehicle moving on the water. It does not by itself establish which control mode was running, and it is not evidence that docking or obstacle avoidance executed successfully — those remain unverified, as the repository states.

Recorded at the competition site. The published copy is a silent, looping excerpt of the original footage with no content edits.

Software team

Credited as provided by the project

Mustafa Sepen · Metehan Karaaslan · Semih Vicir · Ahad Aydın · Selim Hacıömeroğlu

All five worked on the software. Individual responsibilities are not inferred from commit history beyond the contribution evidence recorded in the repository.

Tech stack

Autonomy

  • ROS 2
  • Nav2
  • NavFn A*
  • DWB controller
  • Theta*
  • Regulated Pure Pursuit

Perception

  • ZED stereo camera
  • YOLO (yolo_ros)
  • OpenCV depth-edge processing
  • Occupancy grid mapping

Vehicle

  • MAVROS
  • Autopilot velocity control
  • GPS waypoints
  • Mission state machines

Simulation

  • VRX / Gazebo
  • Njord task worlds
  • Buoy and dock geometry
  • Python