DEV Community: Harsh Pandhe

Building a Custom Autonomous Drone Stack - Part 3: The Zero-Velocity Hover

Harsh Pandhe — Thu, 25 Jun 2026 01:33:00 +0000

Surviving GPS-Denied Environments with `VELOCITY_MASK`

If you're flying a micro-UAV indoors using only an optical flow sensor and a downward-facing LiDAR, standard autonomous flight commands will quickly disappoint you.

When you issue a traditional MAV_CMD_NAV_TAKEOFF, ArduPilot expects to have access to global position information. Without GPS, the navigation stack may refuse to move.

To work around this, we bypassed the higher-level navigation controller and injected raw MAVLink commands over serial using set_attitude_target_send(). This allowed the drone to climb using only its onboard sensors.

Getting airborne, however, is only half the battle.

Keeping the drone in the air is where things get interesting.

The "Zero-Throttle Drop" Trap

During our first tethered test flights, we managed to climb to roughly one meter in GUIDED mode.

To command a stable hover, we switched the vehicle into LOITER.

The instant the mode changed, the motors slowed down and the drone dropped.

What happened?

The issue wasn't hardware.

It was a software conflict.

GUIDED mode is completely autonomous and ignores pilot stick inputs.

LOITER, on the other hand, is a hybrid mode.

As soon as the flight controller entered LOITER, it checked the RC transmitter.

Our throttle stick was resting at zero.

ArduPilot interpreted that as a pilot command to descend.

The Pure Autonomy Fix: `VELOCITY_MASK`

Instead of relying on physical joysticks, we stayed entirely inside GUIDED mode and continuously sent a zero-velocity command.

Using set_position_target_local_ned_send(), we can specify a bitmask that tells the Pixhawk exactly which fields matter.

A mask value of 3527 (0b110111000111) means:

Ignore position coordinates
Ignore acceleration
Ignore yaw
Enforce X, Y, and Z velocity

By commanding:

Vx = 0
Vy = 0
Vz = 0

we are effectively telling the flight controller:

Hold perfectly still.

Velocity Hold Loop

VELOCITY_MASK = 3527

# Maintain hover for 10 seconds
for i in range(20):

    master.mav.set_position_target_local_ned_send(
        0,
        master.target_system,
        master.target_component,
        mavutil.mavlink.MAV_FRAME_LOCAL_NED,

        VELOCITY_MASK,

        0, 0, 0,     # Position (ignored)
        0, 0, 0,     # Velocity = 0 m/s
        0, 0, 0,     # Acceleration (ignored)
        0, 0         # Yaw and yaw rate (ignored)
    )

    time.sleep(0.5)

With this loop running, optical flow measurements continuously feed the EKF3.

If the drone drifts due to airflow or frame vibrations, the Pixhawk automatically adjusts motor outputs to force the physical velocity back toward zero.

Why Velocity Commands Work Better Than Position Commands Indoors

Position commands assume absolute position knowledge.

Indoors, position estimates often drift.

Velocity control is far more forgiving.

Instead of saying:

Be exactly at coordinate X=0.52 meters.

we say:

Maintain zero velocity.

This lets the flight controller use optical flow and LiDAR to make tiny corrections without fighting an imperfect global reference frame.

The Panic Button

Never fly without an emergency failsafe.

If your Python script crashes unexpectedly while the vehicle remains armed, the drone will continue executing the last command it received.

That's a bad day.

We wrapped the entire flight sequence inside an emergency interceptor.

Emergency Landing Function

import sys

def emergency_land():

    print("\n[!!!] EMERGENCY: INITIATING LAND")

    mode_id = master.mode_mapping()['LAND']

    master.mav.set_mode_send(
        master.target_system,
        mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED,
        mode_id
    )

    master.mav.command_long_send(
        master.target_system,
        master.target_component,
        mavutil.mavlink.MAV_CMD_NAV_LAND,
        0,
        0, 0, 0, 0, 0, 0, 0
    )

    sys.exit(0)

Wrapping the Flight Loop

try:

    # 1. Arm

    # 2. Takeoff

    # 3. Velocity hold

    pass

except KeyboardInterrupt:

    emergency_land()

except Exception as e:

    print(f"ERROR: {e}")

    emergency_land()

Now, pressing Ctrl+C immediately overrides the current mission and forces a controlled descent.

The flight controller handles the landing sequence and disarms automatically after touchdown.

Final Thoughts

One of the biggest lessons we learned was this:

Separate high-level logic from low-level reflexes.

Let your companion computer make decisions.

Let the flight controller do what it does best:

Sensor fusion
State estimation
Motor control
Stabilization
Recovery

By respecting this separation, you can build an autonomous stack that remains reliable even in GPS-denied environments.

And that's exactly what robotics is all about.

Not replacing the flight controller.

Working with it.

Building a Custom Autonomous Drone Stack - Part 2: Defeating the Safety Engine

Harsh Pandhe — Tue, 23 Jun 2026 13:30:00 +0000

Stop Using `time.sleep()`. Start Polling the EKF3 State Machine.

Writing a Python script to tell a drone to "Take Off" is easy.

Getting the drone to actually listen to you is the hard part.

Flight controllers are designed to be extremely paranoid. When you tell ArduPilot to arm the motors in an autonomous mode like GUIDED, it runs an extensive internal safety checklist. If it isn't completely confident in its sensors, it will silently reject your command.

The "Dumb Timer" Trap

When developers first start automating drones, their scripts usually look something like this:

# Tell the drone to arm
master.mav.command_long_send(
    ..., MAV_CMD_COMPONENT_ARM_DISARM, 1
)

time.sleep(3)  # Hope it armed...

# Tell the drone to take off
master.mav.command_long_send(
    ..., MAV_CMD_NAV_TAKEOFF, ...
)

This is the Dumb Timer Trap.

If the Pixhawk rejected the arming command because the optical flow camera couldn't see the floor properly (PreArm: Need Position Estimate), your Python script has no idea.

It waits three seconds, assumes everything worked, and blindly sends a takeoff command while the drone sits motionless on the table.

Active Polling: Reading the Pixhawk's Mind

To build a reliable autonomous stack, your code must actively interrogate the flight controller.

