Jianlin Ye | RSS Feed

A Topology-Aware Spatiotemporal Handover Framework for Continuous Multi-UAV Tracking

hello@jye.bio — Tue, 14 Jul 2026 00:00:00 GMT

Authors: Jianlin Ye, Christos Kyrkou, Panayiotis Kolios

Venue: 2026 International Conference on Unmanned Aircraft Systems (ICUAS)

Location: Corfu, Greece

Pages:

Publisher: IEEE

DOI:

Abstract

The integration of Unmanned Aerial Vehicles (UAVs) into Intelligent Transportation Systems (ITS) offers synoptic visibility for traffic monitoring, yet scalable deployment is hindered by trajectory fragmentation, where vehicle identity persistence is lost across multi-UAV Fields of View (FOV). While state-of-the-art frameworks excel in optimizing local trajectory extraction and stability for single-drone imagery, they often function as isolated data silos that generate disjointed trajectories, thereby precluding network-level analysis such as Origin-Destination estimation. This paper presents a real-time Multi-Camera Multi-Vehicle Tracking (MCMT) system designed to handle global identity persistence. Addressing the visual ambiguity and computational cost of appearance-based Re-Identification (Re-ID) in nadir views, we introduce a lightweight Topology-Based Spatiotemporal Handover mechanism. We implement a high-throughput parallel pipeline leveraging YOLO11 and ByteTrack to process concurrent 4K streams. Our core contribution is a deterministic queue-based matching algorithm that utilizes geometric overlaps and virtual lane discretization to predictively manage identity handover via FIFO queues. Experimental results on complex urban environments, including intersections and merging traffic, demonstrate a Handover Success Rate (HOSR) of 99.8% in continuous traffic flows, significantly outperforming Re-ID baselines (74.1%) while validating edge deployment feasibility. The source code is available at https://github.com/JYe9/multi-camera-multi-vehicle-tracking-system.

BibTeX

A Review of Vision-based Vehicle Detection for UAV-based Traffic Monitoring: Experimental Insights and Future Directions

hello@jye.bio — Tue, 21 Apr 2026 00:00:00 GMT

Authors: Jianlin Ye, Christos Kyrkou

Venue: IEEE Transactions on Intelligent Transportation Systems (T-ITS)

Location:

Pages:

Publisher: IEEE

DOI:

Abstract

In Intelligent Transportation System (ITS), unmanned aerial vehicle (UAV)-based surveillance offers an innovative solution to traffic surveillance with wide coverage and real-time data collection capabilities. In comparison to fixed ground-based infrastructure, UAVs are able to respond to dynamic traffic but present challenges such as vehicle detection at varying altitudes, compensation for motion-induced image variations and efficient processing of high-resolution images. Deep learning has been largely beneficial on improving the detection accuracy; however, for practical deployment, a critical assessment of the accuracy, latency, and harmonization with current transportation systems needs to be carefully considred. This survey reviews recent advancements in the UAV-based traffic monitoring, with a primary focus being deep neural network models for traffic analytics in various urban settings. Three main challenges identified in the literature are ensuring compatibility with traffic control systems, achieving real-time processing to optimize traffic flow, and maintaining robust detection in different environmental conditions. Existing solutions often lack comprehensive frameworks for utilizing UAV captured data to respond to incidents and manage traffic effectively. Future research should focus on optimal detection models, edge processing, and adaptive control integration to improve the responsiveness of urban traffic management.

BibTeX

Deploying OpenClaw on Mac Mini: My Experience with the Hottest AI Tool of 2026

hello@jye.bio — Sun, 01 Mar 2026 00:00:00 GMT

If you've been following the AI space lately, you've probably heard of OpenClaw. With over 145,000 GitHub stars and headlines calling it "the AI that actually does things," it's become one of the most talked-about tools of 2026.

I decided to try it myself by deploying it on a Mac Mini M4. Here's what I learned.

Why OpenClaw?

