Every day, millions of tons of waste are produced worldwide. Most of it ends up in landfills, much of it recyclable, and some even biodegradable. The problem isn’t just the waste—it’s the sorting. Traditional methods of waste management rely heavily on human labor: tedious, error-prone, and often inefficient. And that’s where our project began.

We wanted to build something that could make waste classification faster, smarter, and—most importantly—automatic.

The Beginning: Choosing the Dataset

Our journey started with the Real Waste Dataset from UCI, a collection of 4,752 images divided into 9 waste categories:

• Cardboard – 461 images

• Food Organics – 411 images

• Glass – 420 images

• Metal – 790 images

• Miscellaneous Trash – 495 images

• Paper – 500 images

• Plastic – 921 images

• Textile Trash – 318 images

• Vegetation – 436 images

Each image measured 524 × 524 pixels with 3 RGB channels, which meant our neural networks had to process high-dimensional data. Before feeding the dataset into the models, we standard-scaled it to ensure faster convergence during training.

The Metrics that Mattered

We didn’t want just accuracy—we wanted a balanced picture.

So, we evaluated our models using:

• Categorical Cross-Entropy Loss: to measure how far our predictions were from reality.

• F1 Score: the harmonic mean of precision and recall, ensuring we weren’t just good at some classes while failing miserably at others.

The Experiments: Building & Training Models

We split the dataset: 80% for training and 20% for validation. Then came the real grind—training not one, but four different CNN architectures:

1. Custom CNN (Our Own Model)

   • Built from scratch.

   • Served as a baseline for comparison.

2. VGG 19

   • A deep, well-known architecture, but surprisingly under-explored in Kaggle waste classification notebooks.

3. Inception V3

   • Transfer learning with a twist:

     • First, we trained only the top layer for 10 epochs.

     • Then, we fine-tuned by unfreezing some of the pre-trained layers and continuing for another 10 epochswith a reduced learning rate.

4. MobileNets V1.0

   • Lightweight, fast, and efficient.

   • Also, not previously explored in Kaggle notebooks for this dataset.

To make our models smarter, we added:

• Step Learning Rate Scheduling – dynamically adjusting the learning rate during training.

• Model Checkpoints – automatically saving the best-performing weights whenever the validation loss improved.

All models were trained using the Adamax optimizer with CrossEntropy loss.

The Results: Which Model Won?

After weeks of experimentation, here’s how the models stacked up:

The clear winner was Inception V3, achieving the highest F1-score. But there was a catch: it was also the slowest model. On the other hand, MobileNets V1.0 delivered an impressive balance—high accuracy with significantly faster performance, thanks to its depthwise separable convolution layers.

What We Learned

In the end, our project proved that deep learning can dramatically improve waste classification. While Inception V3shined in accuracy, MobileNets V1.0 showed us that speed and efficiency can’t be overlooked—especially if such a system is ever to be deployed in real-world recycling plants.

This wasn’t just an experiment—it was a step toward rethinking how technology can tackle one of the world’s oldest problems: trash.

The Team Behind the Work

• Amish Faldu (af557)

• Sneh Vora (sv992)

• Palak Pabani (pp872)

Want to Explore More?

• 📂 Dataset: UCI Real Waste Dataset

• 💻 Code: Google Drive Repository

• 🎥 Project Video: Link

👉 This is just the beginning. Imagine a world where waste bins have eyes—powered by AI—to sort your trash for you. That’s not science fiction anymore. It’s where we’re headed.

But the path wasn’t glamorous from day one.

The Chaos Before the Order

When I joined in August 2021, the challenge was clear: data was everywhere, but value was nowhere. We had fragmented CSVs, incomplete logs, and cloud data scattered across multiple systems. Analysts spent hours just wrangling files before even thinking about modeling.

That’s when I decided to start with ETL pipelines. Using Python, Pandas, and SQLAlchemy, I stitched together workflows that could not only ingest raw data but also transform and clean it on the fly. To scale, I leaned on AWS S3, Lambda, and RDS, automating ingestion so data flowed like a stream instead of arriving as a trickle.

