AI-ML based Intelligent Dead Reckoning system for seamless navigation

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   Dead reckoning error grows quadratically with time, so accuracy over a long blackout is fundamentally limited and overclaiming it is exposable

2. It gets worse

   A phone IMU without a speed reference cannot resolve velocity scale well, which is exactly why the no-OBD constraint makes this hard

3. Still reading?

   Vibration and orientation changes from a phone loose in a holder inject noise that a model trained on cleaner data will not handle

4. And the finisher

   An ISRO navigation judge knows the physical limits precisely and will ask how accuracy scales with outage duration

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  3/5

  Buildable. Not comfortably. There is a week in here you have not planned for yet.

  The IO-VNBD benchmark is public and named, and learned inertial odometry is an established research direction, but dead reckoning from a phone IMU alone without any speed reference is fundamentally hard — errors accumulate quadratically — so holding useful accuracy beyond a short blackout is a real, unsolved-in-general challenge.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  Learning to suppress phone-specific vibration and bias to extend usable dead-reckoning time from a phone IMU alone is genuinely open, and the outage-detection and re-blending logic is your own design.

• Clarity

  4/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  The description defines the problem, the sensors, the no-OBD constraint and the target environments precisely, and names the benchmark dataset, so the target is clear even though no accuracy threshold is stated.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  A strong pick — the named public benchmark means you can train and validate rigorously, the problem is genuinely useful and relatable, learned inertial odometry gives you a real approach, and the phone-only constraint is a distinctive and honest framing, though you must be candid that accuracy degrades with blackout length.

• Effort

  Heavy

  Heavy. Somebody on this team is not sleeping in week three. Pick who, on purpose.

  The learned inertial model, the outage detection and re-acquisition blending, and validation on the benchmark are focused, well-bounded work on data that already exists.

• Demo-ability

  Medium

  Demoable, if you rehearse it. Nobody rehearses it.

  Your track holding while naive integration diverges is a clear, satisfying result, but it plays out on a plotted trajectory that needs the GPS-outage context to be appreciated.

The demo they will have already seen 🪞

Somewhere around 150–340 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• IO-VNBD is a named public benchmark built for exactly this ground-vehicle positioning problem, so you can train and validate on real data
• Learned inertial odometry approaches like RoNIN give you an established, effective starting point rather than a from-scratch model
• The phone-only, no-OBD constraint is a distinctive framing that matches the reality of most Indian vehicles