Instead of guessing, we continuously listen for the formal COMMAND_ACK response.

Here's how to properly arm a drone:

master.mav.command_long_send(
    master.target_system,
    master.target_component,
    mavutil.mavlink.MAV_CMD_COMPONENT_ARM_DISARM,
    0,
    1,
    0, 0, 0, 0, 0, 0
)

armed_successfully = False
start_time = time.time()

# Listen for 5 seconds
while time.time() - start_time < 5.0:
    msg = master.recv_match(
        type=['STATUSTEXT', 'COMMAND_ACK'],
        blocking=False
    )

    if msg:

        if msg.get_type() == 'STATUSTEXT':
            print(f"[PIXHAWK STATUS]: {msg.text}")

        elif (
            msg.get_type() == 'COMMAND_ACK'
            and msg.command ==
            mavutil.mavlink.MAV_CMD_COMPONENT_ARM_DISARM
        ):

            if msg.result == 0:
                print("--> Pixhawk accepted arming!")
                armed_successfully = True
                break

            else:
                print(
                    f"--> Pixhawk rejected arming! "
                    f"(Error Code: {msg.result})"
                )
                break

if not armed_successfully:
    print("\n[!!!] Flight aborted.")
    sys.exit(1)

Let the Flight Controller Tell You What's Wrong

By listening to the STATUSTEXT packets, your terminal will display the exact reason why the Pixhawk refuses to fly.

Examples include:

PreArm: Need Position Estimate
PreArm: Gyros inconsistent
PreArm: GPS 1: Bad fix
PreArm: Battery below minimum voltage

This one loop can save you hundreds of hours of hardware debugging.

The 32-Bit Overflow Bug

Once we finally got the drone armed, we started sending raw MAVLink thrust commands.

The instant the thrust command executed, Python crashed with:

struct.error:
'I' format requires 0 <= number <= 4294967295

At first glance, this error makes absolutely no sense.

What happened?

Understanding `time_boot_ms`

Many MAVLink messages require a parameter called:

time_boot_ms

Internally, this field is defined as an unsigned 32-bit integer (uint32_t).

Its maximum value is:

4,294,967,295

Our code looked like this:

int(time.time() * 1000)

Unfortunately, time.time() returns the Unix epoch timestamp.

Today, that's roughly:

1,700,000,000,000 milliseconds

Python then tried to cram a 1.7 trillion millisecond timestamp into a field that can only hold 4.29 billion.

The MAVLink packet serializer immediately overflowed and crashed.

The Fix

The flight controller doesn't care about global Unix time.

It only cares about elapsed time since your script started.

Anchor a start time:

SCRIPT_START_TIME = time.time()

Then calculate the delta:

def get_time_boot_ms():
    return int(
        (time.time() - SCRIPT_START_TIME) * 1000
    )

This guarantees that the value always fits inside a 32-bit integer.

Final Thoughts

The biggest lesson we learned was this:

Never assume the drone did what you asked.

Always wait for confirmation.

Always inspect COMMAND_ACK.

Always monitor STATUSTEXT.

And never use time.sleep() as a substitute for state feedback.

In robotics, assumptions become bugs.

Bugs become crashes.

Crashes become broken propellers.

Up Next

In Part 3, we'll tackle one of the most frustrating problems in indoor flight:

The Zero-Throttle Drop

We'll explore:

Why drones suddenly fall after takeoff
Why thrust values don't behave linearly
How to achieve a stable indoor hover without GPS
Raw MAVLink thrust control
Tuning for smooth altitude hold

Stay tuned.

Building a Custom Autonomous Drone Stack - Part 1: The Black Box Flight Recorder

Harsh Pandhe — Mon, 22 Jun 2026 20:27:25 +0000

Why We Ditched MAVROS for Raw PyMAVLink and systemd

If you're building an autonomous UAV, MAVROS is the undisputed industry standard for bridging a companion computer (like a Raspberry Pi or Jetson Nano) to your flight controller (like a Pixhawk). It wraps the MAVLink serial protocol into the ROS ecosystem. For most projects, it's the perfect tool.

But what if you're building a micro-UAV for a strictly GPS-denied environment?

What if your Raspberry Pi needs every ounce of CPU and RAM to run heavy, tightly-coupled LiDAR SLAM algorithms like FAST-LIO?

During the development of our autonomous drone stack, we hit a massive computational bottleneck. We simply couldn't afford to burn precious CPU cycles and deal with middleware overhead just to log telemetry.

We needed a zero-latency "Black Box" flight recorder. It needed to capture Optical Flow drift, Barometer altitude, CPU load, and frame vibrations at a strict 10 Hz frequency so we could mathematically verify stability before autonomous flight.

Our solution?

We bypassed ROS and MAVROS entirely for the telemetry layer and went straight to the metal using raw pymavlink over a blazing 921600 baud serial connection.

The PyMAVLink Interceptor

Instead of wrestling with ROS nodes, topic publishers, and XML configurations, we wrote a lightweight procedural Python script. It opens a direct UART connection to the Pixhawk, intercepts the binary MAVLink stream, and logs only the data we care about directly into a CSV file.

One important detail: flight controllers won't continuously spam data unless you explicitly ask them to.

1. Connect to the Pixhawk 6C

import time
import csv
from pymavlink import mavutil

PORT = "/dev/ttyAMA0"
BAUD = 921600

print(f"Connecting to Pixhawk on {PORT} at {BAUD} baud...")
master = mavutil.mavlink_connection(PORT, baud=BAUD)

We use a 921600 baud rate to avoid bottlenecking the telemetry stream.

2. Wait for the First Heartbeat

master.wait_heartbeat()
print(f"Connected! Target System: {master.target_system}")

This guarantees the Pixhawk is fully booted and speaking MAVLink before we continue.

3. Request All Data Streams at 10 Hz

master.mav.request_data_stream_send(
    master.target_system,
    master.target_component,
    mavutil.mavlink.MAV_DATA_STREAM_ALL,
    10,
    1
)

MAV_DATA_STREAM_ALL tells ArduPilot to actively send telemetry rather than waiting for individual requests.

The Async Logging Loop

By sending request_data_stream_send(), we tell the Pixhawk to start continuously flooding the serial port with MAVLink packets.