What used to take hours of manual work turned into an automated system that ran in minutes.

Teaching Machines to Learn

With the data foundation set, I shifted focus to the real fun: machine learning models.

I spent weeks building supervised learning models with scikit-learn, experimenting with everything from regression to ensemble methods. Then came the deep learning phase, where PyTorch became my closest ally. Every late-night training run felt like pushing boundaries—tuning hyperparameters, debugging exploding gradients, and finally watching the validation accuracy climb.

But training models is one thing. Delivering them to users is another.

Breaking Out of the Notebook

To make our models useful, I deployed them as RESTful APIs using Flask and FastAPI. Suddenly, predictions weren’t locked in my Jupyter notebook—they were accessible to downstream applications in real-time.

To scale, I containerized everything with Docker and leveraged AWS ECS, Lambda, and EC2. Now, no matter how big the workload grew, the system could adapt without missing a beat.

This was the moment I realized: true ML engineering isn’t just about models—it’s about building systems that last.

Watching in Real-Time

One of my proudest contributions was implementing monitoring and logging. Models aren’t perfect, and neither is data. By setting up real-time dashboards, we could track model performance, drift, and data quality as they happened. Instead of reacting to failures weeks later, we were catching issues in real-time.

That’s how machine learning truly becomes reliable.

What I Learned

Over those 18 months, I didn’t just grow as an engineer—I grew as a systems thinker. I learned that:

• Data pipelines are the silent backbone of every AI project.

• A model in a notebook isn’t a solution until it’s deployed and consumed.

• Monitoring and iteration are what keep ML alive in production.

At the end of the day, I wasn’t just building code—I was building trust in data-driven decisions.

Closing Thought

Machine learning can feel like magic from the outside. But behind the curtain, it’s about solving real problems, one pipeline, one model, and one API at a time.

And that’s exactly what I set out to do at Aarav Solutions—turning messy data into actionable intelligence, and experiments into production systems that made a difference.

Github Link : Multi-Agent Reinforcement Learning (MultiCarRacing-v0)

It started with frustration, not inspiration.

I was deep into my machine learning coursework, scrolling through Kaggle competitions and research papers, when I noticed a common theme: most reinforcement learning (RL) tutorials stop at Atari games. Pong, Breakout, maybe CartPole if you’re lucky.

Cool examples, sure—but they didn’t feel real.

I wanted something messy, dynamic, and closer to the real world. Something where the agent couldn’t just memorize screen pixels but actually had to react, adapt, and survive.

That’s when I found the CarRacing environment.

Why Racing Cars?

Car racing is chaotic and unforgiving. Every turn is a test:

• Brake too late, and you’re off the track.

• Accelerate too much, and you spin out.

• Turn too little, and you never finish the lap.

It perfectly embodies what makes RL so powerful—learning to make a sequence of split-second decisions under uncertainty.

This was the challenge I wanted to tackle:
👉 Could I train AI agents, using RL, to learn racing strategies without any rules handed to them?

Setting Up the Track

I worked with two environments:

• Single-agent mode (CarRacing-v2, Gymnasium): One car, one brain, grayscale vision.

• Multi-agent mode (custom repo): Two cars racing on the same track, each acting independently.

If single-agent racing was about teaching one car to survive, multi-agent racing felt more like refereeing a duel.

When I first put two cars on the same track, something strange happened: either they both crawled along cautiously (to avoid penalties) or they crashed headlong into chaos. Clearly, they needed better incentives.

So I reshaped the reward system to act like a race official:

• ⏱️ Time Penalty: Every frame cost them -0.1 points. No stalling at the start line.

• 🏆 Progress Reward:

  • The leading car earned +1000/N per tile.

  • The trailing car earned +500/N per tile.
    (Where N is the total track length in tiles.)
    This way, both cars stayed motivated, but the leader always had an edge—just like in real racing.

• 🚫 Off-Track Penalty: Going off track meant -100 points. A harsh but necessary rule to keep driving clean.

The result? The cars stopped loafing around and started racing. One would pull ahead, the other would chase, and both learned that the only way forward was—literally—forward.