Unlike typical AI chatbots that just generate text, OpenClaw is designed for automation — it can actually perform tasks on your computer. Think of it as having a digital assistant that doesn't just tell you how to do something, but actually does it for you.

The promise of running it locally was particularly appealing:

Privacy: Everything stays on your machine
No API costs: After the initial hardware investment, it's essentially free
Control: You decide what the AI can and cannot access

The Setup Journey

Setting up OpenClaw wasn't exactly plug-and-play. The installation process is technical, involving Terminal commands and configuration files.

Security First

One important principle I followed was the principle of least privilege — only giving the AI the minimum access it needs to do its job. I set up:

A dedicated guest user account for OpenClaw
A separate email account just for the AI
Admin privileges kept separate for safety

This creates a sandbox environment where OpenClaw can operate without risking your main system.

The Local Model Challenge

I initially wanted to run everything on local models — no cloud APIs, completely offline. The M4 Mac Mini should theoretically handle this, but in practice, the local models ran slower than expected.

After some experimentation, I found that using a hybrid approach (local processing with occasional API calls) provides the best balance of speed and cost.

What Makes OpenClaw Different

The real magic happens when you integrate OpenClaw with messaging apps. Through WhatsApp integration (as simple as scanning a QR code), you can text commands to your AI from anywhere.

This shift from fighting with Terminal to casually messaging your AI from the couch is when OpenClaw really clicks. It feels like having a personal assistant that:

Has persistent memory
Knows what you've been working on
Can actually execute tasks on your computer

Use Cases I'm Exploring

Here are some automation tasks I'm testing:

Research Synthesis — Having the agent collect and summarize papers and articles over time
File Organization — Automatically sorting, renaming, and backing up project files
Experiment Coordination — Scheduling tasks and pulling together data from multiple sources
Competitive Monitoring — Regular checks on developments in my research areas

Thoughts So Far

OpenClaw is like the custom motorcycle of AI assistants — it requires some tinkering to keep running smoothly, but the potential is remarkable. For researchers and engineers who spend too much time on repetitive tasks, local AI agents like this could be game-changing.

The economics of running AI locally vs. using cloud APIs is still something I'm figuring out. But the dream of having a private, local AI assistant that actually gets things done feels closer than ever.

I'll share more as I explore deeper into what OpenClaw can do.

Inspired by the growing community of people experimenting with local AI agents. The future of personal computing might just be having an AI that lives on your machine and works for you.

Building Reliable AI Agents: Architecture, Challenges, and Lessons Learned

hello@jye.bio — Sat, 28 Feb 2026 00:00:00 GMT

AI agents are everywhere right now. Every week brings a new framework, a new benchmark, and a new demo of an LLM autonomously browsing the web, writing code, or booking a flight. Most of these demos are impressive. Most of them also fall apart the moment you try to use them for something real.

This post is about what it actually takes to build AI agents that hold together beyond the demo — drawing from my work on agentic systems for software environments. I'll cover the core architecture patterns, the failure modes nobody talks about in blog posts, and the design decisions that actually matter in practice.

What Is an AI Agent, Really?

Before getting into architecture, it's worth being precise about what we mean. The term "agent" is used so loosely that it has become nearly meaningless.

For the purposes of this post, an AI agent is a system that:

Receives an objective (not just a single prompt)
Plans and executes a sequence of actions to achieve it
Observes the results of those actions
Adapts based on what it observes
Does this autonomously, without requiring human input at every step

The key word is autonomously. A chatbot that answers questions is not an agent. A system that writes code, runs it, reads the error, fixes the code, and runs it again — that's an agent.

The Core Loop

Every agent, regardless of how complex it becomes, is built around some version of this loop:

Observe → Think → Act → Observe → ...

In code, the simplest possible version looks something like this:

def run_agent(objective: str, tools: list[Tool], max_steps: int = 20):
    memory = []

    for step in range(max_steps):
        context = build_context(objective, memory)
        decision = llm.complete(context)
        action = parse_action(decision)

        if action.type == "finish":
            return action.result

        observation = action.tool.call(action.args)
        memory.append({"action": action, "observation": observation})

    raise MaxStepsExceeded("Agent did not finish within the step limit")

