Ario Barin Ostovary

A few things worth seeing (click the projects for more info)

eValuator. An ML-powered auction sniper that flags underpriced listings and suggests high-value flips.

Pollinator. A robot arm that locates flowers with depth sensing and pollinates them autonomously.

There's more to see in the sidebar.

Part of the University of Waterloo SE Webring

Wat Street

At Wat Street, I'm working on a market regime detection system that models the market as distinct behavioral states instead of just "up" or "down."

The goal is to avoid using one trading model for every environment. We detect the current regime first, then use that signal to route capital toward strategies that fit the conditions. That matters because market behavior changes over time, and models trained in one regime can fail when volatility and correlations shift.

My work has focused on the labeling and forecasting pipeline: building the k-means clustering approach, improving agreement across labeling methods, creating the final labeled dataset with a pessimistic pivot rule (favoring the riskier state when models disagree), and training/optimizing a Temporal Convolutional Network (TCN) to predict regime transitions ahead of time.

A big part of the work is making the labels trustworthy before using them for prediction. We compare unsupervised methods (Gaussian HMMs and k-means), check where they agree historically, and resolve the remaining conflicts with a risk-aware tie-break. We pushed agreement to about 81%, which gives us a much cleaner training signal than treating the labels as arbitrary clusters.

From there, the TCN is trained on the labeled sequences to forecast regime transitions. The target is not exact price prediction. It is to predict how the market is likely to behave next, early enough to switch strategies before the environment changes.

Wat AI

You can't train a real RC car from scratch strictly in the real world. It would crash around thousands of times before learning anything useful. So: you train it in simulation, where crashing is free, and hope it transfers enough to the real thing. Then fine-tune from there.

When I joined, the project was basically a title and a tech choice. We knew we wanted to do an RL racecar with PyBullet, but that was about it. No track dimensions, no car scale, no hardware picked, no plan for what "done" meant. So I kind of just... took charge of the direction. Wrote docs so the team had something concrete to point at instead of vibes, figured out how to split the work so nobody was blocking each other, and handled the hardware side. I also made a cartpole example repo for people who were new to PyBullet.

I built the simulation environment and an interactive track creator. The whole point is that if you train on a ton of different tracks, the model should generalize. So when we put this on a real car, it already knows how to drive. All it needs to pick up is the physics of real life. That's the dream, anyway. I ran 40+ experiments testing PPO and SAC on different difficulties, and our best agent hit 96% of the theoretical max reward on the hardest track. Pretty satisfying to watch it nail corners it's never seen before. We're presenting this at CUCAI, the Canadian Undergraduate Conference on AI. Madhav, one of the directors, also got me into using AI for quick prototyping, which has been really useful.

Pollinator

Make a robot arm pollinate flowers. Autonomously. I somehow landed a research assistant position at the University of Windsor's AI Robotics Centre. I was busing 40 minutes every morning, but honestly? Completely worth it. The arm had an Intel RealSense depth camera mounted on it (stereo IR + RGB), but nobody in the lab really knew how to control it yet. So I spent a lot of time reading through scattered documentation, figuring out how to actually send commands to this thing. I also 3D modeled and printed the tool mount (the yellow thing at the end of the arm).

I fine-tuned YOLO and Faster R-CNN models to detect blossoms, tested them, compared them. Then came the fun part: SE(3) calibration. That's basically the math that converts "the camera sees a flower at this 3D point" into "the arm needs to move here." Getting that transformation right was tricky, but when it finally clicked, the arm just... reached for the flower. Exactly where it should.

The whole thing ran on a Jetson Orin Nano, basically a credit card sized computer. I'd been developing everything on my Windows laptop, so deploying to Linux meant reworking a bunch of stuff. But in the end, the robot could find and pollinate flowers completely on its own. Part of the job was also making sure the next person wouldn't have to struggle like I did. I spent a lot of time reading through scattered documentation to get the arm and camera working through code, so I wrote up guides for all of it: controlling the arm with Python, Intel RealSense SDK, and a YOLO primer. The next researcher who walks into that lab is pretty much set up perfectly.

eValuator

eValuator is a project I built for Hypixel Skyblock's auction market. It scans listings, estimates how likely an item is to sell at a given price, and flags underpriced auctions worth flipping.

The core idea is simple: if a listing looks like it would still sell with very high probability at a meaningfully higher price, it is probably underpriced right now. I buy it, relist it where the sell probability is still strong, and keep the spread.

I built the entire system myself end-to-end: data collection, cleaning, feature processing, training pipeline, XGBoost modeling, isotonic calibration, and the UI/site. Over time I tracked more than 12 million listings (about 40 GB of auction data), which gave me enough data to model item behavior at a practical scale instead of guessing from small samples.