Models in the Pit Stop

I tested two core RL approaches:

1️⃣ Deep Q-Networks (DQN)

• Good for discrete actions.

• Pixel inputs → CNN → action-value estimation.

• I even experimented with ResNet transfer learning and LSTM-ResNet hybrids.

2️⃣ Proximal Policy Optimization (PPO)

• A policy-gradient method.

• More stable learning curves.

• Tried it in single-agent setups for comparison.

Race Results 🏁

• Single-agent DQN: After ~2.5M steps (15 hours CPU training), the agent achieved ~800 average reward—right in line with published results.

• Single-agent PPO: Smoother early learning (~500 reward), but plateaued.

• Multi-agent DQN: After ~52 hours, both cars learned reasonable policies (~400 reward each), but sometimes “fought” over track tiles instead of racing efficiently.

Lessons From the Track

• Representation is everything: Frame stacking gave agents memory of momentum.

• Algorithms trade off differently: DQN is efficient but unstable; PPO is steady but weaker.

• Multi-agent is messy: Independent learners don’t naturally cooperate—you have to design incentives.

The Roadblocks

• Q-value instability → fixed with replay buffers + target networks.

• Long CPU training → I had to optimize every preprocessing step.

• Reward tuning → a balancing act between punishment and encouragement.

Why This Matters Beyond Racing

What I learned here isn’t just about cars in a simulator.

This applies to any system where decisions must be made in real time under uncertainty:

• Autonomous vehicles avoiding crashes.

• Robotics navigating dynamic warehouses.

• Logistics systems optimizing deliveries and routes.

Reinforcement learning gives machines the ability to adapt, not just follow pre-coded instructions.

And racing, for me, was the perfect playground to test those limits.

Github Link : Legal-AI-For-Bankruptcy-Cases

The Problem That Hooked Me

Bankruptcy law isn’t just about numbers on a balance sheet—it’s a maze of case law, filings, motions, and obscure legal jargon.

When I first started exploring this domain, I noticed how time-consuming it was for legal professionals to manually sift through lengthy documents just to extract relevant precedents. Unlike other industries, legal text is unforgiving—if you miss context, you risk making the wrong judgment.

That’s when the idea hit me:
👉 What if I could build an AI that retrieves the right legal passages and generates answers like a seasoned paralegal—fast, reliable, and context-aware?

From Frustration to Framework

At first, I naively thought: “Throw GPT at it, and we’re done.”
But reality humbled me. A generic LLM struggled—it hallucinated, mixed up precedents, and ignored nuanced legal definitions. In law, “close enough” is the same as wrong.

So, I turned to Retrieval-Augmented Generation (RAG).

Instead of relying on a model’s memory, I designed a system where the AI could:

1. Search legal documents (via Pinecone 🌲 for vector search)

2. Rank passages by relevance (thanks to Cohere 🔍)

3. Generate nuanced responses (with Cohere, Ollama, and Gemini ✨)

4. Orchestrate workflows (using LangGraph 🧩 for state management)

What I Actually Built

The result is what I call Legal AI for Bankruptcy Cases.

It’s not just another chatbot—it’s a multi-component system:

• Streamlit UI for an intuitive interface.

• Poetry-managed dependencies so devs can spin it up cleanly.

• Pinecone + Cohere + Ollama + Gemini powering retrieval and generation.

• LangGraph to manage complex legal workflow states.

• XML handling for parsing structured legal files.

Why This Matters

Bankruptcy law affects everything from small businesses to global corporations. A system like this isn’t replacing lawyers—but it’s amplifying their ability to find relevant information instantly. Think of it as a turbocharged research assistant that never sleeps.

Lessons Learned (the hard way)

• Legal data is messy—parsing and indexing documents took longer than I expected.

• RAG is powerful, but state management (via LangGraph) was the real unlock to making workflows consistent.

• AI isn’t about replacing expertise—it’s about scaling it.

What’s Next

I see this project as a foundation. The legal AI ecosystem is still in its infancy, and the potential is massive. Bankruptcy is just one domain; imagine extending this to contracts, compliance, or litigation prep.