This is the ReAct pattern — Reason + Act — and it's the foundation of most production agent systems today.

The Tool Layer

An agent's capabilities are defined entirely by its tools. The LLM can reason about anything, but it can only do what its tools allow.

A well-designed tool interface looks like this:

from dataclasses import dataclass

@dataclass
class Tool:
    name: str
    description: str
    parameters: dict  # JSON Schema

    def call(self, **kwargs) -> str:
        raise NotImplementedError

    def to_llm_spec(self) -> dict:
        return {
            "name": self.name,
            "description": self.description,
            "parameters": self.parameters,
        }

A few things matter enormously here:

The description is your most important parameter. The LLM decides which tool to use based on the description. Vague descriptions lead to wrong tool selection. Be specific about what the tool does, what inputs it expects, and what it does not do.

Return strings, not structured data. The observation fed back into the LLM context is text. A well-formatted string that directly answers the implicit question the agent was trying to answer leads to faster, more reliable reasoning.

Handle errors gracefully. Tools will fail. The agent needs to see the error message and have a chance to recover — not crash.

class FileReadTool(Tool):
    name = "read_file"
    description = (
        "Read the contents of a file. Returns the full text content. "
        "Use this when you need to examine an existing file. "
        "Do not use this to check whether a file exists — use list_directory instead."
    )

    def call(self, path: str) -> str:
        try:
            with open(path, "r") as f:
                return f"Contents of {path}:\n\n{f.read()}"
        except FileNotFoundError:
            return f"Error: File '{path}' does not exist."
        except PermissionError:
            return f"Error: Permission denied when reading '{path}'."

Memory and Context Management

The biggest practical challenge in agent development is context management. LLMs have finite context windows, and a long-running agent will exhaust them.

There are three broad approaches:

