Undocumented Vex Tech Scavenger Hunt

A few finds from messing around this season, including some random fun facts.

  • vex::vision::code is largely undocumented/unexplained. I believe these work similar to Pixy2 Vision Codes
  • Suprisingly, vex::pneumatics isn’t listed anywhere on VEX help resources (they recommend using digital_out instead). This offers an easier abstraction over digital_out.
  • vex::this_thread::sleep_for(); offers an alternative API to vex::task::sleep, which better matches the standard library implementation of threads.
  • Headers for libv5rt can be easily accessed via the vscode extension (since lv5rt.a is a static library). api.vexcode.cloud seems to be generated on these headers using doxygen (or something similar). These include the undocumented C API, but not the actual private API (v5_apiprivate.h is omitted from the actual production distribution of the V5 SDK).
  • The actual entrypoint for the V5 API is actually v5_cpp.h and not v5_vcs.h. v5_vcs.hseems to be included in vex.h as a relic of the older VEX coding studio program.
  • vex::competition::bStopAllTasksBetweenModes
  • For some reason vex::inertial::getTurnType is marked as protected, making it impossible to tell which direction the gyro of an inertial sensor reads as positive.
  • VEXCode Pro is written using nw.js and uses Monaco for its internal editor.
  • This is documented, but not well known. vex::triport::installed allows you to get the status and type of a triport device, similar to how smart port devices have an installed method.
  • vex::controller::axis::position returns integers from [-100, 100], while vex::controller::axis::value returns integers from [-127, 127]. This isn’t really listed anywhere, and could be a footgun if you use value instead of position.