Different messages arrive at different frequencies:

Attitude → 50 Hz
Battery Status → 1 Hz
Optical Flow → varies

Writing directly to CSV every time a packet arrives would create inconsistent rows.

Instead, we maintain a state dictionary, continuously update it, and snapshot it every 0.1 seconds.

Simplified Logging Loop

state = {
    "Alt": 0.0,
    "Flow_X": 0.0,
    "Flow_Y": 0.0,
    "Quality": 0
}

last_write = time.time()

while True:
    msg = master.recv_match(blocking=True, timeout=0.1)

    if not msg:
        continue

    msg_type = msg.get_type()

    if msg_type == "VFR_HUD":
        state["Alt"] = msg.alt

    elif msg_type == "OPTICAL_FLOW":
        state["Flow_X"] = msg.flow_comp_m_x
        state["Flow_Y"] = msg.flow_comp_m_y
        state["Quality"] = msg.quality

    if time.time() - last_write >= 0.1:
        write_to_csv(state)
        last_write = time.time()

This keeps all asynchronous packets synchronized into a single telemetry snapshot.

The systemd Autopilot

A flight recorder is useless if:

You forget to start it before takeoff.
You need to SSH into the drone after every battery swap.
The script crashes mid-flight.

To make the logger production-ready, we wrapped it inside a Linux systemd service.

Unlike cron or rc.local, systemd automatically:

Starts the logger when the Raspberry Pi boots.
Restarts it if it crashes.
Runs silently in the background.

Create `/etc/systemd/system/drone_blackbox.service`

[Unit]
Description=Autonomous Drone Black Box Flight Recorder
After=multi-user.target network.target

[Service]
User=pi
WorkingDirectory=/home/pi/drone_project
ExecStart=/usr/bin/python3 /home/pi/drone_project/drone_blackbox.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable the Service

sudo systemctl daemon-reload
sudo systemctl enable drone_blackbox.service
sudo systemctl start drone_blackbox.service

Your Raspberry Pi is now a professional-grade auto-starting telemetry recorder.

🚨 The Serial Port "Gotcha"

Suppose your logger is already running in the background and you launch another Python script for autonomous takeoff.

Linux will throw:

serial.serialutil.SerialException:
device reports readiness to read but returned no data
(device disconnected or multiple access on port)

A hardware serial port can only be owned by one process at a time.

Option 1

Stop the logger temporarily:

sudo systemctl stop drone_blackbox.service

Option 2

Use a MAVLink router like MAVProxy to split one physical serial connection into multiple virtual UDP ports.

Final Thoughts

By ditching ROS and MAVROS for telemetry logging, we achieved:

Lower CPU overhead
Near-zero latency
Deterministic 10 Hz logging
Automatic startup with systemd
Improved reliability during indoor autonomous flights

Sometimes the best architecture isn't adding another layer of abstraction.

Sometimes it's removing one.

Up Next

Logging data is easy.

Making the drone fly itself is hard.

In Part 2 of this series, we'll explore:

Autonomous takeoff without GPS
ArduPilot's EKF3 safety engine
State polling and pre-arm checks
Safe operation in GPS-denied environments
The realities of indoor autonomous flight

Stay tuned.

Why I’m Learning Blender to Build Better Autonomous Systems 🚀

Harsh Pandhe — Tue, 12 May 2026 10:54:04 +0000

For robotics engineers, simulation environments are just as important as the code running inside the robot.

As developers, we often spend our lives inside:

terminals
IDEs
Jupyter notebooks

Our world is built from:

logic
loops
APIs
data structures

But while working on Project ASCEND, I eventually hit a major wall:

The Environment Problem.

How do you properly test drone navigation logic without crashing a real-world prototype every five minutes?

The answer lies in:

Digital Twins
High-fidelity simulations
Synthetic environments

So instead of relying on stock assets, I recently started building my own Martian simulation sandbox in Blender.

🚀 The Goal: A Stylized Martian Testbed

I didn’t need a perfect 1:1 replica of Mars.

I needed an environment that was:

Computationally Efficient

Low-poly assets that wouldn’t destroy frame rates during simulation runs.

Efficient rendering matters when:

testing SLAM pipelines
running reinforcement learning
generating synthetic datasets
simulating autonomous agents

Geometrically Challenging

I intentionally added:

vertical pillars
jagged rocks
uneven terrain
debris shards

to stress-test:

obstacle avoidance
path planning
depth estimation

A "perfect" environment teaches robots nothing.

Edge cases do.

Visually Consistent

I also optimized the environment for:

visual odometry
depth perception
feature tracking

using:

high-contrast lighting
exaggerated shadows
strong silhouettes

because perception systems depend heavily on environmental consistency.

🛠 The Learning Curve: From Python to Poly-Editing

Coming from a pure programming background, Blender initially felt like an alien spacecraft dashboard.

But eventually something clicked:

3D environments are just structured data.

Vertices.

Normals.

Meshes.

Transforms.

Once I started viewing Blender as an environment-generation engine instead of an art tool, the learning process became much easier.

My Workflow

Low-Poly Modeling

I used simple primitives like:

Cylinders
Ico-spheres
Planes

combined with Blender’s Decimate Modifier to achieve a stylized low-poly aesthetic.

This helped keep scenes lightweight while still visually readable.

Procedural Terrain Displacement

Using noise textures and displacement modifiers, I warped flat geometry into:

dunes
cliffs
rocky terrain

This created a more natural Martian landscape without manually sculpting every surface.

Lighting the Red Planet

Mars has a very distinct visual feel.

To mimic that, I used:

a single directional sun lamp
warm orange/red tones
sharp shadow contrast
higher light intensity

The result looked stylized, but also became useful for testing perception systems under harsh lighting conditions.

Camera Rigging

To simulate drone flyovers consistently, I created camera rigs using:

Bezier curves
Follow Path constraints

This allowed repeatable trajectories for testing navigation and visual tracking algorithms.

Repeatability is critical when debugging autonomous systems.

📈 Iteration: v1 → v3

In software engineering, we iterate on features.

In simulation engineering, we iterate on environmental complexity.

v1

The first version was extremely simple:

flat terrain
a few cylinders
minimal obstacles

Good enough for proof-of-concept testing.

