Initializing portfolio

Roy.

Product · systems · impact

Roy
Selected work

Case study · Jan–Jul 2025

Karggu Robots

I helped turn package dimensions, weight constraints and warehouse routes into a working multi-agent simulation with two interactive 3D renderers.

Textured 3D warehouse simulation with robots, packages and a cargo loading area.

Overview

Product context and challenge

Karggu Robots is a logistics prototype for exploring how autonomous robots can collect packages, navigate a shared warehouse grid and deliver cargo according to a three-dimensional packing plan.

The project connects constraint-aware packing, agent-based behavior, route planning, API state exchange and interactive visualization. Operators can define packages, run the simulation and inspect how robots move cargo toward its calculated position.

Core challenge

The simulator had to solve three dependent problems: determine where each package could fit, preserve the resulting delivery order and route multiple robots through the same space without invalid movement.

Rendering added a separate challenge. Both the browser client and the textured PyGame/PyOpenGL client worked across Windows, macOS and Linux, but the desktop renderer showed slower behavior on Windows. Keeping simulation state independent from either renderer made both approaches usable for comparison.

Role

My scope within the team

I worked as a full-stack developer in a three-person team. My scope covered the package-placement and robot-routing logic, custom package workflows, 3D modeling and both visualization clients.

  • Implement three-dimensional package placement using dimensions and weight
  • Build package assignment and delivery-sequencing logic
  • Implement A* routes for robots moving through a shared grid
  • Support custom package creation and simulation setup
  • Create models and textured scenes for the 3D experience
  • Work on the React and Three.js browser renderer
  • Work on the PyGame and PyOpenGL desktop renderer
  • Connect renderer state to the Julia simulation workflow

The delivered simulator was a shared team outcome. This page focuses on the packing, routing, package-management and visualization work I completed personally.

Architecture

How the product layers connected

Simulation logic remains independent from the renderer, allowing two clients to consume the same evolving state without duplicating robot behavior.
  1. Operator clients

    React/Three.js and PyGame/PyOpenGL interfaces prepare, control and visualize a run.

  2. Simulation API

    A Genie service creates simulations and returns incremental JSON state snapshots.

  3. Agent model

    Julia and Agents.jl coordinate robots, packages, routes and delivery dependencies.

  4. Packing engine

    Python packing logic calculates fitted packages, rotations and final cargo coordinates.

Workflow

From custom packages to coordinated delivery

Every step depends on the output of the previous one, so packing feasibility and delivery order are established before robot movement begins.

Define the load

Register package names, dimensions and weight together with container constraints.

Calculate placement

Determine which packages fit and assign coordinates and an ordered loading plan.

Dispatch robots

Assign available packages and calculate A* routes around occupied cells.

Render progress

Advance the simulation and update robots, packages and storage in either 3D client.

Contribution

Work completed across the stack

Packing and ordering

  • Used package dimensions and weight to calculate feasible placement
  • Preserved the packing result as a delivery sequence
  • Handled fitted and custom package information

Robot coordination

  • Implemented package assignment and lifecycle transitions
  • Built A* routing with dynamic occupied positions
  • Coordinated pickup, delivery and waiting behavior

3D visualization

  • Created the browser scene with React and Three.js
  • Developed the textured desktop renderer with PyGame and PyOpenGL
  • Modeled warehouse, robot, package and cargo elements

Full-stack integration

  • Connected visualization clients to incremental simulation state
  • Supported operator controls and custom package workflows
  • Kept renderer concerns separate from core agent logic

Decisions

Engineering a simulation that could evolve by layer

Separate simulation state from visualization

Both renderers consume simulation state instead of owning robot behavior, making the core logic easier to reason about and compare across clients.

Use packing output as a delivery constraint

The order returned by the 3D packing stage becomes an explicit dependency so robots do not finalize packages out of sequence.

Plan routes with A* and dynamic obstacles

Robots calculate goal-directed paths while treating other robot positions as occupied cells and trying valid alternatives when blocked.

Maintain two rendering approaches

A browser renderer provided a lightweight interactive view while the desktop renderer explored richer custom geometry and textures across the same domain.

Deep dive

Three algorithms, one coordinated simulation

Packing

Dimensions, rotation, intersection checks and maximum weight determine feasible cargo coordinates.

Coordination

Assignment and package dependencies preserve the planned sequence while multiple robots operate concurrently.

Routing

A* paths use Manhattan distance and current robot positions to avoid invalid grid movement.

01

Browser renderer

React and Three.js provide an orbitable scene with live position updates and operator controls.

02

Desktop renderer

PyGame and PyOpenGL add textured geometry, a custom camera and continuous API polling.

03

Shared state

Both clients represent the same robots, packages and destination coordinates from the Julia service.

Outcome

What shipped—and what remains unproven

Delivered

  • Delivered multi-agent logistics prototype
  • Three-dimensional package placement with weight constraints
  • A* robot routes and collision-aware movement
  • Ordered package pickup and delivery workflow
  • Custom package-management controls
  • Two working interactive 3D renderers

Limitations

  • The project did not reach formal testing or performance measurement, so no throughput or route-efficiency metrics are claimed.
  • The desktop renderer showed slower performance on Windows and would require a dedicated optimization pass.
  • This is an engineering prototype, not a certified warehouse-management system, digital twin or physical robot controller.

Lessons

  • Separating the simulation engine from presentation made it possible to test different visual approaches without rewriting agent behavior.
  • A visually convincing robot simulation still depends on explicit constraints, deterministic state transitions and careful coordination logic.

Evidence

Selected product evidence

Karggu Robots textured warehouse with packages, forklifts and cargo loading area

Desktop simulation renderer

The textured PyGame and PyOpenGL client visualizes packages, robot movement and the cargo destination while polling simulation state.

Full resolution
Karggu Robots julia simulation of a warehouse with packages, forklifts and cargo loading area

Windows Desktop simulation renderer

Full resolution

The Julia client visualizes packages, robot movement and the cargo destination while polling simulation state.

Attribution

Team work, clearly attributed

Karggu Robots was completed by a three-person team for Karggu. The screenshot and technical description are shown with permission. Client source code, operational data, original assets and configuration remain private.