Open-source Rust Runtime for the VEX V5 Platform

Overview

vexide

Work in progress high level bindings for the V5 Brain VEX SDK. Unlike other libraries for the V5 Brain, vexide doesn't use an RTOS. Instead, vexide leverages Rust's powerful async/await (cooperative multitasking) to allow faster and more user friendly code.

vexide is the successor to pros-rs which now serves as a slightly more stable, but unmaintained api using bindings over PROS.

vexide is still in development but we are quickly moving towards competition readiness.

Usage

Compiling

The vexide library itself has no external dependencies, but cargo-pros depends on pros-cli for uploading and cargo-binutils for necessary binary modification. Read the installation guide for your OS to see how to get things set up.

Windows

Steps:

  1. Install the pros cli, instructions are here
  2. Install cargo pros with cargo install cargo-pros
  3. Install cargo-binutils with cargo install cargo-binutils

To compile the project just run cargo pros build.

Linux

The steps for getting vexide compiling are slightly different based on if you use Nix or not.

With Nix

The Nix flake contains the Arm GNU Toolchain, cargo pros, and pros-cli.

There is a .envrc file included for Nix + Direnv users.

Without Nix

Install cargo-binutils and pros-cli from your package manager of choice. Cargo pros can be installed with cargo install cargo-pros.

MacOS

This project depends on the Xcode Command Line Tools. Chances are that if you develop on MacOS you have them already, but if not you can install them with xcode-select --install.

Most of the other dependencies can easily be installed with Homebrew.

Install the Arm GNU Toolchain with brew install osx-cross/arm/arm-gcc-bin.

Install pros-cli with brew install purduesigbots/pros/pros-cli.

And you are done! Compile the project with cargo build.

Compiling for WASM

To build projects in this repository for WebAssembly, run cargo pros build -s This will automatically pass all of the correct arguments to cargo.

If, for some reason, you want to do it manually, this is the command: cargo build --target wasm32-unknown-unknown -Zbuild-std=std,panic_abort.

The extra build-std argument is neccesary because this repository's .cargo/config.toml enables build-std but only for core, alloc, and compiler_builtins. WebAssembly does come with std but there is currently no way to conditionally enable build-std.