But far too easy for navigation systems.

v3 (Current Version)

The latest environment includes:

varied terrain elevation
debris shards
complex shadows
irregular obstacle geometry
varied rock sizes

These additions introduced realistic edge cases:

Does the drone mistake a shard for a landing hazard?
Do shadows confuse depth estimation?
Can obstacle avoidance handle narrow passages?

By building the world myself, I can intentionally inject test cases directly into the environment.

💡 Engineering Takeaway

Learning Blender isn’t just about creating cool visuals.

For robotics and AI engineers, it’s about:

simulation
synthetic data generation
digital twins
environment control

If I can build a scene in Blender, I can generate:

thousands of labeled images
synthetic training datasets
depth maps
segmentation masks
navigation scenarios

for machine learning systems.

That’s incredibly powerful.

Why This Matters for Autonomous Systems

Real-world robotics is expensive.

Simulation allows us to:

fail safely
iterate faster
scale testing
generate data cheaply

The better your simulated environments become, the more robust your real-world systems become.

Simulation isn’t a side tool anymore.

It’s part of the core engineering stack.

Final Thoughts

Project ASCEND is slowly teaching me that modern robotics engineers need to think beyond code.

We’re no longer just writing algorithms.

We’re building:

environments
datasets
simulations
digital ecosystems

And tools like Blender are becoming surprisingly important in that workflow.

Discussion

For those working in:

robotics
simulation
game engines
AI systems

what does your simulation stack look like?

Do you use:

Blender?
Gazebo?
Isaac Sim?
Unreal Engine?
Unity?

And how much effort do you invest into your environments compared to your actual autonomous logic?

I’d genuinely love to hear how other engineers approach simulation-first development.

Architecting for Trust: Building a Multi-Role Admin Platform with React and Express

Harsh Pandhe — Fri, 08 May 2026 16:52:59 +0000

How I designed a secure multi-role admin platform with JWT authentication, layered authorization, and role-specific workflows for Project Morpheus.

When building an admin tool like Project Morpheus, the biggest security threat usually isn’t an external hacker.

It’s Privilege Escalation.

In a system with four distinct roles:

Admin
Warden
Auditor
Desk Operator

how do you ensure that a desk volunteer can’t accidentally—or intentionally—delete audit logs or modify hostel configurations?

Here’s how I architected a robust Role-Based Access Control (RBAC) system using React and Express.

1. The "Single Point of Truth" Authentication Model

The foundation of the architecture is JWT-based authentication.

When a user logs in, the backend issues a signed token containing:

userId
role
hostelId (for Warden accounts)

This token is stored in the browser and sent with every API request through the Authorization header.

Authorization: Bearer <jwt_token>

The hostelId field allows wardens to be automatically restricted to their assigned building.

This became the foundation for permission-aware APIs and role-specific dashboards.

2. The Hybrid API: Performance Meets Portability

I wanted the platform to work seamlessly in:

Local development
Cloud/serverless deployments

So I used a Hybrid Express + Serverless Architecture.

Local Development

A central Express server.js handles:

Routing
Middleware
JWT validation
Local API orchestration

Production Deployment

Each route is structured as an independent serverless function:

/api/teams/verify.js
/api/hostels/allocate.js
/api/audit/logs.js

This approach gave me:

Better modularity
Easier debugging
Isolated feature testing
Cloud portability

without maintaining two different codebases.

3. Defense in Depth: The "Double Lock" Strategy

One of the most common security mistakes in frontend-heavy applications is:

Protecting only the UI.

Hiding buttons in React does not secure your system.

Anyone with:

Postman
curl
browser devtools

can still hit your APIs directly.

So Morpheus uses a Two-Layer Guard Architecture.

Layer 1: Frontend Route Guards (UX Protection)

In React, I implemented a wrapper component that validates roles before rendering routes.

const ProtectedRoute = ({ allowedRoles, children }) => {
  const { user } = useAuth();

  if (!allowedRoles.includes(user.role)) {
    return <Navigate to="/unauthorized" />;
  }

  return children;
};

This ensures:

Wardens never see admin settings
Desk operators never access audit tools
Auditors only see verification workflows

The frontend becomes cleaner and less error-prone.

Layer 2: Backend Middleware (Real Security)

Every API route is wrapped in authorization middleware.

Even if someone bypasses the UI, the server validates:

JWT authenticity
User role
Permission level
Resource ownership

before processing the request.

Example:

if (req.user.role !== "Admin") {
  return res.status(403).json({
    error: "Access denied"
  });
}

This creates true defense-in-depth security.

4. Designing for Specific Roles

One of the most impactful decisions in Morpheus was making the interface adapt to the user’s identity.

Different users think differently.

So the UI itself changes depending on the role.

The Desk Operator

Their workflow is optimized for:

Speed
Search
Verification

They need to:

Find teams instantly
Search by phone number or ID
Verify attendance rapidly

Minimal distractions.

Maximum efficiency.

The Warden

Their workflow is visual.

They need:

Occupancy heatmaps
Room status visibility
Floor-level overview dashboards

Instead of forms, they interact with live hostel state.

The Auditor

Auditors care about process integrity.

Their interface is workflow-oriented:

Step-by-step validation
Approval pipelines
Verification checkpoints
Historical records

They don’t need dashboards.

They need structured operational flows.

5. Key Architecture Takeaways

Building Morpheus taught me several important engineering lessons.

Never Trust the Client

Always verify permissions on the backend.

Frontend validation improves UX.

Backend validation provides security.

You need both.

Modular APIs Scale Better

Small domain-focused handlers are easier to:

Test
Maintain
Secure
Deploy independently

Context is King

Using:

React Context
Custom Hooks
Global Auth Providers

allowed me to avoid painful prop-drilling across deeply nested dashboards.

Security Is Also About Preventing Mistakes

One of the biggest realizations during this project was:

Security isn’t just about stopping attackers.

It’s also about designing systems that prevent normal users from making catastrophic mistakes.

Good architecture guides users toward safe behavior by default.

That matters just as much as encryption and middleware.

Final Thoughts

Building Project Morpheus pushed me to think beyond CRUD applications and into operational system design.

Once you introduce:

Multiple roles
Real-world workflows
Permissions
Auditability
Physical asset management

