**ShahroodRC** โ *Future Engineers 2026*
๐ **1st Place โ Iran National WRO 2025**
๐ **Heading to Tehran National Final (31 Jul 2026)**
A fully autonomous LEGO EV3 robot with vision-based obstacle avoidance and precision navigation.
**๐ฑ Connect with us:**
[](https://www.instagram.com/shahrood_rc?igsh=MWpmMjQ0MG90NzdjOQ==)
[](https://youtube.com/@shahroodrc)
[](https://github.com/ShahroodRC)
---
## ๐ฏ Key Features
| Feature | Details |
|---------|---------|
| ๐ค **Platform** | LEGO EV3 Mindstorms with Python (ev3dev) |
| ๐๏ธ **Vision System** | Pixy 2.1 camera (60 fps, real-time obstacle detection) |
| ๐งญ **Navigation** | Dual ultrasonic sensors + gyro sensor for precision wall-following |
| โก **Performance** | 90% success rate in 50+ test runs; completes challenges in <2min |
| ๐ง **Custom Parts** | 3D-printed Pixy 2.1 mount for optimal positioning |
| ๐ฆ **Components** | All standard LEGO pieces (100% WRO-compliant) |
---
## The Meaning Behind ShahroodRC
ShahroodRC blends "Shahrood" (our hometown in Iran, symbolizing resilience like its mountains) with "RC" (Robotics Club). Inspired by the story of iteration, teamwork, and turning "what if" into "we did it." Behind the code and gears? The quiet support of families โ our real "power source," fueling late nights and breakthroughs. ShahroodRC isn't just a robot; it's proof that passion and persistence lead to a global stage.
---
## Table of Contents
- [๐ฅ The Team](#-the-team)
- [๐ National Championship Victory](#-national-championship-victory)
- [๐ฏ Mission Overview for WRO Future Engineers Rounds](#-mission-overview-for-wro-future-engineers-rounds)
- [๐ธ Pictures](#-pictures)
- [๐ฌ Videos](#-videos)
- [๐ฑ Randomizer App](#-randomizer-app)
- [๐ Our Path โ Platform Evolution](#-our-path--platform-evolution)
- [๐ Design Evolution & Iteration History](#-design-evolution--iteration-history)
- [๐ Performance Metrics & Statistics](#-performance-metrics--statistics)
- [๐ค Robot Components Overview](#-robot-components-overview)
- [๐ป Code For Each Component](#-code-for-each-component)
- [๐ Drive Motor Code](#-drive-motor-code)
- [๐ฏ Steering Motor Code](#-steering-motor-code)
- [๐ท Pixy Camera Code](#-pixy-camera-code)
- [๐ Color Sensor Code](#-color-sensor-code)
- [๐ก LED Indicator Code](#-led-indicator-code)
- [๐ Ultrasonic Sensor Code](#-ultrasonic-sensor-code)
- [๐ Button Control Code](#-button-control-code)
- [โก Main Control Flow](#-main-control-flow)
- [๐ Mobility Management](#-mobility-management)
- [1. ๐ Introduction to Mobility System](#1--introduction-to-mobility-system)
- [2. โ๏ธ Motors and Actuators](#2-๏ธ-motors-and-actuators)
- [3. ๐ก Sensor Integration for Mobility](#3--sensor-integration-for-mobility)
- [4. ๐ฎ Mobility Control Algorithms](#4--mobility-control-algorithms)
- [5. โก Energy Management for Mobility](#5--energy-management-for-mobility)
- [6. ๐ System Integration for Mobility](#6--system-integration-for-mobility)
- [7. ๐งช Testing and Optimization](#7--testing-and-optimization)
- [8. โ
Conclusion](#8--conclusion)
- [โก Power and Sense Management](#-power-and-sense-management)
- [1. ๐ Power Supply and Distribution](#1--power-supply-and-distribution)
- [2. ๐ Power Consumption Overview](#2--power-consumption-overview)
- [3. ๐ก Sensor Architecture and Management](#3--sensor-architecture-and-management)
- [4. ๐ Wiring and Safety](#4--wiring-and-safety)
- [5. ๐ Diagnostics and Monitoring](#5--diagnostics-and-monitoring)
- [6. โ๏ธ Optimization Techniques](#6-๏ธ-optimization-techniques)
- [7. โ
Conclusion](#7--conclusion)
- [๐ง Obstacle Management](#-obstacle-management)
- [๐ Qualification Round (Open Challenge)](#-qualification-round-open-challenge)
- [๐ Final Round with Obstacle Avoidance (Obstacle Challenge)](#-final-round-with-obstacle-avoidance-obstacle-challenge)
- [๐๏ธ Robot Assembly Guide](#๏ธ-robot-assembly-guide)
- [๐ง Software Architecture & Obstacle Strategy](#-software-architecture--obstacle-strategy)
- [๐ง Systems Thinking & Engineering Decisions](#-systems-thinking--engineering-decisions)
- [๐ ๏ธ Software Setup & Installation](#๏ธ-software-setup--installation)
- [๐ง Sensor Calibration Guide](#-sensor-calibration-guide)
- [๐ด Problems and Solutions](#-problems-and-solutions)
- [๐ฐ Cost Report](#-cost-report)
- [๐ Repository Structure](#-repository-structure)
- [๐ค Contributing & Support](#-contributing--support)
- [๐ License](#-license)
---
## ๐ฅ The Team
We are the ShahroodRC team, a group of dedicated students from Iran with a passion for robotics, electronics, and programming. Our goal is to design an innovative robot for the WRO 2026 Future Engineers category, leveraging technical skills and collaboration to tackle complex challenges.
### ๐จโ๐ผ Sepehr Yavarzadeh
- **Role**: Project Manager and Software Engineer
- **Age**: 17
- **Description**: Third-time WRO participant, 3rd place in 2025 Robo Mission. Passionate about programming, physics, and math. Enjoys piano and tennis.
- **Contact**: sepehryavarzadeh@gmail.com
- **Links**: [GitHub](https://github.com/Sepehryy) | [Instagram](https://www.instagram.com/sepehr.yavarzadeh/) | [LinkedIn](https://www.linkedin.com/in/sepehr-yavarzadeh-9643252a3/)
### ๐จ๐ผโ๐ง Nikan Bashiri
- **Role**: Mechanical and Electronics Specialist
- **Age**: 18
- **Description**: Advanced LEGO robotics instructor with 5 WRO national finals experience. Expertise in mechanical/electronic systems and LEGO design.
- **Contact**: nikanbsr@gmail.com
- **Links**: [Instagram](https://www.instagram.com/nikanbsr/)
### ๐งโ๐ป Amirparsa Saemi
- **Role**: Lead Developer and Algorithm Designer
- **Age**: 20
- **Description**: Third-year WRO competitor, professional ping-pong player. Studying computer science, passionate about math, physics, and programming.
- **Contact**: amirparsa.saemi2021@gmail.com
- **Links**: [Instagram](https://www.instagram.com/amirparsa_saemi/)
### ๐จ๐ปโ๐ซ Ali Raeesian
- **Role**: Coach
- **Age**: 25
- **Description**: B.Sc. in Computer Engineering, pursuing M.Sc. in Computer Science. Former WRO competitor (2016 global finals). Specializes in game development.
- **Contact**: raeesianali@gmail.com
- **Links**: [GitHub](https://github.com/SheykhAlii) | [Instagram](https://www.instagram.com/ali_raeesiian/)
### ๐จ๐ปโ๐ซ Hossein Bagheri
- **Role**: Manager
- **Age**: 51
- **Description**: Founder of Shahrood's educational LEGO institute.
- **Links**: [Instagram](https://www.instagram.com/ho.bagheri/)
### Team Photos
| Sepehr Yavarzadeh | Nikan Bashiri | Amirparsa Saemi | Ali Raeesian | Hossein Bagheri |
|-------------------|---------------|-----------------|--------------|-----------------|
| 
| 
| 
| 
| 
|
The ShahroodRC Team
|
Fun Team Moments ๐
|
> In this project, we aimed to combine creativity, teamwork, and technical knowledge to build an efficient robot for the challenges of WRO 2026.
---
## ๐ National Championship Victory & International Success
### 2025 National Championship
ShahroodRC secured **1st Place** at the Iran National WRO 2025 Competition (August 2025, Rasht), earning qualification for the WRO 2025 International Final.
### 2025 International Final โ Singapore
Competing in the World Robot Olympiad 2025 (November 26โ28, Singapore), ShahroodRC achieved:
- โ
**Full Score** in Open Challenge
- โ
**Full Score** in Obstacle Challenge
- ๐ **12th Place Globally**
### 2026 National Qualifiers
Currently preparing for the **Iran National WRO 2026 Qualifying Round** (July 2026, Tehran) to qualify for WRO 2026 International Final.
### Gallery
National Championship Gold Medal
2025, Rasht
|
International Final
2025, Singapore
|
---
## ๐ Robot Progress Journey
A reason-driven timeline of the robot's development through four design stages. Each version reflects a clear decision: what we learned, what we improved, and why the next stage was needed.
### Version 1 โ EV3 starter prototype
This first prototype used the EV3 platform with:
- two ultrasonic sensors for distance awareness
- a floor-mounted color sensor for lap counting
- a Pixy 1 camera for early vision experiments
- two drive motors for propulsion in the Open Challenge, and a single drive motor in the Obstacle Challenge to reduce complexity under difficult conditions
Why this design? The goal was to get a working system on the field quickly and use the color sensor as a simple, reliable lap counter. The limitations were also clear: the robot was slow, the Pixy 1 vision was inconsistent on obstacles, and the system relied too much on floor color detection rather than robust obstacle awareness.
### Version 2 โ sensor upgrade and chassis exploration
In the second version we focused on improving sensing and motion control:
- removed the floor color sensor entirely
- added a gyro sensor for heading stability
- upgraded from Pixy 1 to Pixy 2.1 for better obstacle recognition
- tested a new chassis layout with different wheelbase and track dimensions
Why this design? We needed more reliable perception and better heading control. The Pixy 2.1 and gyro were stronger choices, but the chassis geometry still needed refinement: the front-to-rear spacing was too large and the left-right track too narrow, which prevented the robot from moving as accurately as required.
### Electronic Prototype โ parallel non-EV3 path
While building Version 3, we also began a separate electronic robot project to overcome EV3 hardware limits:
- non-EV3 electronics to escape EV3 processing speed and sensor flexibility constraints
- a design aimed at higher speed and smaller physical size
- Open Challenge functionality completed, with obstacle detection in progress
Why this path? We recognized that EV3 imposed hard limits on processing speed, sensor variety, and overall agility. The electronic prototype is intended for future competition use, but it is still under development and not yet ready for the Obstacle Challenge.
### Version 3 โ competition-ready EV3 robot
The final version is the most refined and reliable EV3 robot we produced:
- sensor placement was optimized for gyro, Pixy 2.1, and ultrasonic sensing
- left-right track width and front-rear wheelbase were corrected for repeatable handling
- the robot achieved smooth, repeatable motion and met the competition requirements
Why this version? It represents the design that learned from the earlier prototypes: better vision, better heading control, and a corrected chassis layout. This is the version we brought to competition-ready performance.
## โ๏ธ Mobility & Mechanical Design
### 1. ๐ Drive and Steering System Choices
- We provide propulsion with one LEGO EV3 Medium Motor driving the rear axle through a differential-style power train that turns both rear wheels together; we chose this because it concentrates traction control on a single actuator and keeps the drivetrain simple for repeatable motion.
- We handle steering with a second LEGO EV3 Medium Motor operating a rudder-style front axle mechanism that turns the front wheels left and right; we selected this arrangement because it cleanly separates steering from propulsion, making motion planning and recovery simpler.
- We selected this drive/steering layout because it separates traction from steering control, simplifying motion planning and reducing the number of active failure modes.
- We avoided a skid-steer layout because it introduces unpredictable pivot behavior and wheel slip; similarly, we did not use independent drive motors because they require more complex control logic, and instead chose this design to maintain consistent, repeatable handling.
### 2. ๐๏ธ Mechanical Structure
- The chassis combines official LEGO EV3 structural elements with custom 3D-printed parts to create a rigid, lightweight frame.
- A reinforced rear axle and a low-mounted drive train keep the center of gravity low, improving stability in straight-line motion and during cornering.
- The front axle and steering linkages are braced to minimize flex and maintain predictable steering geometry under load.
- Cable routing is designed to stay clear of moving parts, bundled along the frame, and secured to reduce vibration and accidental interference.
### 3. ๐ Mounting
- We used custom printed mounts to firmly position the Pixy 2.1 camera, gyro, and ultrasonic sensors so the sensing vectors remain stable under motion and do not shift during competition runs.
- We mounted the gyro centrally on top of the robot to minimize measurement error from pitching or rolling, because placing it near the center reduces the effect of rotational offsets on yaw readings.
- We mounted the two ultrasonic sensors at the front-left and front-right with a 90ยฐ orientation to the centerline to provide reliable side distance sensing; we chose this placement because it yields smoother side-range readings for wall-following.
- We elevated and angled the Pixy camera downward toward the field to ensure consistent target detection and line/object recognition, since that viewpoint improves signature size and reduces false positives.
### 4. โก Torque and Speed Reasoning
- Each EV3 Medium Motor delivers 8 Nยทcm nominal torque and 12 Nยทcm stall torque, with a top speed of 240โ250 rpm.
- We selected these motors because they provide a strong balance between power and precision, enabling controlled acceleration while preserving the accuracy needed for line following and obstacle approach.
- We tuned the drive train for moderate speed with high controllability rather than maximum velocity because that improves performance for precise navigation tasks.
- We geared the steering motor for smooth, repeatable wheel angles to enable accurate turns and stable lane corrections based on sensor feedback.
- We prioritized reproducible motion over raw acceleration to reduce mechanical stress and ensure repeatable performance across many runs.
### 5. โ
Design Justification
- We designed the robot for rigidity, precision, and reliability, choosing control and repeatability over raw speed.
- We added custom structural reinforcements and sensor mounts after testing revealed flex and alignment issues, because eliminating chassis flex directly improved sensor consistency and navigation accuracy.
- We validated the design with multiple test sessions: the robot completed more than 50 runs with consistent handling, showing over 90% success rate in repeated mobility and navigation trials.
- The result is a stable, robust system capable of accurate navigation and reproducible motion behavior for the Future Engineers challenge.
---
## โก Power and Sense Management
### 1. ๐ Power System Layout
- Primary power is supplied by the **EV3 battery pack** (LEGO EV3 rechargeable battery pack) rated at approximately **9V / 2050 mAh**.
- The EV3 battery pack is installed inside the EV3 brick and powers the EV3 brick itself, the two medium motors, the gyro sensor, both ultrasonic sensors, and the Pixy 2.1 camera.
- The EV3 brick is the central power distribution hub. Unlike Arduino/ESP32/Raspberry Pi systems that often require a separate custom power harness, this EV3-based robot uses the brickโs built-in ports and internal regulators to provide safe and reliable power.
- The EV3 supplies 9V directly to the motor outputs and uses an internal regulator to provide 5V for sensors. This is why the motors and sensors operate from different voltage domains even though they are both connected to the same EV3 controller.
- A separate **LED battery pack** is dedicated only to the front LED indicators and is not part of the EV3 power bus. The LED pack consists of three 3.7V cells connected in **parallel** (each 2000 mAh), giving a total capacity of ~**6000 mAh** while keeping the pack voltage at ~3.7V.
- This separate LED battery pack keeps the LED lighting load isolated from the EV3 battery, which reduces interference and ensures the EV3 brick remains focused on motors and sensors.
- Motor outputs are assigned as:
- `OUTPUT_B` โ Medium motor for front steering
- `OUTPUT_D` โ Medium motor for rear drive
- `OUTPUT_A` โ Relay coil control (used to switch the LED battery pack)
- Sensor inputs are assigned as:
- `INPUT_1` โ PixyCam 2.1
- `INPUT_2` โ Gyro sensor
- `INPUT_3` โ Ultrasonic sensor (right-side / front-right)
- `INPUT_4` โ Ultrasonic sensor (left-side / front-left)
- The port assignments reflect function: separate outputs for steering and propulsion, and a dedicated output for relay control so the LED system does not interfere with drive control.
### 2. ๐ Wiring and Cabling
- Wherever possible we use **official LEGO EV3 cables** for signal integrity and robust connectors.
- The Gyro and two EV3 ultrasonic sensors use official EV3 sensor cables directly to EV3 sensor ports.
- The Pixy 2.1 camera does not natively support the official LEGO EV3 sensor connector, so we built a custom cable to adapt it to the EV3 sensor port and I2C protocol. The wiring approach we used:
- We cut a spare official EV3 sensor cable and exposed the six internal conductors (red, blue, yellow, green, white, black).
- We insulated and taped the unused white and black wires because Pixy does not need them.
- We used the four wires **red, blue, yellow, green** to connect Pixy 2.1 and mapped them to the Pixy I2C interface so the EV3 can communicate with Pixy over I2C.
- This custom wiring allows the Pixy camera to work like other EV3 sensors from the brickโs perspective, even though the Pixy uses a non-standard connector.
- The relay and LED wiring also uses a custom EV3 cable adaptation. Because EV3 output ports expect a motor-like device, we adapted an official EV3 output cable so the relay behaves like a motor to the brick:
- We cut another official EV3 output cable and connected two conductors to the relay coil.
- The remaining two conductors that would normally provide encoder feedback were tied together with a resistor to mimic a motor's expected load. This trick makes the EV3 treat the relay as a valid motor-like load.
- The unused conductors were insulated and securely taped.
**Pin Connections (for our EV3โrelay custom cable):**
- **White (Pin 1)** โ Relay coil positive (9V when output is active)
- **Black (Pin 2)** โ Relay and LED ground
- **Red (Pin 3)** โ Relay common / power reference
- **Green (Pin 4)** โ Relay coil negative / ground
- **Yellow (Pin 5)** โ Insulated (unused encoder feedback wire)
- **Blue (Pin 6)** โ Insulated (unused encoder feedback wire)
**Relay Output wiring:**
- Normally-Open contact โ LED+ (battery positive terminal)
- Common contact โ LED- (battery ground terminal)
### 3. โก Power Budget (summary)
The sensors and vision system have low power requirements compared to the motors, which is why we can rely on the EV3 battery pack without using a separate power distribution harness for the main robot electronics.
| Component | Supply | Typical current | Typical power |
|---|---:|---:|---:|
| Gyro sensor | 5 V (from EV3) | 15โ20 mA | 75โ100 mW |
| Ultrasonic sensor (each) | 5 V (from EV3) | 20โ25 mA | 100โ125 mW |
| Pixy 2.1 camera | 5 V (from EV3) | 140 mA | 0.7 W |
| EV3 Medium Motor (idle) | 9 V (from EV3) | ~80 mA | ~0.72 W |
| EV3 Medium Motor (stalled) | 9 V (from EV3) | ~800 mA | ~7.2 W |
Notes:
- Sensor currents are small and do not present a load problem for the EV3 battery pack.
- The EV3 uses a 9V motor rail for the medium motors and a regulated 5V rail for the sensors, which is why the motors and sensors are powered from different voltage sources within the brick.
- The separate LED battery pack isolates the lighting load and prevents LED switching from affecting the EV3 brickโs main power supply.
- The main power risk is motor stall current, so we design motion profiles to avoid prolonged stall conditions and preserve battery life.
### 4. ๐ก Sensor Choices and Placement
- **Pixy 2.1 camera** is mounted above and slightly rearward on the robot, angled about **35ยฐ downward toward the field**. We chose this location so the Pixy can see the path ahead without having its view blocked by the robot body.
- The downward tilt keeps the Pixy focused on the field and avoids looking at objects outside the arena, reducing false detections.
- **Gyro sensor** is mounted centrally on top of the robot. This placement was chosen because it keeps the gyro away from strong electromagnetic sources and near the robot's rotation center, improving heading stability.
- **Ultrasonic sensors** are mounted at the front-left and front-right, each oriented roughly **perpendicular to the robot centerline**. We positioned them slightly ahead of the robot center so they can see field walls in advance and accurately estimate distance.
- We use two ultrasonic sensors because the robot must handle both turning directions around the field walls. During clockwise motion, the right sensor is prioritized; during counter-clockwise motion, the left sensor is prioritized.
- These sensors also compare left/right distances at the beginning of the Obstacle Challenge to determine whether the robot will turn clockwise or counter-clockwise.
- In the Open Challenge, the same comparison helps detect which wall segment is the central 1-meter wall and choose the correct turning direction.
- **Front LED indicators** are mounted above the EV3 brick near the center and facing forward. This location provides the most effective illumination of the path and obstacles.
- The LEDs are angled slightly outward to light the side edges of the robot and the obstacles, ensuring the Pixy camera keeps the object visible until the last moment during obstacle passage.
- The **EV3 battery pack** is installed inside the EV3 brick near the robot center, minimizing its effect on the center of gravity and keeping weight distribution even across the wheels.
- The separate **LED battery pack** is mounted on top of the EV3 brick near the center so its weight is balanced and its power source remains dedicated to the LEDs.
### 5. ๐งช Calibration and Verification
- **Gyro calibration** is performed before each competition run; the robot is held still while the gyro is zeroed to reduce drift.
- **Ultrasonic calibration** is done by checking each sensor against a fixed reference distance and using averaged readings to remove noise.
- **Relay and LED verification** is included in the pre-run checklist: confirm that `OUTPUT_A` correctly triggers the relay and that the front LEDs switch on and off as expected.
- **PixyCam verification** includes cleaning the lens, checking object signatures with PixyMon, and confirming detection reliability under competition lighting.
- Regular inspection of connector seating, cable strain relief, and sensor alignment is part of the pre-run checklist.
---
## ๐ง Software Architecture & Obstacle Strategy
This section is reason-driven and organized to show why each software design choice was made. The robot's architecture is explained through four clearly separated views: flowchart, algorithm phases, path keeping, and obstacle encounter strategy.
### 1. ๐ Flowchart: Full Obstacle Challenge Algorithm
- The full obstacle challenge flowchart is shown below.
- This diagram traces the robot from the moment the start button is pressed to the moment it finishes parking, including:
- startup, sensor health verification, and LED readiness
- direction selection from the parking stall
- repeated section loops for three laps
- real-time obstacle detection and handling
- final parking sequence with ultrasonic wall detection
- For the **Open Challenge**, the same overall flow is used; the only difference is that camera-specific obstacle branches are removed and the robot relies purely on gyro and ultrasonic guidance.
- The code structure supporting this flow uses **EV3Dev2 Python** with two main scripts: `code/open_challenge.py` and `code/obstacle_challenge.py`. Each script initializes hardware, processes perception, executes motion commands, and manages behavior state with explicit loop variables and counters.
- Key runtime states include:
- **direction selection**: deciding clockwise or counterclockwise from parking
- **section progression**: executing each course segment and updating counters
- **obstacle detection**: switching from normal traversal to the obstacle pass algorithm
- **fallback wall following**: maintaining course when vision is unavailable
- **parking completion**: ending the run safely after the final section
### 2. ๐ Algorithms: Why the Robot is Divided into Three Phases
- The Obstacle Challenge software is intentionally split into three reasoned phases:
1. **Exit the parking bay**
2. **Main traversal loop** (12 section passes = 3 full laps)
3. **Return and park**
- This structure is chosen because each phase has different sensor priorities and risk profiles. Separating them keeps the behavior deterministic and easier to validate under competition rules.
#### Phase 1: Exit the parking bay
- The robot starts by comparing left and right wall distance with the two ultrasonic sensors.
- This comparison decides whether the traversal direction is **clockwise or counterclockwise**.
- Because the field layout determines which wall is on the inner side, using both ultrasonic sensors first avoids guessing and prevents an early wrong turn.
- After the direction is chosen, the robot steers out of the parking bay with a controlled heading correction and begins the main loop.
#### Phase 2: Main traversal loop
- The core behavior repeats 12 times, corresponding to the 12 course sections needed for 3 complete laps.
- In each section:
- the **gyro sensor** keeps the robot straight and prevents excessive angular drift inside the section
- the **active side ultrasonic sensor** maintains a safe centerline relative to the inner wall, keeping the robot away from both inner and outer walls
- when the inner-wall distance grows rapidly, the software interprets this as having passed the central field wall and issues a turn command by updating the gyro heading target
- This layered approach is chosen because a single sensor cannot reliably maintain both heading and lateral position at the same time. The gyro enforces straightness while the ultrasonic sensor enforces section centering.
- Maintaining moderate speed is essential here: excessive velocity would shorten sensor update windows, degrade ultrasonic consistency, and reduce the available reaction time for obstacle detection.
- During the entire main traversal, the Pixy camera is also watching the path ahead. If the camera detects an obstacle, the robot temporarily shifts to the obstacle-pass algorithm.
#### Phase 3: Return and park
- After 12 sections, the robot enters the parking phase.
- It first moves cautiously toward the outer boundary wall, using ultrasonic sensing to detect the wall reliably.
- Then it reverses at a fixed safe distance from the outer wall until the parking zone is recognized by the ultrasonic sensors.
- Once parking is detected, the robot executes a controlled double-park maneuver.
- This final phase is separate because parking requires very low speed, precise wall distance control, and the avoidance of any obstacle override behavior.
#### Open Challenge difference
- In the Open Challenge, the same three-phase structure is preserved, except there is no exit/parking phase.
- The robot performs the main traversal only, without opening the camera-based obstacle branch.
- This decision keeps both scripts aligned conceptually and makes the Open Challenge implementation simpler while retaining the same robust section-based control logic.
### 3. ๐งญ Path Maintenance: Why Gyro + Ultrasonic are Both Needed
- Path maintenance in Obstacle Challenge uses a **hybrid control strategy**.
- The **gyro sensor** is responsible for keeping the robot straight inside each section. This prevents the robot from accumulating heading error over long straight segments.
- The **ultrasonic sensor** ensures the robot stays centered in the section by comparing distance to the inner wall.
- The reason for this combination is practical:
- gyro-only control would keep heading but drift laterally toward walls
- ultrasonic-only wall following would not maintain a true straight line and would suffer in corners
- By splitting the task, the robot keeps the wall at a safe offset and maintains heading stability, which also improves obstacle visibility by keeping the camera aligned with the expected path.
- The control law is proportional: `out = (setpoint - measured_distance) * direction_sign`, then limited with `clamp()` to prevent oversteering.
- This hybrid approach is also a robustness strategy: the gyro corrects heading faster than wall distance feedback alone, while the ultrasonic sensor prevents gradual drift that could cause a collision.
- The same gyro + ultrasonic path maintenance is used exactly the same way in the Open Challenge, even though the camera is disabled. That consistency reduces software complexity and risk.
### 4. ๐ง Obstacle Encounter Strategy: Linear Formula with Color-Based Side Choice
- When the Pixy camera sees an obstacle, the robot switches from normal path maintenance to obstacle handling.
- The obstacle algorithm first detects the obstacle color, then uses the obstacleโs horizontal position (`x`) and proximity (`y`) from the Pixy camera to compute movement.
- Front LED illumination is part of this strategy, stabilizing vision quality and helping the Pixy camera detect obstacles more reliably under variable lighting.
- The algorithm applies a linear formula so that as the robot gets closer the formula output increases and the robot moves farther around the obstacle. This design provides the safest and smoothest motion compared to alternate obstacle-following methods.
- The formula is designed for two purposes:
1. keep the obstacle centered in front of the robot while it is still distant
2. adjust the steering angle based on obstacle color when it gets closer
- In practice, when the obstacle is far the robot drives directly toward it and keeps it in view. As the obstacle approaches and its vertical size increases in the camera frame, the formula smoothly shifts steering to pass on the correct side.
- Color classification is essential: green obstacles are passed on one side and red obstacles on the other, so the robot does not use a one-size-fits-all avoidance rule.
- The formula was generated by putting the Pixy camera in **View mode**, recording the initial `x` and `y` values, then placing the robot in the desired obstacle-pass position and recording the secondary `x` and `y` values. Those data points were entered into GeoGebra, and the resulting linear formula was derived from the observed behavior.
- Once the obstacle is no longer visible, the robot returns to normal gyro + ultrasonic traversal and continues the section loop.
### 5. ๐ค Why this structure?
- We organize the section to show the reasons behind each design choice, not only what the robot does.
- The four views ensure the robotโs software is clearly understood as a flowchart-driven system, a repeated section algorithm, a combined path control mechanism, and an obstacle-specific strategy.
- That clarity is essential for scoring this section: the algorithm is visible, the path keeping method is explicit, and the obstacle strategy is documented with both a diagram and a formula.
---
## ๐ก Systems Thinking & Engineering Decisions
This section explains the engineering logic behind the robot design, the relationships between subsystems, and the reasoning used to make the system robust for the Future Engineers challenge. Every major decision in this project was made not only to improve performance, but also to reduce uncertainty, improve repeatability, and make the robot safer and more reliable during competition.
### 1. โ ๏ธ Constraints and Design Limitations
- One of the main constraints in our robot is speed. When the robot moves too fast, the time available for reading and processing ultrasonic data becomes too short, which reduces the quality of reactions to walls and makes navigation less stable. This is why we designed the motion system to prioritize controlled movement over aggressive speed.
- Lighting is another major constraint. In conditions where natural light comes from one side, the Pixy camera struggles to detect obstacles reliably. For this reason, the competition field should ideally be illuminated evenly and without strong directional sunlight. We solved this by installing front LEDs on the robot so that the environment in front of the robot remains more stable and easier for the camera to interpret under different conditions.
- Mechanical constraints also matter: the robot must remain compact enough for the competition field while still carrying the EV3 brick, motors, sensors, and battery systems. The chassis therefore had to be rigid, lightweight, and stable enough to support consistent motion.
- Hardware constraints include the limited battery capacity, the limited processing resources of the EV3, and the need to control several sensors and motors at the same time. These constraints forced the team to balance power, weight, response speed, and control complexity carefully.
- Sensor constraints are also important: the Pixy camera is sensitive to lighting and angle, ultrasonic sensors can be affected by reflections and geometry, and the gyro can drift if calibration is not handled properly.
- Competition constraints also shaped the design. The robot had to follow WRO Future Engineers rules, stay practical to build and maintain, and remain robust across repeated runs.
### 2. ๐ Subsystem Interactions and Why the Architecture Was Chosen
- The drive and steering subsystems are tightly coupled through the EV3 control logic: the rear motor provides forward propulsion, while the front steering motor changes the heading. This separation makes the motion system easier to control and more predictable than a skid-steer layout.
- The vision subsystem uses the Pixy 2.1 camera to detect obstacles and estimate their position. These measurements directly influence steering decisions and help the robot decide when to track an object or switch to fallback behavior.
- The proximity subsystem uses two ultrasonic sensors on the left and right sides of the robot to maintain safe side clearance and support navigation when vision is temporarily lost. This improves the robot's ability to follow walls and avoid collisions.
- The gyro subsystem provides heading feedback to the EV3, allowing the robot to correct drift and maintain better directional stability. This is especially important when the robot must keep a consistent course under repeated motion cycles.
- The lighting subsystem uses front LEDs, powered separately and controlled through a relay, to improve the camera's visibility and make obstacle detection more reliable under changing light conditions.
### 3. ๐ Alternative Design Choices and Justification
- For the chassis, alternatives such as fully 3D-printed frames, metal structures, or wooden structures could be used. However, each of these has drawbacks. Fully 3D-printed parts can increase cost and fabrication complexity, metal parts add weight and may create mechanical difficulties, and wood can deform under friction, heat, or moisture. We chose LEGO structural parts because they are accessible, modular, and easy to modify. This was a major advantage because when a design flaw was discovered, the team could quickly adjust the chassis and test a new version without rebuilding the entire robot.
- For the vision system, other cameras could also be used, but they usually require more processing power or higher cost. We selected the Pixy 2.1 because it performs object and obstacle processing internally and sends only the final results to the EV3. This reduces the computing burden on the main processor and allows a higher effective frame rate, which improves reaction speed. A different camera would be possible, but it would usually require more code, more processing on the main controller, and greater design complexity.
- For the main processor, there is no practical replacement for the EV3 in this robot because it is the most compatible and straightforward platform for controlling the sensors, motors, and power interfaces used here. Its main disadvantage is that it is relatively large and heavy, which makes it less suitable for extremely compact and ultra-light robots.
- We also considered alternative motion layouts. A skid-steer system could provide aggressive turning, but it would introduce more wheel slip and less predictable motion. Independent drive motors would offer more control freedom, but they would also increase coding complexity and create more failure modes. The chosen rear-drive and front-steer layout was selected because it offers simpler control, more repeatable motion, and better stability for precise navigation.
### 4. ๐งช Experimental Validation and Iteration Cycles
- We tested the robot experimentally on the field rather than relying only on theory. Each subsystem was evaluated separately: motors, sensors, and control logic were tested one by one to confirm that each component performed its intended task correctly.
- We used a strict validation standard. A subsystem was considered successful only when it completed its task correctly for 10 consecutive runs without error. Once that level was reached, it was fixed into the robot and used confidently in future runs.
- We applied this same logic to all algorithms, including steering control, wall-following behavior, obstacle detection, and fallback strategies. This helped us ensure that the final system was not only functional in principle, but also dependable under real competition conditions.
- The design evolved through several iterations. Version 1 used a simpler chassis and a rougher sensor layout. Version 2 improved the orientation of the ultrasonic sensors and adjusted the Pixy camera angle. Version 3 moved the gyro closer to the robot center and improved LED positioning. The final adjustment refined the LED angle and control parameters so the robot became more stable and repeatable.
- The software was also tuned experimentally through repeated test runs. Gains, thresholds, and control limits were adjusted until the motion became smooth and consistent.
### 5. ๐ก๏ธ Risk Reduction and Robustness Strategies
- One of the most effective ways to reduce risk is to lower the robot speed. Slower movement gives the sensors more time to update, the control loop more time to interpret data, and the motors more time to respond accurately. This reduces the chance of wall collisions and unstable behavior.
- We also reduced risk by combining multiple sensing methods rather than relying on a single source. Ultrasonic sensors provide distance information for wall-following, while the gyro adds heading stability and improves motion consistency. This produces more reliable results than using either sensor alone.
- The software includes fallback behavior so that the robot does not fail completely when the main perception method is temporarily weak. If the camera loses the target, the robot can continue with wall-following or search behavior instead of stopping abruptly.
- We also included pre-run verification. Before the main program starts, the robot checks the health of the sensors and actuators and confirms that the required subsystems are operating correctly. If a problem is detected, the robot avoids unsafe motion until the issue is resolved.
- The lighting system is part of the risk reduction strategy. By controlling the illumination in front of the robot with LEDs, we reduce the effect of changing external light and improve obstacle detection consistency.
- The overall design also emphasizes maintainability. Spare parts, organized wiring, structured sensor mounting, and clear pre-run checks make the robot easier to repair and safer to use during testing and competition.
### 6. ๐ Spare Parts and Pre-Run Checklist
- Spare parts: two extra EV3 Medium Motors, extra ultrasonic sensors, extra gyro sensor, one extra Pixy camera, extra wheels and tires, spare EV3 battery, spare LED battery pack, relay, cables, connectors, and soldering tools.
- Pre-run checklist: confirm the EV3 battery is charged, verify the LED battery pack is charged, clean the Pixy lens, check sensor ports, calibrate the gyro while the robot is still, verify relay operation through OUTPUT_A, inspect cable routing and mounts, and perform a short dry run before the actual challenge.
| Risk | Why it matters | Mitigation |
|------|----------------|------------|
| Pixy detection failure due to lighting or angle | The robot may lose obstacle information at a critical moment | LED illumination, threshold tuning, and fallback search behavior |
| Ultrasonic false readings from reflections | The robot may misinterpret wall distance and drift off course | Careful sensor positioning, filtering, and control clamping |
| Gyro drift or calibration error | Heading estimation may become unstable | Pre-run calibration and stable mounting near the robot center |
| Mechanical looseness or cable interference | Sensor alignment and motion stability may be affected | Reinforced mounts, organized cabling, and vibration-resistant assembly |
| Power drop during long or aggressive runs | Performance may degrade during the mission | Moderate motor power, controlled acceleration, and battery checks |
| Single-point failure in a critical subsystem | One weak component could compromise the full run | Spare parts, fallback logic, and simple recovery behavior |
---
## ๐ฑ Randomizer App
> Generates **WRO-compliant** random tracks for both challenges.
To help our team test the robot against unpredictable track layouts, ShahroodRC developed a custom Android **Randomizer App**. It creates randomized, rule-compliant configurations for both the **Open Challenge** and the **Obstacle Challenge**, enabling faster practice setup and more robust validation.
### App Screenshots
 |
 |
 |
| Welcome Screen |
Main Menu |
Challenge Selection |
 |
 |
|
| Obstacle Challenge |
Open Challenge |
|
### Features
- **Dual challenge support** for both Open and Obstacle rounds.
- **Rule-compliant layouts** following WRO Future Engineers requirements.
- **Simple interface** with one-touch generation.
- **Offline operation** for use in any practice environment.
- **Exportable results** for easy sharing and setup.
### Usage
1. Install `randomizer.apk` on any Android device (Android 7.0+ recommended).
2. Open the app and choose the challenge type: **Open** or **Obstacle**.
3. Use the generated layout to set up your practice arena or test robot behavior.
> **Note**: This app was used internally during development to ensure the robot could handle any valid WRO scenario with robustness and adaptability.
### Download
- [`randomizer.apk`](randomizer.apk)
> **Security Note**: This APK is built and signed by the ShahroodRC team. Scan files with your preferred antivirus before installation.
---
## ๏ฟฝ๐ค Contributing & Support
This project is **open-source** and welcomes:
- ๐ **Bug reports** โ Found an issue? Let us know!
- ๐ก **Suggestions** โ Have ideas for improvement? Share them!
- ๐ **Documentation improvements** โ Help make it clearer!
### Quick Links
- ๐ง **Email**: sepehryavarzadeh@gmail.com (Project Manager)
- ๐ **Instagram**: [@shahroodrc](https://www.instagram.com/shahrood_rc/)
- ๐น **YouTube**: [ShahroodRC Channel](https://youtube.com/@shahroodrc)
---
## ๐ License
This project is licensed under the **MIT License**, allowing free use, modification, and distribution with proper attribution. See the [LICENSE](LICENSE) file for full details.
---
**Built with โค๏ธ by ShahroodRC Team**
๐ Representing Iran at WRO 2026 National Final in Tehran ๐
See you in Tehran!
ยฉ 2026 ShahroodRC โ All rights reserved.