If you’re a legal professional, ML engineer, or just curious about where AI meets law—you’ll want to keep an eye on this space.

🔗 Full repo here: Legal-AI-For-Bankruptcy-Cases

💬 Got thoughts? Hit reply or drop me a message. I’d love to hear how you see AI reshaping law.

When I first started working on WordPress projects back in 2021, I quickly realized that running a website isn’t just about writing great content—it’s about keeping it fresh, optimized, and consistent.

But here’s the catch: most of the time wasn’t spent on creativity. Instead, it was wasted on repetitive admin tasks—uploading posts, cleaning up drafts, tweaking SEO settings, checking plagiarism, or simply copy-pasting news articles from trusted sources. By the end of the day, it felt less like content management and more like content babysitting.

That frustration gave birth to WPInsight Automator.

The Problem That Sparked the Idea

While helping with a WordPress project at CHARUSAT (Charotar University of Science and Technology), I noticed a recurring pattern:

• Fetching trending news from sites like NDTV or Hindustan Times.

• Paraphrasing and rewriting them to avoid duplication.

• Uploading them manually into WordPress with proper formatting, categories, and SEO tags.

• Running plagiarism checks to ensure originality.

• Repeating this cycle for multiple posts every single day.

It was tedious, time-consuming, and error-prone. And if you missed a day? The site instantly felt outdated.

I knew there had to be a better way.

The Vision

I wanted to design a system that could:

1. Extract news automatically from trusted sources.

2. Rephrase it intelligently using NLP so it wouldn’t be a direct copy.

3. Upload and manage posts on WordPress with minimal human input.

4. Run SEO checks so the content was not just uploaded, but also optimized.

In short: an AI-powered assistant that could save 80% of the manual work.

Enter WPInsight Automator 🚀

This wasn’t just a script—it was a complete workflow automation bot. Here’s what it could do:

✨ Key Features

• News Extraction → Automated scraping from Hindustan Times and NDTV.

• AI Paraphrasing → Leveraging Transformers and PyTorch for context-aware rewriting.

• WordPress Task Automation → Uploading, deleting, updating, and managing posts with Selenium.

• Plagiarism Check → Ensuring originality before publishing.

• SEO Integration → Automatic compatibility with Rank Math SEO plugin.

• File & Content Management → Uploading media, handling drafts, and cleaning up clutter.

The Tech Behind It

I combined traditional automation with modern NLP:

• Selenium → For interacting with WordPress like a human admin.

• Transformers + PyTorch → For paraphrasing and NLP-based rephrasing.

• NumPy & Math → For handling data and backend calculations.

• MySQL → To store extracted content and metadata.

• Tkinter → For a simple GUI to make the tool usable by non-technical users.

• smtplib → For sending automated email alerts when new posts were ready.

It wasn’t fancy at first—just a bunch of scripts strung together. But once it clicked, the efficiency boost was undeniable.

Lessons Learned

1. Automation ≠ Magic
   Every scraper breaks at some point. I learned the importance of making my pipeline modular so I could fix or swap out components easily.

2. AI Needs Guardrails
   NLP paraphrasing isn’t perfect. Without plagiarism checks, it occasionally produced results too close to the source. Building fallback mechanisms taught me the importance of balancing automation with quality control.

3. UX Matters, Even for Bots
   At first, WPInsight Automator was command-line only. Adding a Tkinter-based GUI made it usable for non-developers, which was a turning point.

Why This Still Matters

Even though this project dates back to 2021, the core idea resonates today:

• AI + Automation can unlock huge productivity gains.

• Content workflows, especially in digital publishing, are still ripe for optimization.

• Building small, targeted tools can sometimes make a bigger impact than large, bloated solutions.

For me, WPInsight Automator wasn’t just about WordPress—it was my entry point into blending machine learning, automation, and real-world usability.

And the best part? That spark of solving an everyday pain point has fueled every project I’ve worked on since.

👉 Curious to see the code? The full project is available here: WPInsight Automator on GitHub