your application becomes less about pages and more about trust boundaries.

And designing those trust boundaries correctly is where backend architecture becomes truly interesting.

Discussion

How would you design RBAC in a large-scale operational platform?

Would you use:

Attribute-Based Access Control (ABAC)?
Policy Engines like OPA?
Role hierarchies?
Permission matrices?
Microservice authorization gateways?

I’d love to hear how other engineers approach multi-role security systems.

The "Double-Booking" Nightmare: Building a Rule-Driven Hostel Allocator with MongoDB Transactions

Harsh Pandhe — Thu, 07 May 2026 11:51:33 +0000

How I built a transactional hostel allocation engine that eliminates race conditions and double-bookings using MongoDB sessions.

Handling logistics for a 500+ person event—like a major hackathon or campus festival—is easy on paper.

It becomes significantly harder at 2:00 AM when multiple exhausted teams arrive at the registration desk simultaneously while operators manually juggle room assignments.

In this article, I’m pulling back the curtain on the "brain" of Project Morpheus: a transactional allocation engine designed to handle complex accommodation logic without risking data corruption or double-bookings.

1. The Challenge: Why CRUD Isn’t Enough

When most people think of a Hostel Management System, they imagine a basic CRUD application.

But in high-concurrency environments—where multiple operators may click Allocate at the exact same moment—traditional CRUD logic introduces dangerous race conditions.

The "Overbooking" Scenario

Operator A queries for the next available bed.
The database responds:

Room 101, Bed A is free.

Operator B performs the same query simultaneously.
The database again responds:

Room 101, Bed A is free.

Both operators hit Confirm.

Result?

The same physical bed gets assigned twice.

I’ve seen this happen in real operational environments, and I decided that Project Morpheus would move the complexity from the operator’s brain into the system itself.

2. The Morpheus Solution: Rule-Driven Automation

The allocator doesn’t randomly assign rooms.

It follows a strict hierarchy of business rules modeled after real-world campus accommodation systems.

The "Golden Rules" of Allocation

1. Gender Segregation

This is the most critical rule.

Male participants → Devgiri or Raigad
Female participants → Godavari

2. The Verification Gate

To prevent ghost bookings and spreadsheet inconsistencies:

A team cannot be allocated unless every member has been verified at the registration desk.

This includes:

ID verification
Physical presence confirmation
Attendance validation

3. Team Integrity

The allocator prioritizes keeping teams:

In the same room
Or in adjacent rooms

It avoids splitting teams across multiple floors unless absolutely necessary.

4. Sequential Optimization

To simplify operations for wardens and housekeeping staff, rooms are filled in a deterministic order:

Block → Room → Bed

3. Technical Deep-Dive: The Transactional Sequence

In Project Morpheus, an allocation request is treated as an:

Atomic Unit of Work

Meaning:

Either every database operation succeeds
Or the entire request rolls back safely

This guarantees consistency even during crashes or network failures.

Step 1: Concurrency Check

The allocator first performs an atomic validation.

if (team.isAllocated) {
  throw new Error("Team already allocated");
}

This prevents:

Double-click allocation issues
Duplicate operator requests
Multiple transaction executions

Step 2: Gender-Specific Scouting

The engine separates members by gender and searches eligible hostel blocks.

const availableBeds = await db.collection('hostels').aggregate([
  { $match: { gender: teamGender } },
  { $unwind: "$rooms" },
  { $unwind: "$rooms.beds" },
  { $match: { "rooms.beds.isOccupied": false } },
  { $limit: memberCount }
]).toArray();

This dynamically finds:

Empty beds
Nearby room availability
Contiguous placements for teams

Step 3: The "Big Write" (MongoDB Transaction)

Using MongoDB sessions, the allocator wraps all mutations into a single transaction.

Inside the transaction:

1. Generate Allocation Records

Create accommodation records for every participant.

This becomes the system’s:

Source of Truth

for room mapping.

2. Update Hostel State

Selected beds are marked as occupied using MongoDB positional operators.

$[ ]

3. Update Team Metadata

isAllocated: true

Why Transactions Matter

Imagine this scenario:

Accommodation slips are printed
The server crashes before hostel state updates
The database still believes those beds are empty

Without transactions:

Duplicate allocations become possible
Database consistency breaks
Physical occupancy mismatches system state

With MongoDB transactions:

Everything commits together
Or everything rolls back safely

4. Operational Impact: From 5 Minutes to 2 Seconds

Before Project Morpheus:

Manual room hunting
Spreadsheet coordination
Warden communication over calls
~5 minutes per team allocation

After automation:

Metric	Before	After
Allocation Time	~5 mins	~2.5 sec
Double Bookings	Frequent Risk	Impossible
Manual Coordination	Heavy	Minimal
Slip Generation	Manual	Automatic

Real-World Results

Zero Double-Bookings

The transactional lock mechanism makes over-allocation mathematically impossible.

Massive Efficiency

Allocation now takes:

~2.5 seconds per team

regardless of team size.

Clean Operational Hand-Offs

The system instantly generates:

Printable accommodation slips
Accurate hostel mappings
Verified room assignments

Students receive the exact data stored in the database.

5. Key Takeaway for Developers

The biggest lesson I learned while building the Morpheus allocator:

Consistency matters more than speed in operational systems.

When software manages physical assets—beds, inventory, seats, reservations—it’s always better to have:

Slightly slower
Transaction-heavy
Fully consistent operations

than ultra-fast systems that corrupt data under load.

Designing for the "2:00 AM Scenario"

Good backend systems are not designed for ideal conditions.

They are designed for:

Failures
Concurrency
Human mistakes
Crashes
Unpredictable operational pressure

If your system can survive 2:00 AM chaos, it can survive production.

Final Thoughts

Building Project Morpheus taught me that backend engineering is less about writing APIs and more about designing reliable systems under pressure.

Handling concurrency correctly is what separates:

Demo projects

from

Production-grade infrastructure.

Discussion

How would you design this allocator differently?

Would you use:

Redis distributed locks?
PostgreSQL row-level locking?
Event sourcing?
Queue-based allocation?
Optimistic concurrency control?

I’d genuinely love to hear production-grade approaches from other backend engineers.