The hardest part was not finding obvious underpriced listings as a first filter. It was getting the arbitrage logic right: is it underpriced enough, how much can I raise the price, how likely is it to sell after relisting, and is the expected profit worth the time? That is what turned it from a model demo into a usable trading system.

Under the hood, the model is trained to answer a more useful question than "what is the exact price?" It estimates whether an item will sell at a given price, then I calibrate the outputs so the scores behave like real probabilities instead of just rankings. That probability signal is what makes expected value calculations and sizing decisions usable in practice.

It also picks up on item-level edge cases that fool a lot of players. One example is pets with a Tier Boost applied: they can look like a bargain compared to naturally higher-tier versions, but they are not equivalent because the upgrade path is different and that changes what the item is actually worth.

I tracked enough data to get stable signals fairly early, but scaling to 12M+ listings changed how I worked. I used smaller sampled datasets to iterate quickly, then ran full-scale training once an approach looked promising. At its peak, the system put me in the top 0.01% of daily earnings, but the part I cared about most was building something that held up in a noisy, fast-moving market.

I don't really play much anymore. I mostly built this because I liked the ML and market-design challenge, and it was a fun way to turn a game economy into a real modeling problem.

Fourier Trading

I came across Skyblock.finance, and I didn't realize how seriously people were taking this game. They were spending money on spreadsheets, but using TradingView on a video game? That's intense. Anyway, turns out you can download their data, although they don't have an official API. You can go under the network tab, inspect element, and figure out how to send an API request so that they give you all their data. So I did that.

Around that time, I watched a 3Blue1Brown video on Fourier transforms. I thought, "You know what else I could apply this to besides pressure over time? Price over time." So I tried it with the most popular item, the Booster Cookie. That bad boy had a strong sine wave with a frequency of exactly 1 day. I graphed a scatter plot of normalized price over time modulo 4, 2, then 1 day, and the pattern was undeniable.

I couldn't believe nobody was arbitraging this. The price would just swing through predictable cycles. I started placing counter-orders during the dips, and I was making a killing. It was incredible!

Items had their own obvious behaviors as well...

You could hop on for 10 minutes a day, trade some stuff, hop off... but only for so long. Eventually I got tired of the game.

Particle Drift

For my grade 12 final, feeling ambitious, my friend and I decided to build a robot that maps rooms autonomously. Like a Roomba, but just the mapping part, not the cleaning. A SLAM algorithm from scratch. He knew hardware, so he built the car. I wrote the algorithm.

Here's how it works. Imagine a grid where each cell is about 5cm by 5cm. Each cell has a probability of being occupied (wall, furniture, whatever). When the LiDAR reads 100cm at some angle, every cell along that path gets less likely to be occupied, and the cell at 100cm gets more likely. You know, because there's something there. At the same time, the algorithm is trying to figure out where the car actually is by maintaining hundreds of "particles," each one a guess for the car's position. It nudges them based on how well their perspective matches what's been mapped so far, and the best guesses survive.

The reason you need the nudging is that encoder readings aren't perfect and sensors are noisy. So you keep randomly perturbing the particles to stay stable. All of this runs on probabilities, and this is where I learned about log odds. Using logarithms to represent probability is really clever. We built a simulation to test it, then tried it on the real hardware.

ReelJobs

"What if job listings were just TikToks?" Somebody said it during a complaining session about job applications (as you do in first year), and we thought... actually, why not?

So we built ReelJobs. It takes job listings and turns them into 15-30 second video summaries you can swipe through. The pipeline was the fun part: Gemini writes the script, Fish.audio does text-to-speech, and FFmpeg composites it all together with karaoke-style captions. We also added semantic search so you could type something like "remote Python jobs at startups" and get actual matches. We won DeltaHacks with it!

Project Reality

Zero preparation. We just brought in a couple cameras and 3D-printed some mounts. We had a projector but figured everything out on the day. And this is the coolest project I've ever made. Won Best Overall at MasseyHacks with it.

Virtual reality projected into real space. You throw real balls at a projected game, and the cameras track them with stereoscopic vision. Just watch the video, you'll love it.

We also built a mask demo where the projector maps visuals onto a physical mask. The stereo rig was janky looking, but it worked. Here, look.

Jarvis Lite

Wave your hands in the air and control any screen. You know how Tony Stark waves his hands and controls holographic displays? That's what we built at Hack the North.

We had two cameras, each running MediaPipe for hand gesture recognition. Each camera spots your hand, and we match the joint positions between the two views to figure out where your hand is in 3D space. We made custom gestures so you could click, scroll, move the cursor, all by waving your hand around in mid-air.

