evian-tracking 0.0.1-rc.1

Robot localization and tracking algorithms in evian.
Documentation
  • Coverage
  • 100%
    26 out of 26 items documented1 out of 18 items with examples
  • Size
  • Source code size: 41.1 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 452.98 kB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 16s Average build duration of successful builds.
  • all releases: 16s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • vexide/evian
    28 12 0
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • Tropix126

Robot localization and tracking.

This crate provides traits and systems for tracking and localizing the position, orientation, velocity, and forward travel of a mobile robot in a 2D environment. The goal is to measure accurate data about the robot and provide it to motion algorithms.

The traits provided in this crate allow for motion algorithms to operate generically over any tracking system implementation, provided that the implementation measures the necessary data.

Tracking systems may choose to implement the following traits for motion algorithms to use:

  • [TracksPosition], for tracking the robot's 2D position (odometry).
  • [TracksHeading], for tracking the robot's absolute orientation (heading).
  • [TracksVelocity], for tracking the robot's linear and angular velocity.
  • [TracksForwardTravel], for tracking the robot's signed forward wheel travel.

Below is an example of a motion algorithm function that is generic across all differential drivetrains with tracking systems that measure a robot's forward wheel travel:

async fn motion(drivetrain: &mut Drivetrain<Differential, impl TracksForwardTravel>) {
    // Motion goes here...
}

Additionally, a reference implementation of a tracking system that performs wheeled odometry is provided by the [wheeled] module.

A quick note about units!

evian made the intentional choice to be primarily unitless, mainly because stable Rust currently lacks many of the features needed to provide a good developer experience using typed units. Although several widely-used libraries exist in stable Rust (such as uom), there is no single obvious choice to be made here and this region of the Rust ecosystem seems to be in a fairly volatile state that would make it dangerous to fully commit to a single library this early on.

As such, evian made the decision to forego requiring specific units of measure where possible, particular in measures of length. Instead, length is typically provided in wheel units, which is defined as "whatever the user measured their wheels with". This gives users a choice of what units to use and keeps everything generally stable while the Rust ecosystem tries to figure out what typed units library to go with.