GitHub Bootcamp: Day 5 – Contributing to Open Source Like a Pro 🧑‍💻🌍

Harsh Pandhe — Thu, 22 May 2025 18:30:00 +0000

Welcome to the final day of our GitHub crash course! Today’s topic is a favorite among devs and job recruiters alike — Open Source Contributions.

Yes, it sounds intimidating. But trust me — you don’t need to be a 10x developer or a command-line wizard to contribute meaningfully. Let’s break it down!

🌱 Why Contribute to Open Source?

Learn by doing – Hands-on experience beats theory any day.
Build your portfolio – Real-world code > tutorial projects.
Grow your network – Meet collaborators, mentors, and friends.
Give back to the community – Many of the tools you use daily are open source!

🔍 How to Find Projects to Contribute To

💡 Start here:

Good First Issue – Curated list of beginner-friendly issues
Up-for-Grabs
First Contributions Repo
Explore trending repos on GitHub – Look under the “issues” tab for low-hanging fruit.

✅ What Can You Contribute?

You don’t need to refactor the entire codebase. Open source thrives on small, meaningful contributions. Examples:

Fixing typos in documentation
Improving README files
Updating dependencies
Fixing bugs
Adding tests
Suggesting features
Reviewing other people’s PRs

🛠️ How to Make a Contribution (The Friendly Way)

Fork the repo 🍴
Creates your own copy where you can make changes.
Clone it locally

   git clone https://github.com/your-username/project-name.git

Create a new branch

   git checkout -b fix-typo

Make your changes & commit

   git add .
   git commit -m "Fix typo in README"

Push to your fork

   git push origin fix-typo

Open a Pull Request (PR)

Explain what you did clearly.
Be polite and open to feedback!

💬 Pro Tips for Contributing

Read the Contributing.md file if available.
Follow code style guidelines of the project.
Engage positively in issue discussions.
Be patient — maintainers are often volunteers!

🚀 Bonus: Hacktoberfest

Every October, GitHub and DigitalOcean host Hacktoberfest, where contributing to open source earns you swag, stickers, and GitHub street cred. Perfect for beginners!

🏁 That’s a Wrap!

You just finished a 5-day journey covering:

What is GitHub
Setting up GitHub & Git
Branching and Collaboration
GitHub Actions for Automation
Open Source Contributions

Whether you're building solo or contributing globally, GitHub is your dev playground.

GitHub Series: Day 4 – Automate Like a Boss with GitHub Actions 🤖⚙️

Harsh Pandhe — Wed, 21 May 2025 18:30:00 +0000

Welcome back, developers! Yesterday, we learned how to branch and merge like Git ninjas. Today, we’re going full automation mode with GitHub Actions — your new best friend for building, testing, and deploying code without lifting a finger (well, almost 😎).

🧠 What are GitHub Actions?

Imagine having a robot that checks your code, runs tests, deploys apps, makes you coffee (okay, not that last one… yet) — all triggered by events like pushing to a branch or opening a pull request.
That’s GitHub Actions. It's a powerful CI/CD (Continuous Integration / Continuous Deployment) system built right into GitHub.

🔥 Why Use GitHub Actions?

✅ Automate repetitive tasks
🧪 Run tests every time code is pushed
🚀 Deploy apps automatically
📦 Build and publish packages
🤝 Boost collaboration with teams

🛠️ Setting Up Your First GitHub Action

Here’s how to build a simple GitHub Action that runs tests when code is pushed:

1. Create a workflow file

Inside your repo, make this folder:

.github/workflows/

Then create a file like ci.yml.

2. Add this starter config:

name: Run Python Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

And boom — your tests will now run automatically whenever you push code!

🚦 Common Use Cases

Use Case	Trigger	Example
Linting	`on: push`	Auto-check code style (e.g., with ESLint or Black)
Deployment	`on: push to main`	Deploy app to Vercel, Heroku, Netlify, etc.
Notifications	`on: issues`	Send Slack or Discord alerts
Testing	`on: pull_request`	Run unit tests before merging

🧩 Pro Tip: Use Actions from the Marketplace

Why reinvent the wheel? Head over to GitHub Marketplace and use thousands of pre-built actions.

Examples:

actions/checkout → Pulls repo code
actions/setup-node → Sets up Node.js
docker/build-push-action → Builds & pushes Docker images

💡 Best Practices

✅ Keep workflows small and focused
🔁 Use reusable workflows to avoid duplication
🧪 Run tests before deploying
⏱️ Don’t trigger workflows on every tiny change — be specific with paths and branches

🚀 Conclusion

GitHub Actions is your personal DevOps assistant. Whether you're solo-building a portfolio site or working in a team on a massive app, automation will save your time and sanity.

Tomorrow?

We’ll wrap this series with something close to every developer’s heart — Open Source Contributions 💖
How to find cool projects, make meaningful PRs, and become a contributor!

GitHub Bootcamp: Day 3 - Branching and Merging Like a Pro

Harsh Pandhe — Tue, 20 May 2025 18:30:00 +0000

Welcome to Day 3 of our GitHub series! Today we're diving into branching and merging—the secret sauce behind collaborative development. If GitHub was a movie, branches would be the plot twists, and merges would be the dramatic reunions. Let's get into it!

🌐 What is a Branch?

A branch in Git is like a sandbox where you can work on changes without affecting the main (production) version of your code.

Imagine you're writing a novel. Your main branch is the final version, but you want to try out an alternate ending. Instead of rewriting everything, you create a branch called alternate-ending and work there. Genius, right?

🔄 Creating a Branch

git branch feature-cool-button

🚀 Switching to Your Branch

git checkout feature-cool-button

git switch feature-cool-button

Now you're in your own bubble. Make changes, commit them, and live your best dev life.

✨ Merging: The Reunion Episode

Once you’re happy with your changes in a branch, it’s time to bring them back into the main branch. That’s merging.

🔐 First, Switch to Main

git checkout main

🔄 Merge Your Branch

git merge feature-cool-button

Boom! Your changes are now part of the main storyline.

⚠️ What About Merge Conflicts?

Sometimes Git gets confused if the same part of a file has been changed in both branches. It’ll raise a merge conflict and ask you to resolve it.

Don't panic.

