Implements comprehensive robot localization system as third template option.
Teams can now start with professional positioning and navigation code.
Template Features:
- 12x12 field grid system (12-inch cells)
- Multi-sensor fusion (encoders, IMU, vision)
- Kalman-filter-style sensor combination
- Fault-tolerant positioning (graceful degradation)
- 21 files, ~1,500 lines, 3 passing tests
Core Components:
- GridCell/Pose2D/FieldGrid - Coordinate system
- RobotLocalizer - Sensor fusion engine
- OdometryTracker - Dead reckoning from encoders
- ImuLocalizer - Heading from gyroscope
- VisionLocalizer - Position from AprilTags
Sensor Fusion Strategy:
Priority 1: Vision (AprilTags) → ±2" accuracy, 100% confidence
Priority 2: IMU + Odometry → ±4" accuracy, 70% confidence
Priority 3: Odometry only → ±12" accuracy, 40% confidence
System gracefully degrades when sensors fail, maintaining operation
even with partial sensor availability.
Hardware Abstraction:
- Interfaces (Encoder, GyroSensor, VisionCamera)
- Mock implementations for unit testing
- Teams implement FTC wrappers for their hardware
Documentation:
- LOCALIZATION_GUIDE.md - System architecture and usage
- GRID_SYSTEM.md - Field coordinate reference
- README.md - Quick start and examples
Usage:
weevil new my-robot --template localization
cd my-robot
./gradlew test # 3 tests pass in < 1 second
This teaches professional robotics concepts (sensor fusion, fault
tolerance, coordinate systems) not found in other FTC tools. Positions
Nexus Workshops as teaching advanced autonomous programming.
Updated src/templates/mod.rs to register localization template with
proper metadata and feature descriptions.
All tests passing (10/10 template tests).
Comprehensively updates all documentation to reflect the template system
feature shipped in v1.1.0 and plans for v1.2.0 package ecosystem.
README.md:
- Add prominent "What's New in v1.1.0" section highlighting templates
- Expand template documentation with detailed examples and use cases
- Show testing template's 45 tests and professional patterns
- Position templates as "game changer" for FTC learning
- Update command reference and quick start guides
- Add template deep dive section with usage recommendations
TEMPLATE-PACKAGE-SPEC.md:
- Mark Part 1 (Templates) as ✅ COMPLETE in v1.1.0
- Document actual implementation (embedded templates, variable substitution)
- Add "Lessons Learned" section from template development
- Update Part 2 (Packages) to reflect v1.2.0 planning
- Show transition from design to implementation reality
- Maintain comprehensive `weevil add` specification for v1.2.0
ROADMAP.md:
- Mark template system complete in v1.1.0 section
- Add "THE GAME CHANGER" designation for templates
- Feature `weevil add` package system as v1.2.0 "THE NEXT BIG THING"
- List initial 15 packages planned for v1.2.0 launch
- Add "Recent Accomplishments" celebrating v1.1.0 delivery
- Update success metrics with actual achievements
- Show clear progression: templates → packages → debugging
Impact:
- Documentation now reflects production reality (templates shipped!)
- Clear roadmap shows v1.2.0 package ecosystem as next major milestone
- Positions Weevil as transformative for FTC software engineering
- Comprehensive reference for teams learning from template system
All documentation ready for v1.1.0 release tag.
Implements template-based project creation allowing teams to start with
professional example code instead of empty projects.
Features:
- Two templates: 'basic' (minimal) and 'testing' (45-test showcase)
- Template variable substitution ({{PROJECT_NAME}}, etc.)
- Template validation with helpful error messages
- `weevil new --list-templates` command
- Templates embedded in binary at compile time
Testing template includes:
- 3 complete subsystems (MotorCycler, WallApproach, TurnController)
- Hardware abstraction layer with mock implementations
- 45 comprehensive tests (unit, integration, system)
- Professional documentation (DESIGN_AND_TEST_PLAN.md, etc.)
Usage:
weevil new my-robot # basic template
weevil new my-robot --template testing # testing showcase
weevil new --list-templates # show available templates
This enables FTC teams to learn from working code and best practices
rather than starting from scratch.
All 62 tests passing.
Implements template-based project creation allowing teams to start with
professional example code instead of empty projects.
Features:
- Two templates: 'basic' (minimal) and 'testing' (45-test showcase)
- Template variable substitution ({{PROJECT_NAME}}, etc.)
- Template validation with helpful error messages
- `weevil new --list-templates` command
- Template files embedded in binary at compile time
Technical details:
- Templates stored in templates/basic/ and templates/testing/
- Files ending in .template have variables replaced
- Uses include_dir! macro to embed templates in binary
- Returns file count for user feedback
Testing template includes:
- 3 complete subsystems (MotorCycler, WallApproach, TurnController)
- Hardware abstraction layer with mock implementations
- 45 comprehensive tests (unit, integration, system)
- Professional documentation (DESIGN_AND_TEST_PLAN.md, etc.)
Usage:
weevil new my-robot # basic template
weevil new my-robot --template testing # testing showcase
weevil new --list-templates # show available templates
This enables FTC teams to learn from working code and best practices
rather than starting from scratch.
Considering pulling in features that auto generate code or pull in
packages. The code generation is planned to bring into v1.1.0 and
the document in this commit walks through that decision in great
detail.
Add status tracking system with visual markers (✅ Complete, ⚠️ In Progress,
🔄 Deferred, ❌ Cancelled) to track feature progress across versions.
v1.1.0 status updates:
- Mark version as ✅ COMPLETE (released as v1.1.0-beta.2)
- System diagnostics (weevil doctor): ✅ Complete
- Dependency cleanup (weevil uninstall): ✅ Complete
- Corporate/school proxy support: ✅ Complete
- Android Studio integration: ✅ Complete
- Manual installation docs: 🔄 Deferred to v1.2.0
- Debian packaging: 🔄 Deferred (not essential for adoption)
v1.2.0 additions:
- Android Studio debugging support: HIGH priority natural extension
of existing IDE integration. Enables breakpoint debugging, variable
inspection, and step-through execution directly from Android Studio.
Major educational value for teaching proper debugging techniques.
- Windows testing & stabilization: CRITICAL priority, blocks v1.1.0
final release. Comprehensive verification needed.
Research items added:
- SOCKS proxy support: LOW priority, wait for user requests. HTTP
proxy covers most use cases; SOCKS would enable additional restricted
environments but has implementation complexity.
Updated timestamp to February 2026.
Document proxy support and Android Studio integration added in v1.1.0.
New sections:
- Proxy Support: --proxy and --no-proxy flags, HTTPS_PROXY env var
auto-detection, air-gapped/offline installation workflows
- Android Studio Setup: complete guide including Shell Script plugin
installation, opening projects, and using run configurations
- Troubleshooting: Android Studio plugin issues, proxy debugging
Updated sections:
- Quick Start: add weevil setup and weevil doctor as step 1
- Command Reference: environment commands (doctor, setup, uninstall),
global proxy flags
- Features: highlight Android Studio integration and proxy support
- Project Status: current version 1.1.0, updated "What Works" list
Expanded troubleshooting for common issues: adb not found, proxy
connectivity, Android Studio run configuration errors.
All existing content preserved. Tone stays practical and student-focused.
Generate .idea/ run configurations for one-click build and deployment
directly from Android Studio. Students can now open projects in the IDE
they already know and hit the green play button to deploy to their robot.
Run configurations generated:
- Build: compiles APK without deploying (build.sh / build.bat)
- Deploy (auto): auto-detects USB or WiFi connection
- Deploy (USB): forces USB deployment (deploy.sh --usb)
- Deploy (WiFi): forces WiFi deployment (deploy.sh --wifi)
- Test: runs unit tests (./gradlew test)
Both Unix (.sh) and Windows (.bat) variants are generated. Android Studio
automatically hides the configurations whose script files don't exist, so
only platform-appropriate configs appear in the Run dropdown.
workspace.xml configures the project tree to hide internal directories
(build/, .gradle/, gradle/) and expand src/ by default, giving students
a clean view of just their code and the deployment scripts.
Technical notes:
- Uses ShConfigurationType (not the old ShellScript type) for Android
Studio 2025.2+ compatibility
- All paths use $PROJECT_DIR$ for portability
- INTERPRETER_PATH is /bin/bash on Unix, cmd.exe on Windows
- upgrade.rs regenerates all .idea/ files so run configs stay in sync
with any future deploy.sh flag changes
Requires Shell Script plugin (by JetBrains) to be installed in Android
Studio. README.md updated with installation instructions.
Files modified:
- src/project/mod.rs: generate_idea_files() writes 5 XML files per platform
- src/commands/upgrade.rs: add .idea/ files to safe_to_overwrite
Nine end-to-end tests for the proxy feature: 6 network tests exercising
every proxy code path through a real hyper forward proxy (TestProxy) and
a mockito origin, plus 3 CLI tests verifying flag parsing and error handling.
TestProxy binds to 127.0.0.1:0, forwards in absolute-form, counts requests
via an atomic so we can assert traffic actually traversed the proxy.
Key issues resolved during implementation:
- ENV_MUTEX serializes all tests that mutate HTTPS_PROXY/HTTP_PROXY in both
the unit test module and the integration suite. Without it, parallel test
execution within a single binary produces nondeterministic failures.
- reqwest's blocking::Client owns an internal tokio Runtime. Dropping it
inside a #[tokio::test] async fn panics on tokio >= 1.49. All reqwest
work runs inside spawn_blocking so the Client drops on a thread-pool
thread where that's permitted.
- service_fn's closure can't carry a return-type annotation, and async
blocks don't support one either. The handler is extracted to a named
async fn (proxy_handler) so the compiler can see the concrete
Result<Response, Infallible> and satisfy serve_connection's Error bound.
Add --proxy and --no-proxy global flags to control HTTP/HTTPS proxy
usage for all network operations (SDK installs, FTC SDK clone/fetch,
Android SDK download).
Proxy resolution priority:
1. --no-proxy → go direct, ignore everything
2. --proxy <url> → use the specified proxy
3. HTTPS_PROXY / HTTP_PROXY env vars (auto-detected)
4. Nothing → go direct
Key implementation details:
- reqwest client is always built through ProxyConfig::client() rather
than Client::new(), so --no-proxy actively suppresses env-var
auto-detection instead of just being a no-op.
- git2/libgit2 has its own HTTP transport that doesn't use reqwest.
GitProxyGuard is an RAII guard that temporarily sets/clears the
HTTPS_PROXY env vars around clone and fetch operations, then restores
the previous state on drop. This avoids mutating ~/.gitconfig.
- Gradle wrapper reads HTTPS_PROXY natively; no programmatic
intervention needed.
- All network failure paths now print offline/air-gapped installation
instructions automatically, covering manual SDK installs and Gradle
distribution download.
Closes: v1.1.0 proxy support milestone
Replace all hardcoded "1.1.0" version strings with env!("CARGO_PKG_VERSION")
in src/, so Cargo.toml is the sole source for the built binary. Tests
intentionally use a separate hardcoded constant in tests/common.rs to act
as a canary — they will fail on a version bump until manually updated.
- src/project/mod.rs: add WEEVIL_VERSION const, wire into Tera context,
generated README, and .weevil-version marker
- tests/common.rs: new file, holds EXPECTED_VERSION for all test crates
- tests/{integration,project_lifecycle,unit/config_tests}.rs: pull from
common instead of env! or inline literals
Adds WEEVIL_HOME-based test isolation so cargo test never touches
the real system. All commands run against a fresh TempDir per test.
Environment tests cover doctor, uninstall, new, and setup across
every combination of missing/present dependencies. Project lifecycle
tests cover creation, config persistence, upgrade, and build scripts.
Full round-trip lifecycle test: new → gradlew test → gradlew
compileJava → uninstall → doctor (unhealthy) → setup → doctor
(healthy). Confirms skeleton projects build and pass tests out of
the box, and that uninstall leaves user projects untouched.
34 tests, zero warnings.
Adds `weevil uninstall` with three modes of operation:
- Full uninstall removes the entire .weevil directory
- --dry-run enumerates managed components and their sizes
- --only N removes specific components by index
Acknowledges system-installed dependencies (Android SDK, Gradle)
in dry-run output so users know what will and won't be touched.
Project creation now requires environment setup first.
Checks system health and directs users to `weevil setup` if needed.
Separates concerns: setup installs, new creates projects.
Adds `weevil doctor` to check development environment health.
Reports status of Java, FTC SDK, Android SDK, ADB, and Gradle.
Provides clear next steps based on system state.
Adds `weevil setup` with two modes:
- System setup: installs default SDKs and dependencies
- Project setup: reads .weevil.toml and installs project requirements
Provides platform-specific installation instructions when auto-install fails.
Never leaves users wondering what to do next.
Update version references from 1.0.0-rc2 to 1.0.0 across documentation.
This marks the first production-ready stable release of Weevil with complete
cross-platform support, robust Windows deployment, and comprehensive project
management features.
Changes:
- Update README.md current version to 1.0.0
- Remove "Next Release" section from ROADMAP.md (now tracking post-1.0 features)
Weevil is now stable and ready for FTC teams to use in production. 🎉
Add ROADMAP.md documenting planned features and improvements for the
initial stable release and future versions.
Roadmap includes:
- Pre-1.0.0: Critical fixes for Windows deployment and documentation
- v1.0.0 features: Enhanced project templates, improved error handling
- Post-1.0.0: Advanced features like custom templates, project analytics,
multi-robot support, and CI/CD integration
This provides transparency for users and contributors about the project's
direction and planned capabilities.
Fixes critical bugs in Windows APK deployment workflow including APK path
resolution, adb integration, and config file parsing.
Changes:
- Fix APK search to look for TeamCode-debug.apk instead of *app-debug.apk
- Strip both single and double quotes from batch file path parsing
- Add android_sdk_path to project configuration (.weevil.toml)
- Resolve adb.exe from Android SDK platform-tools directory
- Check adb install exit code and report deployment failures correctly
- Add migration support for old .weevil.toml files missing android_sdk_path
- Update all tests to use new ProjectConfig::new() signature
The deployment workflow now properly finds the generated APK, locates adb,
and reports success/failure accurately on Windows.
Complete Windows compatibility overhaul with robust cross-platform SDK management.
This release candidate establishes feature freeze for the 1.0.0 release.
Key improvements:
- Fixed Android SDK installation on Windows
* Use cmd.exe wrapper for sdkmanager.bat with piped stdin
* Properly reorganize cmdline-tools directory structure
* Write license acceptances synchronously to avoid hangs
- Fixed FTC SDK configuration
* Auto-generate local.properties with Android SDK path
* Escape backslashes in Kotlin build.gradle.kts strings
* Support both new installs and upgrades via ensure_local_properties()
- Enhanced Windows console output
* Enable ANSI color support via enable_ansi_support crate
* Maintain color compatibility across Windows versions
- Improved error handling and debugging
* Added comprehensive logging throughout SDK installation
* Better context messages for troubleshooting failures
Cross-platform testing verified on:
- Windows 11 with Eclipse Adoptium JDK 21
- Linux (existing support maintained)
Breaking changes: None
This RC introduces feature freeze - subsequent 1.0.x releases will be
bug fixes only. New features deferred to 1.1.0.
Closes Windows compatibility milestone.
- Fix unused `project_path` parameter warning in make_executable()
- Add build-release.sh for automated binary packaging
- Update .gitignore to exclude release artifacts
- Support cross-compilation for Linux and Windows binaries
Release artifacts are now built with ./build-release.sh and uploaded
to Gitea releases separately, keeping the git repo clean.
Cross-platform tool for generating clean, testable FTC robot projects
without editing the SDK installation.
Features:
- Standalone project generation with proper separation from SDK
- Per-project SDK configuration via .weevil.toml
- Local unit testing support (no robot required)
- Cross-platform build/deploy scripts (Linux/macOS/Windows)
- Project upgrade system preserving user code
- Configuration management commands
- Comprehensive test suite (11 passing tests)
- Zero-warning builds
Architecture:
- Pure Rust implementation with embedded Gradle wrapper
- Projects use deployToSDK task to copy code to FTC SDK TeamCode
- Git-ready projects with automatic initialization
- USB and WiFi deployment with auto-detection
Commands:
- weevil new <name> - Create new project
- weevil upgrade <path> - Update project infrastructure
- weevil config <path> - View/modify project configuration
- weevil sdk status/install/update - Manage SDKs
Addresses the core problem: FTC's SDK structure forces students to
edit framework internals instead of separating concerns like industry
standard practices. Weevil enables proper software engineering workflows
for robotics education.
