zendo-protocol

The wire-protocol definitions for the Zendo motion-tracking WebSocket stream: port range, message-type tags, the joint and landmark vocabularies, and the pure decode/encode routines.

This crate is the single source of truth for the protocol. It has no dependencies, performs no I/O, never allocates, and is no_std by disabling the default std feature. Most users want zendo-sdk (Rust) or the zendo-sdk PyPI package (Python), which build a connection on top of this crate. Depend on zendo-protocol directly only if you bring your own transport.

Frame layout

Every frame is one binary WebSocket message: byte 0 is the type tag, the rest is the payload. All numeric values are little-endian f64.

The server sends the hello frame first on every connection, carrying PROTOCOL_VERSION; clients require an exact match. The side byte is 0 for the right hand and 1 for the left. Body messages stream in body-tracking mode; hand messages stream in hand-tracking mode; the two never appear in the same session.

Example

use zendo_protocol::{decode, Message};

fn handle(frame: &[u8]) {
    match decode(frame) {
        Ok(Message::BodyQuaternions(q)) => println!("hips: {:?}", q.hips),
        Ok(Message::BodyLandmarks(l)) => println!("nose: {:?}", l.nose),
        Ok(Message::HandQuaternions { side, frame }) => {
            println!("{} wrist: {:?}", side.as_str(), frame.wrist)
        }
        Ok(Message::HandLandmarks { side, frame }) => {
            println!("{} thumb tip: {:?}", side.as_str(), frame.thumb_tip)
        }
        Err(e) => eprintln!("bad frame: {e}"),
    }
}

License

Licensed under either of Apache-2.0 or MIT at your option.