Git will mark the conflicts in the file.
You decide which version to keep.
After editing, mark the conflict as resolved:

git add conflicted-file.js
git commit

🎓 Pro Tips

Name your branches clearly: bugfix-login-issue, feature-dark-mode.
Always pull latest changes before you merge.
Use git log --graph to visualize branches.
Use git status to stay aware of what’s going on.

🤖 Pull Requests: Collaborate the GitHub Way

If you're working with a team or contributing to open source, don’t just merge directly. Open a pull request on GitHub.

Why?

It allows others to review your code.
You can discuss changes before merging.
Ensures cleaner, safer code.

🌟 Summary

Branching and merging are powerful tools for working independently without chaos. Master these, and you’re halfway to becoming a Git wizard.

Coming Up: Day 4 - GitHub Actions ✨

Next, we’ll explore how to automate workflows and save time with GitHub Actions. Get ready for some dev magic!

#GitHub #Git #VersionControl #GitTips #CodeCollaboration #OpenSource

GitHub Bootcamp: Day 2 - Setting Up GitHub

Harsh Pandhe — Mon, 19 May 2025 18:30:00 +0000

Welcome to Day 2 of our 5-day GitHub series! Today we’re setting up GitHub, the digital garage where developers store, collaborate on, and show off their code. If GitHub were a superhero, it’d be Batman: mysterious, powerful, and full of cool gadgets (like Actions and Pull Requests). Let's get you set up and ready to push code like a pro.

Step 1: Create a GitHub Account

Go to github.com and hit Sign up

Pick a memorable username (bonus points for geeky puns).
Add your email and a strong password.
Choose your plan (the free one is plenty to get started).

You're officially a GitHubber now. 🎉

Step 2: Create Your First Repository

A repository (or “repo”) is where your project lives—kind of like a folder, but cooler.

How to Create a Repo:

Click the + icon on the top-right → New repository.
Give it a name like awesome-project.
Add a description (optional but classy).
Choose public (anyone can see) or private (for your eyes only).
Check “Initialize this repository with a README” if you want to add one.
Click Create repository.

Boom. Your project home is ready.

Step 3: Install Git Locally

To push code from your computer to GitHub, you’ll need Git installed.

Install Git:

Windows: Download Git
macOS: Use Homebrew → brew install git
Linux: Use your package manager → sudo apt install git (for Debian/Ubuntu)

Configure Git:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

This tells Git who you are (like a signature on your code).

Step 4: Push Your Code to GitHub

Let’s say you created a project on your computer called hello-github.

Push it to GitHub:

cd hello-github
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/yourusername/hello-github.git
git push -u origin main

And boom 💥 your code is now live on GitHub!

GitHub UI Tips for Beginners

README.md: A welcome message for your repo. Make it fun and informative.
Commits Tab: Shows your code history like a time-travel diary.
Branches: Parallel universes for your code. We’ll talk more tomorrow!

Bonus: Learn Git Basics

Here are a few must-know Git commands:

Command	Description
`git status`	Check what’s going on
`git add .`	Stage all changes
`git commit -m "message"`	Save changes
`git push`	Upload changes to GitHub
`git pull`	Fetch latest code

Conclusion

Today you created a GitHub account, made a repo, and learned how to push your first code. You’re officially dangerous (in a good way).

What’s Coming Next?

Tomorrow, we dive into Branching and Merging—aka how not to break stuff while working with others. Stay tuned!

#GitHub #Git #DeveloperTools #VersionControl #OpenSource #Day2

GitHub Bootcamp: Day 1 - What is GitHub?

Harsh Pandhe — Mon, 19 May 2025 12:45:41 +0000

Welcome to Day 1 of our 5-day GitHub series! If you've ever heard developers say, "Push it to GitHub" and wondered if they meant a gym workout, you're in the right place.

What is GitHub?

GitHub is like social media for code—except instead of selfies and cat memes, you'll find commits, pull requests, and branches. It's a web-based platform built on top of Git, a version control system that helps developers track changes in their code.

TL;DR:

Git = A tool to track code changes.
GitHub = A cloud platform to store, manage, and collaborate on Git repositories.

If Git is your notebook, GitHub is your bookshelf in the cloud.

Why Use GitHub?

✨ Features & Benefits

Version Control: Never lose progress. Revert to older versions anytime.
Collaboration: Work on the same project with friends, teammates, or strangers across the globe.
Issue Tracking: Report bugs or suggest features with Issues.
Pull Requests: Review, discuss, and merge changes smoothly.
Documentation: Use README files and Wikis to explain your code.
GitHub Pages: Host static websites directly from your repo.
Community and Open Source: Find projects, contribute, or get help from fellow devs.

Real-Life Examples

Solo Developer: You’re building a personal portfolio site. GitHub tracks changes and lets you host it using GitHub Pages.
Startup Team: Your team of 5 is working on a web app. Everyone pushes code to the same repo and uses branches to prevent chaos.
Open Source Contributor: You find a bug in a cool tool. Fork the repo, fix the bug, and submit a pull request!

A Quick Glossary

Repository (Repo): A project folder tracked by Git.
Commit: A snapshot of your project at a specific time.
Branch: A parallel version of your project.
Merge: Bringing branches together.
Pull Request (PR): Proposing changes to be added to a repo.

Final Thought for Today

GitHub isn’t just for developers—it’s for creators. Writers, designers, data scientists, and more use GitHub to manage versioned work. By learning it, you’re joining a global community of builders and innovators.

What’s Next?

Tomorrow, we’ll walk you through Setting Up GitHub, creating your first repository, and mastering Git basics. No worries—we'll keep it fun, hands-on, and beginner-friendly.

Day 05: System Administration Like a Pro

Harsh Pandhe — Thu, 13 Feb 2025 18:30:00 +0000

Welcome to the final day of our Linux series! Today, we’re stepping into the shoes of a Linux System Administrator. You’ll learn how to manage users, processes, and services like a seasoned pro. Ready to level up? Let’s dive in!

What is System Administration?

System administration is all about keeping a Linux system running smoothly. It involves managing users, monitoring processes, configuring services, and ensuring everything works together harmoniously. Think of it as being the conductor of a tech orchestra.

Managing Users and Groups

1. Add a New User