If you’ve ever felt trapped by repetitive digital tasks, maybe it’s time to build your own automation story.

Github Link : Smart Inventory Bot

Why I Built the Smart Inventory Bot?

It all started when I got curious about my uncle’s warehouse business.

Walking through the aisles, I noticed the same challenge that plagues so many small-to-mid-sized operations: the data existed, but the insights didn’t.

He had mountains of transaction records—sales, discounts, returns, seasonal demand shifts—but whenever I asked him a simple business question like “What’s the average discount on electronics versus clothing last year?” his answer was always the same:

“I’ll need to check with the accountant.”

That struck me. Why should everyday business owners need a technical degree—or an expensive analyst—just to get insights from their own data?

That was the seed for what became the Smart Inventory Bot.

The Problem I Saw

Databases are great at storing information, but terrible at talking to humans.
On the other hand, humans are great at asking questions, but not everyone speaks SQL.

So, the gap is clear:

• Business owners have questions in plain English.

• The answers are locked in relational databases.

My goal was to build a bridge.

The Vision

Imagine asking a bot in natural language—
“Show me the average discount by product category for 2023”—
and instantly hearing back:

🗣️ “Electronics: 15%, Clothing: 10%, Home Goods: 5%.”

No code. No dashboards. No “let me get back to you.”

That’s what I wanted to bring to life with Smart Inventory Bot.

Under the Hood

The bot works like a translator between humans and data.

1️⃣ Understanding the Question
At its core is a StateGraph, which decides where each query should go:

• SQL path → if the question is data-specific.

• LLM path → if the question is more conversational or abstract.

2️⃣ Getting the Answer
Two engines power the response:

• SQL Generator: Converts natural language into SQL queries on the fly.

• LLM Responder: Handles edge cases, explanations, or questions outside the database.

3️⃣ Resilient by Design
No bot is perfect, but Smart Inventory Bot doesn’t just fail silently.
It has an error-handling path that reroutes failed queries, ensuring the user always gets some response.

What Surprised Me

The first time I asked it,
“What’s the average discount on electronics last year?”
and it not only wrote the SQL, ran it, and gave me the result in plain English…

…I had that spark every engineer knows. The “it actually works” moment.

That’s when I realized this isn’t just a student project. This is a tool small businesses could actually use to make data-driven decisions without hiring a full analytics team.

Why It Matters

Warehouse owners like my uncle shouldn’t need to spend hours poring over spreadsheets.
Data should talk back, in the same language we use every day.

Smart Inventory Bot isn’t perfect yet—it’s a prototype—but it’s a glimpse of how natural language + structured data can empower everyday decision-making.

And that’s why I built it.

At BVM Infotech, I focused on building scalable backend infrastructure using Flask, enabling reliable and efficient server-side solutions for high-traffic applications.

Key Contributions:

• 🔧 Backend Development: Built Flask-based REST APIs, delivering scalable, modular, and maintainable server-side applications.

• 📊 Data Handling: Implemented efficient data management pipelines, ensuring integrity and smooth flow of information.

• 🔗 API Integration: Connected third-party services, including payment gateways, SMS APIs, and notification systems, to provide seamless user experiences.

• 🖥️ Server Logic & Optimization: Enhanced server response times by 35% through optimized SQL queries and caching strategies, reducing database load and boosting scalability.

Skills & Tools: Flask · REST APIs · SQL · API Integration · Database Optimization · Caching · CSS

This internship strengthened my foundation in backend engineering and gave me hands-on experience in delivering production-grade APIs that balanced efficiency, scalability, and real-world usability. 🌟👨‍💻

Key Contributions:

• 🔍 Multi-Platform Product Comparison: Designed workflows to compare items across different online stores, giving users a unified view of prices and availability.

• 🌐 Web Scraping & Automation: Implemented scraping pipelines to automatically extract real-time product data. Set up automated scripts to update the database with the latest information, minimizing manual effort.

• 🔗 Affiliate Integration: Integrated affiliate links to direct users to the best deals seamlessly.

• 🗄️ Database Management: Built and maintained a structured database that kept product information fresh and accurate.