1. Full History (Simple, Doesn't Scale)

Keep everything in the context. Works fine for short tasks. Falls apart for anything involving more than a few dozen steps.

2. Sliding Window

Keep only the last N steps. Simple to implement, but the agent can "forget" information from earlier in the task that turns out to be important.

3. Structured Memory

Maintain a separate memory store with explicit read/write operations. The agent stores important facts, retrieves them when needed, and the raw step-by-step history gets compressed or discarded.

class AgentMemory:
    def __init__(self):
        self.working_memory: list[dict] = []
        self.long_term: dict[str, str] = {}

    def add_step(self, action, observation):
        self.working_memory.append({"action": action, "observation": observation})
        if len(self.working_memory) > 20:
            self.working_memory = self.working_memory[-20:]

    def remember(self, key: str, value: str):
        self.long_term[key] = value

    def to_context(self) -> str:
        parts = []
        if self.long_term:
            parts.append("Key facts:\n" + "\n".join(
                f"- {k}: {v}" for k, v in self.long_term.items()
            ))
        parts.append("Recent steps:\n" + format_steps(self.working_memory))
        return "\n\n".join(parts)

The Failure Modes Nobody Mentions

Most agent tutorials show you the happy path. Here's what actually goes wrong.

Hallucinated Tool Calls

The LLM will occasionally call a tool with arguments that look plausible but are subtly wrong — a file path that doesn't exist, a parameter name off by one character, a value in the wrong format.

Mitigation: Validate tool inputs before execution. Return a descriptive error that tells the agent exactly what was wrong.

Getting Stuck in Loops

Without explicit loop detection, an agent will sometimes repeat the same action five times because the observation doesn't contain what it expected and it doesn't know how to proceed.

Mitigation: Track action history. If the last N actions are identical, force the agent to reconsider.

def detect_loop(memory: list[dict], window: int = 3) -> bool:
    if len(memory) < window:
        return False
    recent = [m["action"].name for m in memory[-window:]]
    return len(set(recent)) == 1

Context Poisoning

Early in the task, the agent makes a wrong assumption and records it in memory. Everything that follows is built on that assumption. The error compounds.

Mitigation: Build in explicit reflection steps. Periodically ask the agent to review its assumptions against the observations it has collected.

Scope Creep

Given a vague objective, an agent will sometimes interpret it as broadly as possible — deleting files it wasn't asked to touch, making API calls with side effects, modifying state that should have been left alone.

Mitigation: Define explicit boundaries in the system prompt. Use sandboxed tool implementations. For anything irreversible, require confirmation.

What Actually Makes an Agent Reliable

After spending significant time building and debugging these systems, the things that matter most are not what I expected.

Prompt engineering matters more than architecture. The clearest improvements came from better system prompts — more precise tool descriptions, clearer task framing, explicit instructions about handling uncertainty. Not from switching frameworks.

Simpler is more robust. A flat ReAct loop with good tools and a well-written system prompt outperforms complex multi-agent architectures on most tasks.

Failure recovery beats failure prevention. You cannot write prompts that prevent all errors. Build systems that detect when something went wrong and know how to recover.

Test with adversarial inputs. The tasks where agents fail most dramatically are edge cases and ambiguous objectives. Your evaluation suite should include these, not just clean happy-path scenarios.

Where This Is Going

The current generation of AI agents is impressive but brittle. They work well on well-defined tasks in constrained environments, and fail unpredictably when those constraints are violated.

The interesting open problems are around reliability at scale: how do you build an agent that completes complex, long-horizon tasks consistently? How do you make autonomous systems safe enough to trust with consequential actions?

These are not just engineering problems. They involve how to specify objectives precisely, how to build systems that know what they don't know, and how to maintain human oversight over systems that act faster than humans can review.

That's what I'm working on. I'll keep writing about it here as I learn more.

The Complete Guide to React Hooks

hello@jye.bio — Sat, 28 Feb 2026 00:00:00 GMT

React Hooks were introduced in React 16.8, enabling you to use state and other React features inside functional components. They fundamentally changed how we write components.

Why Hooks?

Before Hooks, if you needed to manage state or handle side effects in a component, you had to use a class component:

class Counter extends React.Component {
  state = { count: 0 }

  increment = () => {
    this.setState({ count: this.state.count + 1 })
  }

  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={this.increment}>+1</button>
      </div>
    )
  }
}

Rewritten with Hooks, the same component becomes far more concise:

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
    </div>
  )
}

useState

useState is the most fundamental Hook — it lets you add local state to a functional component.

const [state, setState] = useState(initialValue)

Basic Usage

function LoginForm() {
  const [username, setUsername] = useState('')
  const [password, setPassword] = useState('')

  const handleSubmit = (e) => {
    e.preventDefault()
    console.log({ username, password })
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={username}
        onChange={(e) => setUsername(e.target.value)}
        placeholder="Username"
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="Password"
      />
      <button type="submit">Log in</button>
    </form>
  )
}

Managing Multiple Fields with an Object

When you have many fields, group them into a single state object:

function ProfileForm() {
  const [form, setForm] = useState({
    name: '',
    email: '',
    bio: '',
  })

  const handleChange = (field) => (e) => {
    setForm((prev) => ({ ...prev, [field]: e.target.value }))
  }

  return (
    <form>
      <input value={form.name} onChange={handleChange('name')} />
      <input value={form.email} onChange={handleChange('email')} />
      <textarea value={form.bio} onChange={handleChange('bio')} />
    </form>
  )
}

Note: Unlike setState in class components, the useState setter does not automatically merge objects — you need to spread ...prev manually.

useEffect

useEffect handles side effects such as data fetching, event subscriptions, and DOM manipulation.

useEffect(() => {
  // side effect logic

  return () => {
    // cleanup function (optional)
  }
}, [dependencies])

Data Fetching