The best moment was during our demo for the judges. We brought everything we needed into this tiny room... except the remote that controls the projector. So the projector was on, but stuck on its home screen. Couldn't get HDMI from the laptop. A little awkward. But thinking quick, I said, "You know what, let's try it on my laptop screen instead." We pointed the cameras at the laptop, ran the ArUco calibration (which we had never tested in this setup; we'd always been on the projector), and it just worked. Perfectly. The cursor moved exactly where it should. That's the kind of robustness you hope for but never expect.

ArcadeFSE

I built an arcade with three games. My favorite was chess: a chess engine in Python. Expectations were low, but it ended up searching hundreds of thousands of positions per second and playing surprisingly well. Well enough to beat me, at least, though my friends who actually knew chess made quick work of it. I implemented all the rules and game logic from scratch. Learned a ton about minimax, alpha-beta pruning, iterative deepening, and heuristic design.

I used the same core logic for Connect 4. Since Connect 4 is a much easier game, the bot destroyed pretty much everybody. It hadn't fully solved it; if you played against an actual perfect Connect 4 solver, my bot would still lose. But it was pretty good.

And Pac-Man. I didn't really have any care for Pac-Man, but one of my friends had done Pac-Man, and I just wanted to one-up him. So I made that in a couple days and just added it to the thing.

2AK-Bot

You know you did something right when they have to rewrite the rulebook because of you. ;)

We made a Mars Rover with a gripper and arm that moves around and cameras on it. Won Best Overall at MasseyHacks. It was the kind of project you'd normally spend a month on, but we got it done in a day. My first real all-nighter. No cheating though: we followed the rules, we just came way more prepared than anyone else. They actually changed the hackathon rules after that.

EventSheet

Looking back, I definitely should have started moving off of spreadsheets at this point, but it's really easy to stick with what you know. I've since learned to push past that. Anyway, I used to play Hypixel Skyblock a lot and was interested in becoming very rich in it. The best methods were all about trading, so I made a spreadsheet for it. The first versions were usable but very hard-coded.

I used them, made lots of money, and actually sold some versions. Then people said, "Hey, you should redo this but better, and I would pay real money for it." See, I was just selling it for in-game coins. So I did. Versions 1.1, 1.2, 1.3, 1.4, and finally 1.5, the magnum opus. It had almost all the well-known money-making methods, plus some obscure ones I'd discovered myself. Lots of in-game coins were made, and on version 1.5, some real money too. But it's a spreadsheet. You're not making thousands. It was just a couple hundred.

It's really hard to make a spreadsheet into a webapp. The user needs to input data, and there's no easy way to do that without giving them access to ruin the whole thing. My workaround was to have two linked spreadsheets that share data. One of them imports data from another where the user has edit access, and the other one (which the user looks at for information) they only have view access. You could easily swap out the input sheet, and the data sheet stays safe.

Also, you may be wondering how you're getting live data from this game using a spreadsheet? Well, let me tell you, this spreadsheet had a backend. Yep, that's right. I had a Python script running on my computer 24/7, updating a master sheet. It would write to the cells, and all spreadsheets of this project would import data from that other master spreadsheet and filter and do whatever with it based on the user's inputs. What a time.

Eventy

There are way too many events at Waterloo, and manually adding everything to Google Calendar got old fast. So I built Eventy as a personal tool to scan pages and turn them into calendar-ready events.

The biggest thing I learned was that sending entire pages straight to an LLM is usually a bad move. It costs more, runs slower, and can miss obvious details. I started doing a preprocessing pass first so the model sees the useful parts, plus table rows converted into structured snippets when schedules are buried in messy markup.

From there, I used structured output for the event fields, handled timezone conversion, and wired the extension flow so it feels stable in normal use: clear scan states, caching, and a quick upcoming vs past review before adding events. It started as something I made for myself, but I kept polishing it, and now it has dozens of users.

Bomb Party Helper

My friends and I started playing Bomb Party. It's a game where you're given a sequence of letters and have to write a word that contains that sequence. You know, if a computer has a dictionary and it knows those letters, it could do pretty well! So I made a helper and posted it on GreasyFork. It has like 500+ downloads. Pretty cool... I never expected that to be popular!

TalkingML

I watched Andrej Karpathy's zero-to-hero series and thought, there should be more stuff like that. Resources that actually start from scratch and build up to the hard stuff instead of hand-waving through it. So my friend and I started writing our own.

It's also just a way to force myself to actually learn things properly. If I have to explain gradient boosting clearly enough for a blog post, I actually have to understand it. That's the first one I'm working on: decision trees and tree-based models.