Add a user with the adduser command:

sudo adduser username

Follow the prompts to set up a password and basic user info.

2. Delete a User

Remove a user with:

sudo deluser username

For a clean slate, delete their home directory too:

sudo deluser --remove-home username

3. Switch Users

Switch to another user with:

su - username

4. Manage Groups

Add a user to a group:

sudo usermod -aG groupname username

Example: Adding jane to the sudo group:

sudo usermod -aG sudo jane

Monitoring and Managing Processes

Processes are the programs running on your system. Here’s how to keep an eye on them:

1. View Running Processes

Use top to see a live list of running processes:

top

Exit with q.

Or, use ps for a snapshot:

ps aux

2. Kill a Process

Terminate a misbehaving process with its PID (Process ID):

kill PID

If it refuses to die, use:

kill -9 PID

3. Monitor System Resources

Check memory and CPU usage:

free -h

uptime

Managing Services

Linux services (a.k.a. daemons) are background processes that handle tasks like web servers, databases, and more. Here’s how to manage them:

1. Start, Stop, and Restart Services

Control services with systemctl:

sudo systemctl start servicename
sudo systemctl stop servicename
sudo systemctl restart servicename

Example: Restarting the Apache web server:

sudo systemctl restart apache2

2. Check Service Status

See if a service is running:

sudo systemctl status servicename

3. Enable and Disable Services

Enable a service to start on boot:

sudo systemctl enable servicename

Disable it:

sudo systemctl disable servicename

Scheduling Tasks with Cron

Automate repetitive tasks using Cron. Cron jobs are scheduled tasks defined in a special file called the crontab.

1. Edit the Crontab

Open the crontab editor:

crontab -e

2. Add a Cron Job

Cron jobs follow this format:

minute hour day month day_of_week command

Example: Run a backup script every day at 2 AM:

0 2 * * * /path/to/backup.sh

3. List Cron Jobs

View your scheduled tasks:

crontab -l

Backing Up Your System

Backups are a sysadmin’s best friend. Here’s a simple way to back up files and directories:

Using rsync

rsync -av /source/directory /backup/directory

Example: Back up your home directory:

rsync -av /home/username /mnt/backup

Tips and Best Practices

Keep Your System Updated: Use sudo apt update && sudo apt upgrade (or your distro’s equivalent) regularly.
Monitor Logs: Check logs for errors and anomalies. System logs are often in /var/log.
Limit Root Access: Use sudo instead of logging in as root.
Backup Regularly: Always have a backup plan.
Document Everything: Keep notes on what you configure for future reference.

Resources to Explore

Conclusion

Congratulations! You’ve completed the 5-day Linux journey. You’ve gone from learning what Linux is to mastering system administration. Whether you’re managing users, processes, or services, you now have the skills to navigate Linux like a pro.

Keep Learning

This is just the beginning. Linux is a vast and fascinating world. Keep exploring, practicing, and experimenting. The command line is your canvas—go create something amazing.

DEV Community: Harsh Pandhe

Building a Custom Autonomous Drone Stack - Part 3: The Zero-Velocity Hover

Surviving GPS-Denied Environments with VELOCITY_MASK

The "Zero-Throttle Drop" Trap

The Pure Autonomy Fix: VELOCITY_MASK

Velocity Hold Loop

Why Velocity Commands Work Better Than Position Commands Indoors

The Panic Button

Emergency Landing Function

Wrapping the Flight Loop

Final Thoughts

Building a Custom Autonomous Drone Stack - Part 2: Defeating the Safety Engine

Stop Using time.sleep(). Start Polling the EKF3 State Machine.

The "Dumb Timer" Trap

Active Polling: Reading the Pixhawk's Mind

Let the Flight Controller Tell You What's Wrong

The 32-Bit Overflow Bug

Understanding time_boot_ms

The Fix

Final Thoughts

Up Next

The Zero-Throttle Drop

Building a Custom Autonomous Drone Stack - Part 1: The Black Box Flight Recorder

Why We Ditched MAVROS for Raw PyMAVLink and systemd

The PyMAVLink Interceptor

1. Connect to the Pixhawk 6C

2. Wait for the First Heartbeat

3. Request All Data Streams at 10 Hz

The Async Logging Loop

Simplified Logging Loop

The systemd Autopilot

Create /etc/systemd/system/drone_blackbox.service

Enable the Service

🚨 The Serial Port "Gotcha"

Option 1

Option 2

Final Thoughts

Up Next

Why I’m Learning Blender to Build Better Autonomous Systems 🚀

🚀 The Goal: A Stylized Martian Testbed

Computationally Efficient

Geometrically Challenging

Visually Consistent

🛠 The Learning Curve: From Python to Poly-Editing

My Workflow

Low-Poly Modeling

Procedural Terrain Displacement

Lighting the Red Planet

Camera Rigging

📈 Iteration: v1 → v3

v1

v3 (Current Version)

💡 Engineering Takeaway

Why This Matters for Autonomous Systems

Final Thoughts

Discussion

Architecting for Trust: Building a Multi-Role Admin Platform with React and Express

1. The "Single Point of Truth" Authentication Model

2. The Hybrid API: Performance Meets Portability

Local Development

Production Deployment

3. Defense in Depth: The "Double Lock" Strategy

Layer 1: Frontend Route Guards (UX Protection)

Layer 2: Backend Middleware (Real Security)

4. Designing for Specific Roles

The Desk Operator

The Warden

The Auditor

5. Key Architecture Takeaways

Never Trust the Client

Modular APIs Scale Better

Context is King

Security Is Also About Preventing Mistakes

Final Thoughts

Discussion

The "Double-Booking" Nightmare: Building a Rule-Driven Hostel Allocator with MongoDB Transactions

1. The Challenge: Why CRUD Isn’t Enough

The "Overbooking" Scenario

2. The Morpheus Solution: Rule-Driven Automation

The "Golden Rules" of Allocation

Surviving GPS-Denied Environments with `VELOCITY_MASK`

The Pure Autonomy Fix: `VELOCITY_MASK`

Stop Using `time.sleep()`. Start Polling the EKF3 State Machine.

Understanding `time_boot_ms`

Create `/etc/systemd/system/drone_blackbox.service`