function UserProfile({ userId }) {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    let cancelled = false

    async function fetchUser() {
      setLoading(true)
      const res = await fetch(`/api/users/${userId}`)
      const data = await res.json()

      if (!cancelled) {
        setUser(data)
        setLoading(false)
      }
    }

    fetchUser()

    return () => {
      cancelled = true
    }
  }, [userId])

  if (loading) return <p>Loading...</p>
  if (!user) return <p>User not found</p>

  return <div>{user.name}</div>
}

The Three Forms of the Dependency Array

Form	Behavior
No second argument	Runs after every render
`[]` empty array	Runs once on mount only
`[a, b]`	Runs when `a` or `b` changes

useContext

useContext lets you read a React Context value directly, without threading props through every layer of the tree.

Building a Theme Toggle

1. Define the Context:

// ThemeContext.js
import { createContext, useContext, useState } from 'react'

const ThemeContext = createContext()

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light')

  const toggleTheme = () => {
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'))
  }

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  )
}

export function useTheme() {
  return useContext(ThemeContext)
}

2. Consume it in any component:

function Header() {
  const { theme, toggleTheme } = useTheme()

  return (
    <header className={`header header--${theme}`}>
      <button onClick={toggleTheme}>
        Switch to {theme === 'light' ? 'dark' : 'light'} mode
      </button>
    </header>
  )
}

useRef

useRef has two main uses: accessing DOM elements directly, and storing a mutable value that does not trigger a re-render when it changes.

function VideoPlayer() {
  const videoRef = useRef(null)

  return (
    <div>
      <video ref={videoRef} src="/video.mp4" />
      <button onClick={() => videoRef.current.play()}>Play</button>
      <button onClick={() => videoRef.current.pause()}>Pause</button>
    </div>
  )
}

Custom Hooks

Custom Hooks are one of the most powerful features in React — extract reusable stateful logic into a standalone function and share it across multiple components.

useFetch

function useFetch(url) {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(null)

  useEffect(() => {
    let cancelled = false

    async function fetchData() {
      try {
        setLoading(true)
        const res = await fetch(url)
        if (!res.ok) throw new Error(`HTTP ${res.status}`)
        const json = await res.json()
        if (!cancelled) setData(json)
      } catch (err) {
        if (!cancelled) setError(err.message)
      } finally {
        if (!cancelled) setLoading(false)
      }
    }

    fetchData()
    return () => { cancelled = true }
  }, [url])

  return { data, loading, error }
}

Using it is clean and straightforward:

