Robotics Olympiads & Competitions in Bangladesh: Complete Guide

Bangladesh's robotics scene is growing quickly, with school science festivals, national project showcases and olympiad-style events feeding into international opportunities. For a student, a competition is the fastest way to turn scattered learning into a finished, defendable system.

This guide covers how events typically work, what judges reward, and a preparation plan you can run with a small team — regardless of the specific event you enter.

Why competitions are worth the stress

• A deadline — the single strongest cure for endless tutorials.
• Feedback — judges and other teams expose weaknesses you cannot see alone.
• Portfolio evidence — a placement, award or even a finished entry is concrete proof of skill.
• Network — teammates, mentors and organisers become future collaborators and references.
• Pressure testing — a robot that survives a crowded demo hall is genuinely reliable.

Team Nokkhotropoth's own members have won national recognition at the Bangladesh Olympiad on Astronomy and Astrophysics and science festivals, and presented work at national showcases. The pattern is consistent: preparation and documentation separate the top teams.

Types of robotics events

Pick an event that matches your current level. A first-time team should not start with a 20-kilogram combat robot; it should start with a line follower or a focused project showcase.

How judging usually works

Rubrics vary, but most competitions score some combination of these:

• Problem and impact (20–30%) — is the problem real, specific and worth solving?
• Technical design (20–30%) — does the system make sense? Are the components appropriate?
• Performance (20–30%) — does the robot complete the task consistently, not once?
• Documentation (10–20%) — diagrams, BOM, code, test data and build notes.
• Presentation (10–20%) — can you explain the work clearly and answer questions honestly?

Read the rubric before you build. If documentation is 20% and you leave it for the night before, you have already given away a fifth of your score.

Build the team

A strong student robotics team has four roles, and one person can hold two roles in a small team:

1. Lead / systems — keeps scope realistic, owns the timeline and integration.
2. Hardware — wiring, power, motors, chassis and safety.
3. Software — control loops, perception, communication and testing tools.
4. Documentation / presentation — photos, diagrams, report, video and pitch.

Choose a captain who is organised rather than the best coder. The most common team failure is not technical — it is three people building different robots because nobody agreed on the design.

A 90-day preparation plan

Reserve the last week for rehearsal, not building. Teams that make major changes on the final night usually arrive with a robot that has never been tested in its final configuration.

Documentation that wins points

• One-page system overview — problem, solution, block diagram, result.
• Wiring diagram — every connection, voltage and ground, not a photo of a breadboard.
• Bill of materials — part, quantity, unit cost, supplier, purpose.
• Test table — trial number, conditions, result, notes. Ten trials is more convincing than one perfect run.
• Code repository — README, pin map, dependencies and a licence.
• Build log — dated photos and short notes. This is easy to keep and impossible to recreate later.
• Safety notes — battery handling, fuses, emergency stop and known hazards.

Demo day checklist

• Charge every battery the night before and bring a second set.
• Bring spare sensors, jumper wires, a multimeter, tape, zip ties and tools.
• Arrive early and test on the actual surface and lighting.
• Have a 60-second explanation and a 5-minute technical explanation ready.
• Prepare for the demo to fail: know your fallback and say it calmly.
• Film your own continuous run for your portfolio.

Common mistakes

• Building for the video, not the run. Judges ask for repeated attempts.
• Ignoring the rubric. Optimising the wrong 20%.
• Overscoping. Three features that work beat eight that almost work.
• No spare parts. A BDT 100 sensor can end a year of work.
• Last-minute code changes. Freeze the design 48 hours before the event.
• Not documenting failures. The failure analysis is often the most valuable slide.

Want to prepare with other builders? Join the free robotics community, share your build log, and ask for a mock judging session. If you are starting from zero, follow the beginner roadmap first.

Frequently asked questions