The problem

Manual apple counting is labour-intensive, inconsistent, and unscalable across commercial orchards. Growers need accurate fruit estimates to plan harvest logistics, but walking every row and counting by hand is impractical at scale.

This project builds an autonomous UAV pipeline that flies along orchard rows, detects individual apples using deep learning, and produces a georeferenced per-tree apple count — without any manual intervention during the flight.

Digital twin environment

The full pipeline was developed and tested in a simulated replica of a real apple orchard, built in Unreal Engine with AirSim as the flight simulator. Tree positions were GPS-matched from a real orchard dataset — creating a digital twin that reflects actual spatial layout and canopy density. The DJI Mavic 3T (thermal + RGB) was the target real-world platform.

Waypoint navigation

The UAV follows programmed waypoint paths running parallel to each tree row, with the camera oriented perpendicular — giving the detector a lateral view that exposes fruit that would be occluded in a top-down (nadir) pass. Flight altitude and inter-waypoint spacing were tuned to balance detection coverage against flight time.

Apple detection — YOLOv7

A YOLOv7 model was fine-tuned for apple detection on simulation frames, outputting bounding boxes and confidence scores per frame. Multi-object tracking was applied across frames to avoid double-counting the same fruit as the drone passes by. Each tracked detection was assigned a GPS coordinate from the drone's pose at detection time, producing a georeferenced apple map per tree.

YOLOv7 running on Unreal Engine simulation frames — bounding boxes with per-apple confidence scores

Results

The pipeline was validated against the simulated orchard where each tree has a known ground-truth apple count of 8. The per-tree apple count distribution tracked closely around the expected value, with the majority of trees detected within ±3 apples of ground truth across 160+ trees in the orchard.

My contributions

• Digital twin construction in Unreal Engine + AirSim with GPS-matched tree placement
• Waypoint navigation system with tree-row-facing flight path planning
• YOLOv7 fine-tuning and deployment for apple detection in simulation
• Multi-object tracking pipeline to avoid double-counting across frames
• Georeferenced per-tree apple count aggregation and result visualization
• Supervisor: Fabio Augusto de Alcantara Andrade — USN

Ongoing master's thesis — results and methodology will be refined through the 2026 academic year.

The problem

Traditional solar system models are fixed — they show one configuration and can't be adapted to focus on a single planet or its satellite. For STEAM education this limits how teachers can use them interactively in class.

The goal was a modular system: the structure physically adapts depending on which planet is being studied, and each planet's orbital mechanics — translation, rotation, axial tilt, and satellite revolution — can be explored in isolation.

Scaled dimensions & orbital periods

Rather than arbitrary proportions, the system uses a base-10 logarithmic scale for planet diameters (so Jupiter at 51.6 mm and Mercury at 36.9 mm remain visually distinct) and a separate log scale for orbital distances — placing Mercury at ~100 mm and Neptune at ~200 mm from the central lamp. Orbital and rotation speeds are derived from real astronomical data, scaled so Jupiter's rotation period sets the maximum motor speed.

Mechanical design

Each planet module uses a stepper motor for rotation, two micro-servo motors for axial tilt and satellite orbit inclination, and a ring gear driven by the satellite servo inside a compact planetary housing (Caixa Planetária). The satellite arm mounts on the ring and stays synchronized — always showing the same face toward the planet, reproducing synchronous rotation. All components were modelled in Autodesk Inventor, then fabricated via 3D printing (PLA) and laser-cut acrylic/MDF at the Laboratório Aberto de Brasília.

Exploded views

The three assemblies below show every modelled component: the main shaft and translation arm, the planetary support structure, and the full planet + satellite mechanism.

Planet & satellite ring assembly

Planetary support structure enclosure

Main shaft & translation arm (Eixo Principal)

Electronics & control