function PostList() {
  const { data: posts, loading, error } = useFetch('/api/posts')

  if (loading) return <p>Loading...</p>
  if (error) return <p>Error: {error}</p>

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

Rules of Hooks

There are two rules you must always follow:

Only call Hooks at the top level — never inside conditions, loops, or nested functions
Only call Hooks from React functions — not from plain JavaScript functions

// ❌ Wrong: calling a Hook inside a condition
function Bad() {
  if (someCondition) {
    const [count, setCount] = useState(0) // not allowed!
  }
}

// ✅ Correct: always call at the top level
function Good() {
  const [count, setCount] = useState(0)

  if (someCondition) {
    return <div>{count}</div>
  }
}

Summary

Hook	Purpose
`useState`	Manage local state
`useEffect`	Handle side effects (fetching, subscriptions, DOM)
`useContext`	Read Context values without prop drilling
`useRef`	Access DOM elements / store non-rendering mutable values
`useCallback`	Memoize function references to optimize child renders
`useMemo`	Memoize expensive computed values
Custom Hook	Extract and reuse stateful logic across components

React Hooks significantly reduce code complexity and make logic reuse feel natural. Start with useState and useEffect, then work your way toward building your own custom Hooks.

VLM-RRT: Vision Language Model Guided RRT Search for Autonomous UAV Navigation

hello@jye.bio — Sun, 15 Jun 2025 00:00:00 GMT

Authors: Jianlin Ye, Savvas Papaioannou, Panayiotis Kolios

Venue: 2025 International Conference on Unmanned Aircraft Systems (ICUAS)

Location: Charlotte, NC, USA

Pages: 633-640

Publisher: IEEE

DOI: 10.1109/ICUAS65942.2025.11007837

Abstract

Path planning is a fundamental capability of autonomous Unmanned Aerial Vehicles (UAVs), enabling them to efficiently navigate toward a target region or explore complex environments while avoiding obstacles. Traditional path-planning methods, such as Rapidly-exploring Random Trees (RRT), have proven effective but often encounter significant challenges. These include high search space complexity, suboptimal path quality, and slow convergence, issues that are particularly problematic in high-stakes applications like disaster response, where rapid and efficient planning is critical.

To address these limitations and enhance path-planning efficiency, we propose Vision Language Model RRT (VLM-RRT), a hybrid approach that integrates the pattern recognition capabilities of Vision Language Models (VLMs) with the path-planning strengths of RRT. By leveraging VLMs to provide initial directional guidance based on environmental snapshots, our method biases sampling toward regions more likely to contain feasible paths, significantly improving sampling efficiency and path quality.

Extensive quantitative and qualitative experiments with various state-of-the-art VLMs demonstrate the effectiveness of this proposed approach.

BibTeX

@inproceedings{ye2025vlmrrt,
  title={VLM-RRT: Vision Language Model Guided RRT Search for Autonomous UAV Navigation},
  author={Ye, Jianlin and Papaioannou, Savvas and Kolios, Panayiotis},
  booktitle={2025 International Conference on Unmanned Aircraft Systems (ICUAS)},
  pages={633--640},
  year={2025},
  organization={IEEE},
  address={Charlotte, NC, USA},
  doi={10.1109/ICUAS65942.2025.11007837}
}

CNN based Real-time Forest Fire Detection System for Low-power Embedded Devices

hello@jye.bio — Mon, 26 Jun 2023 00:00:00 GMT

Authors: Jianlin Ye, Stelios Ioannou, Panagiota Nikolaou, Marios Raspopoulos

Venue: 2023 31st Mediterranean Conference on Control and Automation (MED)

Location: Limassol, Cyprus

Pages: 137-143

Publisher: IEEE

DOI: 10.1109/MED59994.2023.10185692

Abstract

This paper proposes a system architecture that uses deep learning image processing techniques to automatically identify forest fires in real-time using neural network models for small UAV applications. Considering the strict power and payload constraints of small UAVs, the proposed model runs on a compact, lightweight Raspberry Pi4B (RPi4B) and its performance is comparable to the state-of-the-art metrics (accuracy and real-time response) while achieving significant reduction in CPU usage and power consumption.

The proposed YOLOv5 optimization approach used in this paper includes:

Replacing the backbone network to ShuffleNetV2
Pruning the Head and Neck network following the backbone baseline
Sparse training to implement the model-pruning method
Fine-tuning of the pruned network to recover the detection accuracy
Hardware acceleration by overclocking the RPi4B to improve the inference speed of the algorithm

Experimental results of the proposed forest fire detection system show that the proposed algorithm compared to the state-of-the-art that run on RPi single board computer, achieves 50% higher inference speed (9 FPS), reduction in CPU usage and temperature by 35% and 25% respectively and 10% reduced power consumption while the accuracy (92.5%) is only compromised by 2%.

Finally, it is worth noting that the accuracy of the proposed algorithm is not affected by deviations in the bird-eye view angle.

BibTeX

@inproceedings{ye2023cnn,
  title={CNN based Real-time Forest Fire Detection System for Low-power Embedded Devices},
  author={Ye, Jianlin and Ioannou, Stelios and Nikolaou, Panagiota and Raspopoulos, Marios},
  booktitle={2023 31st Mediterranean Conference on Control and Automation (MED)},
  pages={137--143},
  year={2023},
  organization={IEEE},
  address={Limassol, Cyprus},
  doi={10.1109/MED59994.2023.10185692}
}