Comments
  • feat(wasm): support building for webassembly target

    feat(wasm): support building for webassembly target

    Describe the changes this PR makes. Why should it be merged?

    This PR adds support for building for WebAssembly to be simulated.

    • Cargo config has updated linker flags
      • Memory is no longer shared because there is no need to simulate FreeRTOS task switching. Before, the simulator would essentially do multithreading (but only run 1 thread at once). Multithreading in WASM requires memory to be marked as shared.
      • Indirect function table is now imported instead of exported. This makes it easier to develop the simulator because the jump table can be set up before booting. I didn't do this with the memory because it seems like Dlmalloc can't see imported memory and always returns OOM errors?
    • Wasm32 is now a checked target by rust-analyzer; this was necessary for making sure everything compiled on both platforms.
    • Added NoopCriticalSection for WASM
      • WASM doesn't have interrupts or any way to disable them so I'm pretty sure it's safe. Also because the module's memory is not shared there is guaranteed to not be any multithreading.
    • Cfg's for ARM assembly
      • The operations being performed at the start of the program aren't actually necessary in WASM.

    Additional Context

    • I have tested these changes on a VEX V5 brain.
    • I have tested these changes in a simulator.
    simulator 
    opened by doinkythederp 2
  • add: vexide-graphics crate and driver implementations

    add: vexide-graphics crate and driver implementations

    Describe the changes this PR makes. Why should it be merged?

    This PR adds the vexide-graphics crate with a brain display driver for Slint and embedded-graphics.

    Additional Context

    • These changes update the crate's interface (e.g. functions/modules added or changed).
    • I have tested these changes on a VEX V5 brain.
    graphics 
    opened by Gavin-Niederman 2
  • Doesn't compile without critical_section feature

    Doesn't compile without critical_section feature

    Bug Description

    Disabling the critical_section feature makes the crate not compile.

    Code to reproduce

    N/A

    Expected vs. actual behavior

    There shouldn't be any broken features.

    Additional information

    • I have tested this issue on the latest development release.
    • Rust version (see rustc --version): rustc 1.78.0-nightly (256b6fb19 2024-02-06)
    • vexide version (see Cargo.toml): 273c7bffa9945d6d89c1321c3ae19a71279fe33d
    bug 
    opened by doinkythederp 2
  • feat: AdiEncoder, AddrLed support

    feat: AdiEncoder, AddrLed support

    Describe the changes this PR makes. Why should it be merged?

    Adds initial support for the following ADI devices:

    • Quad Encoder
    • WS2812B Addressible LEDs

    Additionally refactors a few things.

    • Renamed AdiUltrasonic to AdiRangeFinder for clarity and renamed ping/echo to input/output to match the physical labeling on the wires.

    Additional Context

    • Untested
    opened by Tropix126 2
  • Driver control doesn't start without competition hub

    Driver control doesn't start without competition hub

    Bug Description

    When testing locally without a competition happening, my driver control code never starts.

    Code to reproduce

    TODO, I'll come back to this later once I make a minimum reproducible sample

    Expected vs. actual behavior

    Operator control code should run even if the robot is not at a competition. In reality it never starts.

    Additional information

    • I don't have access to a competition hub so it's possible that driver control code never runs whatsoever.
    core 
    opened by doinkythederp 1
  • fix: flush serial buffer on program exit

    fix: flush serial buffer on program exit

    Describe the changes this PR makes. Why should it be merged?

    This PR adds a exit function to vexide-startup which blocks for 3ms to flush the serial buffer and then exits the program with vexSystemExitRequest.

    Additional Context

    • I have tested these changes on a VEX V5 brain.
    opened by Gavin-Niederman 1
  • refactor: change all crate names to vexide-*

    refactor: change all crate names to vexide-*

    Describe the changes this PR makes. Why should it be merged?

    This PR changes the name of all crates to vexide-* except for pros-sys which will be removed soon. In the future the name of the repo should also be changed to vexide. Pros-sync was deleted entirely because it isn't needed anymore.

    Additional Context

    No code functionality was changed, just crate paths.

    opened by Gavin-Niederman 1
  • refactor: `vexide_async` crate organization

    refactor: `vexide_async` crate organization

    Describe the changes this PR makes. Why should it be merged?

    • Adds the task and time modules (mirrored off of tokio's crate structure more or less).
    • Re-exports Task and FallibleTask from async_task to allow users to store task handles without manually adding async_task as a dependency.
    • Refactors SleepFuture (now named Sleep) to internally store an Instant. This required some minor changes to the reactor.
    • Adds sleep_until which should be pretty self explanatory.
    • Updates docs.
    async 
    opened by Tropix126 0
  • chore: adjust `syn` versioning to be compatible with dependencies

    chore: adjust `syn` versioning to be compatible with dependencies

    Describe the changes this PR makes. Why should it be merged?

    Makes vexide_macro's depdendency on the syn crate not conflict with the versions specified in snafu-derive and pin-project-internal, resulting in this error when attempting to use the vexide crate from an external project: image

    opened by Tropix126 0
  • fix: implement `Send` and `Sync` for smart devices

    fix: implement `Send` and `Sync` for smart devices

    Describe the changes this PR makes. Why should it be merged?

    Smart devices are currently not Send or Sync, which makes them not shareable between async tasks. This is because we store a raw device handle V5_DeviceT for convenience when interacting with the SDK. Sending raw pointers across threads isn't inherently unsound, and the lack of Send + Sync on raw pointers exists more as a lint.

    opened by Tropix126 0
  • refactor: Screen API

    refactor: Screen API

    Describe the changes this PR makes. Why should it be merged?

    • Changes text drawing to no longer support the line positioning mode, since that has some inconsistent behavior.
    • Removed direct usage of mint::Point2, instead adding our own Point2 struct with an actually practical implementation.
    • Re-exports some mint types used by devices through the geometry module.
    • draw pixel is now dead. Instead we blanket-impl Fill for all types that can be converted into a Point2.
    • Fixes various issues caused by not taking the program header into account while drawing.

    Additional Context

    Closes #44. Needs hardware testing.

    opened by Tropix126 0
  • refactor: new `Position` struct

    refactor: new `Position` struct

    Describe the changes this PR makes. Why should it be merged?

    Refactors Position to hopefully have more precision. It now always stores data in terms of ticks with a TPR value being the LCM between the two largest TPR devices (motor and rotation sensor). I've also adjusted the naming to match similar standard library types like Duration.

    Additional Context

    TODO:

    • Hardware test (of course)
    • Update examples
    smart-devices adi-devices 
    opened by Tropix126 0
  • `AdiGyro` and `AdiServo` Device Support

    `AdiGyro` and `AdiServo` Device Support

    What's the motivation for this feature?

    Both of these devices are ones i've been avoiding for a while for various reasons, but we need to support them at some point.

    Describe the solution you'd like

    • Add an AdiGyro support for abstracting over the old 3-wire yaw-rate gyro.
    • Add an AdiServo struct for controlling the legacy cortex-era servos.

    Describe the drawbacks, if any

    Both of these devices are very poorly documented in the SDK and may utilize private API functionality on VEXCode's side. Not sure.

    • In AdiGyro's case, VEXCode has an is_calibrating function while PROS does not. There's no provided function in the SDK for this functionality, meaning it's probably some undocumented status bit. Fun.
    • PROS also is forced into immediately calibrating the sensor as soon as vexDeviceAdiPortConfigSet is called.
    • In AdiServo's case, PROS doesn't even support it at all. The units/range of the ADI setter is comlpetely unknown.

    I also don't have access to any of this hardware to test on.

    enhancement adi-devices 
    opened by Tropix126 0
  • CTE Workcell Devices

    CTE Workcell Devices

    What's the motivation for this feature?

    We currently don't support the following new smart devices from the CTE workcell kit:

    • CteArm
    • CtePneumatics
    • CteSignalTower

    Describe the solution you'd like

    Add support for these devices.

    Describe the drawbacks, if any

    This hardware is very new. I think Liam may have access to a few units, though.

    enhancement smart-devices 
    opened by Tropix126 0
  • AI Vision Support

    AI Vision Support

    What's the motivation for this feature?

    vex-sdk currently supports the AI Vision SDK functions. We should probably look into supporting that.

    Describe the solution you'd like

    Use vex-sdk's syscalls to implement an AiVisionSensor struct that abstracts over the smart device. This API might need to end up being a little different than the current VisionSensor API (which is far more scuffed internally).

    Describe the drawbacks, if any

    • Barely anyone has access to this hardware at this point in time, making it difficult to test. Some features of it may also change in the future.
    • We might want to share some functionality between the old vision sensor and this struct, depending on how similar the APIs are (I don't recall them being that similar, though). We should probably figure out how to best do this (should these sensors be in a single vision module?).
    enhancement smart-devices 
    opened by Tropix126 0
  • GPS Sensor Support

    GPS Sensor Support

    What's the motivation for this feature?

    We current lack support for the V5 GPS sensor as provided by vex-sdk.

    Describe the solution you'd like

    Adding support shouldn't be too bad (it'd essentially be the InertialSensor API but with a few extra getters). We might want to have an Imu trait or something for common functionality to be shared between the two sensors, since their APIs are near identical in the imu-facing hardware abstractions.

    Describe the drawbacks, if any

    I don't have a GPS sensor to test on. Think Liam does, though, so we could use that.

    Describe the alternative solutions, if any

    None

    enhancement smart-devices 
    opened by Tropix126 0
  • Allocator Benchmarks

    Allocator Benchmarks

    We currently leverage talc, which is a fairly experimental memory allocator for embedded systems. Right now, we just use talc because it works and hasn't really raised any trouble. To my knowledge, talc isn't quite up to speed with some competing allocators, but i'm curious around how it stacks up against libc's malloc in libpros, as well as the performance of other allocator options (both performance-wise and efficiency-wise).

    Potential benchmark contenders:

    • linked_list_allocator/embedded_alloc (if we can get it to work)
    • libc's malloc
    • dlmalloc
    • https://github.com/yvt/rlsf
    documentation core 
    opened by Tropix126 1
Owner
vexide
Open source Rust tooling for VEX V5 robots
vexide
Open-source Rewind.ai clone written in Rust and Vue running 100% locally with whisper.cpp

mind-overflow Open-source Rewind.AI clone built with Tauri and Vue. Leverages whisper.cpp for Speech-to-Text and (wip: llama.cpp for Text generation a

Maxime Dolores 4 Aug 9, 2023
Open Source terraform provider registry

Terustry Simple configurable proxy that implement terraform provider registry protocol, to build your own terraform provider private registry. How it

Open-Source by Veepee 53 Nov 24, 2022
Open-source NI maschine device handling

Open-source NI maschine device handling

william light 69 Dec 1, 2022
Ector is an open source async, no-alloc actor framework for embedded devices

Ector is an open source async, no-alloc actor framework for embedded devices. Ector is an open source async, no-alloc actor framework for embedded dev

Drogue IoT 11 Dec 15, 2022
An open-source Windows client for Twitch.tv

TwitchBox is a lightweight Windows client created to enhance the Twitch.tv experience. The app uses the Tauri framework, which includes a combination

Sandun Wiratunga 3 Apr 28, 2023
Fusion is a cross-platform App Dev ToolKit build on Rust . Fusion lets you create Beautiful and Fast apps for mobile and desktop platform.

Fusion is a cross-platform App Dev ToolKit build on Rust . Fusion lets you create Beautiful and Fast apps for mobile and desktop platform.

Fusion 1 Oct 19, 2021
Runtime dependency injection in Rust

This library provides an easy to use dependency injection container with a focus on ergonomics and configurability at the cost of runtime performance. For a more performance-oriented container, look for a compile-time dependency injection library.

TehPers 16 Nov 28, 2022
Rust Kubernetes runtime helpers. Based on kube-rs.

kubert Rust Kubernetes runtime helpers. Based on kube-rs. Features clap command-line interface support; A basic admin server with /ready and /live pro

Oliver Gould 63 Dec 17, 2022
A Rust runtime for AWS Lambda

Rust Runtime for AWS Lambda This package makes it easy to run AWS Lambda Functions written in Rust. This workspace includes multiple crates: lambda-ru

Amazon Web Services - Labs 2.4k Dec 29, 2022
Rust Lambda Extension for any Runtime to preload SSM Parameters as 🔐 Secure Environment Variables!

?? Crypteia Rust Lambda Extension for any Runtime to preload SSM Parameters as Secure Environment Variables! Super fast and only performaned once duri

Custom Ink 34 Jan 7, 2023
Graceful shutdown util for Rust projects using the Tokio Async runtime.

Shutdown management for graceful shutdown of tokio applications. Guard creating and usage is lock-free and the crate only locks when: the shutdown sig

Plabayo 54 Sep 29, 2023
Develop an async runtime like thing in Rust for educational purpose.

How-not-to-async-rs Develop an async runtime like thing in Rust for educational purpose. What this is not This is not going to be a blog post explaini

Arun Muralidharan 28 May 11, 2024
microtemplate - A fast, microscopic helper crate for runtime string interpolation.

microtemplate A fast, microscopic helper crate for runtime string interpolation. Design Goals Very lightweight: I want microtemplate to do exactly one

_iPhoenix_ 13 Jan 31, 2022
ImGUI runtime inspector

igri is a runtime inspector powered by imgui-rs

toyboot4e 2 Oct 30, 2021
Minimal runtime / startup for RISC-V CPUs from Espressif

esp-riscv-rt Minimal runtime / startup for RISC-V CPUs from Espressif. Much of the code in this repository originated in the rust-embedded/riscv-rt re

esp-rs 13 Feb 2, 2023
Use winit like the async runtime you've always wanted

async-winit Use winit like the async runtime you've always wanted. winit is actually asynchronous, contrary to popular belief; it's just not async. It

John Nunley 17 Apr 23, 2023
Continuous runtime observablity SDKs to monitor WebAssembly code.

Observe Observe is an observability SDK for WebAssembly. At the moment we support wasmtime hosts and we output opentelemetry data to stdout. We plan t

Dylibso 4 Jun 8, 2023
A modular and blazing fast runtime security framework for the IoT, powered by eBPF.

Pulsar is a security tool for monitoring the activity of Linux devices at runtime, powered by eBPF. The Pulsar core modules use eBPF probes to collect

Exein.io 319 Jul 8, 2023
Asynchronous runtime abstractions for implicit function decoloring.

decolor Asynchronous runtime abstractions for implicit function decoloring. Decolor is in beta Install | User Docs | Crate Docs | Reference | Contribu

refcell.eth 11 Oct 26, 2023