Skip to content
SIH Buddyby Ganeev Singh
Dev

πŸ”₯ Roast My Pick Β· SIH26123

Edge-AI Based Distributed Fleet Coordination for Autonomous Mobile Robots (AMRs) in Smart Warehouses

Bharat Electronics Limited

Mild17/100

Good pick. Genuinely. Now sit down, because the judges are going to try anyway β€” and this is what they will try.

Strong pick. The best-defined problem in this block by some distance β€” the numeric success criteria and explicit acceptance of simulation make it unusually winnable, so implement the baseline honestly and let the measured comparison carry the demo. Roughly 80–180 teams are expected to go here.

The receipts

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

  1. Exhibit A

    The description says the system must run on edge hardware while the deliverable is a simulation, so resolve that tension explicitly β€” run the real stack on real Pis against a simulated world rather than simulating the compute too

  2. It gets worse

    Truly decentralised conflict resolution is much harder than centralised planning, and a team that quietly runs a central planner and calls it distributed will be caught by any robotics judge

  3. Still reading?

    Deadlock at a choke point is the specific hard case named in the description, so a demo that only shows robots avoiding each other in open space has dodged the actual problem

  4. And the finisher

    The twenty percent improvement must be measured against a fairly implemented baseline β€” a deliberately weak stop-and-wait implementation makes the number meaningless

The damage report

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

  • Feasibility

    4/5

    Actually buildable, which on this slate is rarer than it sounds. Do not squander it on scope.

    The Expected Solution explicitly asks for a multi-robot simulation rather than physical robots, which removes the hardware barrier entirely, and decentralised multi-agent path finding has well-documented algorithms you can implement and benchmark.

  • Innovation scope

    4/5

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

    The decentralised constraint is set but the negotiation protocol, the deadlock resolution strategy and the task reallocation policy are all yours, and there are several genuinely different valid architectures.

  • Clarity

    5/5

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

    The description numbers three required capabilities, names the deliverable components, and states quantitative success criteria β€” zero inter-robot collisions and at least a twenty percent reduction in task completion time against stop-and-wait β€” which is the clearest acceptance bar in this entire block.

  • Acceptance potential

    5/5

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

    The standout of this block β€” the success criteria are given as hard numbers so your result is unarguable, simulation is explicitly accepted so there is no hardware risk, and multi-agent path finding intimidates enough teams that the field will be far thinner than a defence PSU problem deserves.

  • Effort

    Heavy

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

    The simulation environment, the peer-to-peer messaging layer, the distributed planner and the dashboard are four pieces, though the simulation removes all hardware integration work.

  • Demo-ability

    Easy

    Easy to demo β€” and so is everyone else's. Working is the floor here, not the achievement.

    Robots visibly negotiating a choke point without colliding, with a live counter proving the time saved against the baseline, is self-explanatory and quantitative at the same time.

  • Data

    None supplied

    No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

    Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen

Somewhere around 80–180 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.

  • The stated success criteria are numeric, so you know exactly what winning looks like and can report it as a measured result rather than a claim
  • Simulation is named in the Expected Solution, which removes the robot-purchasing barrier that makes most robotics statements unapproachable
  • The stop-and-wait baseline is specified for you, so your comparison is pre-defined and cannot be accused of being cherry-picked

Nothing here is fatal. It is just the list of places this statement pushes back, and you now get to push there first.

The framing is a joke. The findings are not β€” they are the same analysis on the statement page, and every line above is attached to a score or a fact in the record. It is one opinion with its reasoning attached, so argue with it before you trust it.