Skills & Tools: Web Scraping · Database Management · Automation · Data Pipelines

This project sharpened my technical skills while showing me how automation can transform user experiences in e-commerce by ensuring efficiency, accuracy, and accessibility. 🌟📈

It all started with a simple question that kept nagging at me: What do people really feel when they post on Twitter?

In the whirlwind of digital conversations, Twitter has always fascinated me. Millions of people drop their thoughts every second—sometimes raw, sometimes witty, sometimes brutally honest. But beneath the chaos of hashtags, emojis, and abbreviations, I sensed a pattern. A hidden pulse.

And I wanted to capture it.

That curiosity became the seed of my research paper: “Twitter Sentiment Analysis using TextBlob” (IJISRT, 2022).

Why Twitter?

When I began, I could have chosen Instagram, Facebook, or even Reddit. But Twitter stood out because of its brevity. Each tweet forces the user to compress their feelings into 280 characters. It’s like a stream of distilled human emotion—short, sharp, and surprisingly revealing.

For an ML engineer, that’s both a gift and a challenge.

The gift? Massive volumes of text-based interactions, perfect for analysis.
The challenge? Tweets are messy. Really messy.

The Early Struggles

I still remember my first dataset. It was a jungle.

• Links to half-broken websites.

• Random emojis.

• Retweet markers.

• And let’s not even talk about the spelling errors.

Running my first scripts felt like staring into static on an old TV screen. I had data, sure—but no clarity.

That’s when I realized: before I could even think about machine learning, I had to get serious about cleaning.

I spent hours designing preprocessing steps: stripping URLs, normalizing text, removing stop words, and handling special characters. It felt less like data science and more like archaeology—scraping away dirt to reveal the artifact hidden beneath.

Building the Framework

Once the noise was cleared, I turned to the heart of the project: sentiment analysis.

I didn’t start with deep neural networks or transformer models. Instead, I wanted to prove that a simple, accessible tool could still uncover powerful insights.

Enter TextBlob.

With its Pythonic simplicity, TextBlob let me classify tweets as positive, negative, or neutral. To some, it might seem too basic compared to today’s BERT or GPT-powered systems—but that was the beauty of it. The framework was lean, efficient, and approachable.

And soon enough, the results started pouring in.

What the Data Whispered

The first time I visualized the sentiment distribution, it felt like watching a living heartbeat of the crowd. Suddenly, the noise had shape.

• I could see sentiment trends shifting around events.

• Brands rising and falling in public favor.

• Collective moods reacting in real-time to global happenings.

This wasn’t just data—it was public opinion, quantified.

The Limitations I Faced

Of course, I had my fair share of frustrations:

• Language support: TextBlob only handled English. Every non-English tweet was a lost voice.

• Shallow classification: Some sarcasm or cultural nuance simply slipped through.

• Comparisons with advanced models: SVMs, LSTMs, and transformers promised higher accuracy, but I chose clarity and speed over complexity—for this paper at least.

But every limitation also planted a seed for future work.

Lessons Learned

Writing this paper wasn’t just about publishing—it was about learning.

I discovered that the hardest part of ML isn’t always the model—it’s the data.
I learned how crucial it is to design with clarity, not just sophistication.
And most importantly, I realized that even simple approaches can have real impact when applied thoughtfully.

Where I’d Take It Next

If I were to extend this research today, I’d explore:

• Multilingual sentiment analysis to capture a truly global voice.

• Transformer-based models like BERT or RoBERTa for deeper contextual understanding.

• Real-time dashboards to let businesses visualize and act on sentiment as it unfolds.

The journey started with TextBlob, but it certainly doesn’t end there.

Closing Thoughts

Looking back, what began as a fascination with Twitter became a full-fledged research project that taught me more than I ever expected.

At its core, the paper was my attempt to decode the human voice—compressed into characters, hashtags, and emojis—and translate it into something organizations and individuals alike could understand.

And in that process, I realized something powerful: data doesn’t just tell us what happened. It tells us how we feel.

That’s the story of my paper, and honestly, the story of why I fell in love with machine learning in the first place.