skills/drone-cv-expert/SKILL.md
Expert in drone systems, computer vision, and autonomous navigation. Specializes in flight control, SLAM, object detection, sensor fusion, and path planning. Activate on "drone", "UAV", "SLAM", "visual odometry", "PID control", "MAVLink", "Pixhawk", "path planning", "A*", "RRT", "EKF", "sensor fusion", "optical flow", "ByteTrack". NOT for domain-specific inspection tasks like fire detection, roof damage assessment, or thermal analysis (use drone-inspection-specialist), GPU shader optimization (use metal-shader-expert), or general image classification without drone context (use clip-aware-embeddings).
npx skillsauth add curiositech/windags-skills drone-cv-expertInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Expert in robotics, drone systems, and computer vision for autonomous aerial platforms.
User mentions drones or UAVs?
├─ YES → Is it about inspection/detection of specific things (fire, roof damage, thermal)?
│ ├─ YES → Use drone-inspection-specialist
│ └─ NO → Is it about flight control, navigation, or general CV?
│ ├─ YES → Use THIS SKILL (drone-cv-expert)
│ └─ NO → Is it about GPU rendering/shaders?
│ ├─ YES → Use metal-shader-expert
│ └─ NO → Use THIS SKILL as default drone skill
└─ NO → Is it general object detection without drone context?
├─ YES → Use clip-aware-embeddings or other CV skill
└─ NO → Probably not a drone question
Wrong: Testing only in Gazebo/AirSim, then deploying directly to real drone. Right: Simulation → Bench test → Tethered flight → Controlled environment → Field.
Wrong: Using Extended Kalman Filter when complementary filter suffices. Right: Match filter complexity to requirements:
Wrong: Processing 4K frames at 30fps expecting real-time performance. Right: Resolution trade-offs by altitude/speed: | Altitude | Speed | Resolution | FPS | Rationale | |----------|-------|------------|-----|-----------| | <30m | Slow | 1920x1080 | 30 | Detail needed | | 30-100m | Medium | 1280x720 | 30 | Balance | | >100m | Fast | 640x480 | 60 | Speed priority |
Wrong: Sequential detect → track → control in one loop. Right: Pipeline parallelism:
Thread 1: Camera capture (async)
Thread 2: Object detection (GPU)
Thread 3: Tracking + state estimation
Thread 4: Control commands
Wrong: Assuming GPS is always accurate and available. Right: Multi-source position estimation:
Wrong: Using same YOLO model for all scenarios. Right: Model selection by constraint: | Constraint | Model | Notes | |------------|-------|-------| | Latency critical | YOLOv8n | 6ms inference | | Balanced | YOLOv8s | 15ms, better accuracy | | Accuracy first | YOLOv8x | 50ms, highest mAP | | Edge device | YOLOv8n + TensorRT | 3ms on Jetson |
| Problem | Classical Approach | Deep Learning | When to Use Each | |---------|-------------------|---------------|------------------| | Feature tracking | KLT optical flow | FlowNet | Classical: Real-time, limited compute. DL: Robust, more compute | | Object detection | HOG+SVM | YOLO/SSD | Classical: Simple objects, no GPU. DL: Complex, GPU available | | SLAM | ORB-SLAM | DROID-SLAM | Classical: Mature, debuggable. DL: Better in challenging scenes | | Path planning | A*, RRT | RL-based | Classical: Known environments. DL: Complex, dynamic |
| Message | Purpose | Frequency | |---------|---------|-----------| | HEARTBEAT | Connection alive | 1 Hz | | ATTITUDE | Roll/pitch/yaw | 10-100 Hz | | LOCAL_POSITION_NED | Position | 10-50 Hz | | GPS_RAW_INT | Raw GPS | 1-10 Hz | | SET_POSITION_TARGET | Commands | As needed |
| Matrix | High Values | Low Values | |--------|-------------|------------| | Q (process noise) | Trust measurements more | Trust model more | | R (measurement noise) | Trust model more | Trust measurements more | | P (initial covariance) | Uncertain initial state | Confident initial state |
| Frame | Origin | Axes | Use | |-------|--------|------|-----| | NED | Takeoff point | North-East-Down | Navigation | | ENU | Takeoff point | East-North-Up | ROS standard | | Body | Drone CG | Forward-Right-Down | Control | | Camera | Lens center | Right-Down-Forward | Vision |
Detailed implementations in references/:
navigation-algorithms.md - SLAM, path planning, localizationsensor-fusion-ekf.md - Kalman filters, multi-sensor fusionobject-detection-tracking.md - YOLO, ByteTrack, optical flow| Tool | Strengths | Weaknesses | Best For | |------|-----------|------------|----------| | Gazebo | ROS integration, physics | Graphics quality | ROS development | | AirSim | Photorealistic, CV-focused | Windows-centric | Vision algorithms | | Webots | Multi-robot, accessible | Less drone-specific | Swarm simulations | | MATLAB/Simulink | Control design | Not real-time | Controller tuning |
Key Principle: In drone systems, reliability trumps performance. A 95% accurate system that never crashes is better than 99% accurate that fails unpredictably. Always have fallbacks.
data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.