An Arduino Uno manages 4 motors simultaneously — a stepper for planetary rotation, a stepper for satellite revolution, and two servos for axial tilt and orbital inclination. Slip rings (anéis coletores) at rotation joints prevent wire tangling during full translation. Speed ratios are calculated from real astronomical data so each planet runs at its correct relative period.

Final prototype

The first version was tested with Mercury, Venus, and Earth + Moon. All seven motion requirements were met — translation, rotation, axial tilt, satellite revolution, synchronous satellite rotation, direction-locked translation plane, and easy planet swap — except continuous translation (limited by the servo range, handled in firmware).

My contributions

• Full mechanical design in Autodesk Inventor — planetary housing, ring gear, shaft, translation arm, modular brackets
• Mathematical scaling of planet sizes, orbital distances, and rotation/translation speeds from real astronomical data
• 3D printing all structural and gear components in PLA; laser cutting base and mounting plates in acrylic/MDF
• Arduino firmware — 4-motor synchronization with astronomically derived speed ratios and automatic translation return
• Dynamic simulation in Inventor to validate movement before fabrication
• Written thesis (125 pp.) documenting design decisions, scale derivations, and educational applications
• Supervisors: Prof. Dr. Carla Maria Chagas E. Cavalcante Koike & Prof. Dr. Jones Yudi Mori Alves da Silva — UnB

The problem

Parkinson's disease is typically diagnosed years after neurodegeneration has begun. Two of the earliest detectable symptoms — changes in grip strength and finger-tapping speed — are measurable non-invasively with the right hardware. Vitacheck aims to make these clinical tests accessible outside a hospital setting.

How it works

The system has two main components: a 3D-printed grip force sensor housing (MA-100 force cell) that the patient squeezes, and a tablet running the Vitacheck app. A second test asks the patient to tap a screen as fast as possible — a digitized version of the standard clinical finger-tapping test. Both signals are processed in real time with metrics displayed live in the GUI.

My contributions

• Integration of MEMS-based force and motion sensors with embedded hardware
• Full Python GUI development for real-time patient interaction and test administration
• Signal acquisition pipeline — from sensor output to processed metrics
• Cross-layer integration: hardware, firmware, and application software

Architecture

The platform follows a three-zone pattern: Raw Zone (exact source replicas), Staging Zone (cleaned, deduplicated), and Curated Zone (business-ready tables). CDC ingestion via AWS DMS; all processing on Amazon EMR with Delta Lake — enabling ACID transactions, upserts, schema evolution, and time-travel queries.

Outcomes

Gave every business unit at AKAD access to clean, versioned, queryable data for the first time. One measurable outcome: reduced cargo insurance loss ratios. Featured in an official AWS Brazil blog post, credited as co-author alongside the AI Engineering Manager and AWS Solutions Architects.

My contributions

• Full architecture design — three-layer schema, zone boundaries, data contracts
• AWS DMS setup for CDC ingestion from 6 relational database sources
• Delta Lake on Amazon EMR with ACID, upserts, and time-travel
• Pipeline orchestration with AWS Step Functions
• Data Warehouse build for Power BI and actuarial teams
• Monitoring and observability with AWS CloudWatch across all stages

The challenge

The Trinity College Firefighting Robot Contest places autonomous robots in a house-like maze. When an alarm triggers, the robot must navigate from its starting position, locate a lit candle, and extinguish it — all without human intervention. The arena layout is unknown in advance.

Design & engineering

Led structural CAD modeling in Autodesk Inventor, then fabricated components via 3D printing and aluminium profile framing. Arduino-based embedded logic handled ultrasonic wall-following navigation, flame sensor array direction finding, and motor control for drive and the extinguisher mechanism.

My contributions

• Full robot structure modeled in Autodesk Inventor
• 3D printing of custom structural and mounting components
• Arduino embedded logic: sensor input, navigation, flame detection, motor control
• Water containment solution: sealed bird feeder as reservoir
• Integration and system-level debugging ahead of competition