vexide/vexide

Open-source Rust Runtime for the VEX V5 Platform

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.

vexide's Issues

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): 273c7bf

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

`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.

Screen API is in need of a refactor.

What's the motivation for this feature?

Our current Screen drawing api is more or less a direct port from the API in pros-rs. I don't really like how PROS 4 handles some things though, specifically as far as text drawing works. It hides a lot of implementation details of the SDK and has inconsistent behavior regarding the way text is formatted/displayed. We should also look at implementing some other things now available to us as a result of vex-sdk, such as stroke widths.

Describe the solution you'd like

• TextFormat, at least in its current state needs to go. It's behavior with draw is pretty inconsistent and it may produce different size text based on if line or point targets are specified.
• The "centered" styling might need to be removed, due to having limited functionality.

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?).

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

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.

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.