VEX IQ Python API Reference Guide 🤖🐍
Use this page as your local reference when you need to remember what a VEX Python command does, how it is written, and which part of the robot it belongs to.
This version is broader than a quick cheat sheet. It covers the main hardware pages, the key logic pages, and the extra tools that sit around them so you can keep working even if the VEX site is slow or blocked.
How to use this page
Start with the jump menu to go straight to the section you need.
Read the short explanation first so you know what family of commands you are looking at.
Check the examples to see how commands are actually used in code.
Use the official links when you want every single method on the full VEX page.
Success looks like
- you can find the right command family quickly
- you can tell the difference between movement, sensing, and logic
- you can adapt an example instead of starting from nothing
- you can debug using screen output or print output
Jump menu
1. How to read a VEX API entry
Each VEX API method entry usually gives you the same kinds of information: the command name, a short description, the exact syntax, the parameter list, and an example. Learn to scan those pieces first instead of trying to read every page from top to bottom.
The Python API home page also warns that IQ (2nd gen) runs Python through a virtual machine with limited memory, so very large or complicated programs may fail even if they seem short enough. Keep projects tidy and modular rather than growing one giant monster script.
- Usage: the exact way the command is written
- Parameters: what inputs it expects and in what order
- Return value: what you get back, if anything
- Example: how VEX expects you to use it
2. The basic shape of a VEX Python program
Most VEX projects follow the same rhythm: create or use configured devices, read inputs or sensor values, make a decision, run an action, wait if needed, then repeat. The logic pages cover control flow, variables, functions, events, math, random, operators, comments, string formatting, threads, timer tools, and MicroPython library support.
That means a strong robotics program is not just hardware code. It is also ordinary Python thinking stitched to robot devices.
3. Drivetrain and smart drivetrain
The drivetrain page is one of the most important in the whole API. It covers basic movement, measured movement, turning, heading-based turning, velocity settings, stopping behaviour, timeouts, sensor-linked calibration, and movement status checks.
| Command | What it does | Why it matters |
|---|---|---|
drive() |
Starts driving and keeps going | Good for live control and loops |
drive_for() |
Drives a set distance | Great for autonomous tasks |
turn() |
Starts turning and keeps going | Useful in loops or manual control |
turn_for() |
Turns by a measured amount | Useful for square paths and fixed angles |
turn_to_heading() |
Turns to a specific heading | Uses a smart drivetrain with inertial data |
turn_to_rotation() |
Turns to a specific rotational value | Good for orientation-based programs |
set_drive_velocity() |
Sets default drive speed | Saves repetition |
set_turn_velocity() |
Sets default turn speed | Makes turning more consistent |
set_stopping() |
Changes stop behaviour | Can brake, coast, or hold |
is_moving(), is_done(), is_turning() |
Checks robot status | Helpful for advanced logic |
4. Motors and motor groups
The motor page handles both individual motors and motor groups. This is where you go when you need an arm, claw, intake, lift, or other mechanism that is not just the drivetrain.
spin()starts spinning indefinitelyspin_for()spins by a set amountspin_to_position()moves to a target positionstop()stops the motorset_velocity(),set_max_torque(),set_stopping()set defaultsposition(),velocity(),current(),temperature()report datareset_position()andset_position()help zero the mechanism
Use motors for parts of the robot that are not the whole drive base. Think claws, lifts, catapults, intakes, and custom mechanisms.
5. Controller buttons and joysticks
The controller page covers button states, joystick positions, controller events, and enabling or disabling remote-control code. That means it supports both simple button checks and more advanced event-driven control.
.pressing()checks whether a button is held.pressed(callback)runs a function when pressed.released(callback)runs a function when released.changed(callback)reacts when joystick values change.position()reads joystick positionremote_control_code_enabled()can enable or disable configured controller actions
6. Brain tools: buttons, battery, screen, console, and timer
These pages are your debugging and information pages. They let you show values, track time, read battery data, respond to brain button presses, and print messages to the monitor console.
pressing(), pressed(), released(), capacity(), voltage(), current()
print(), clear_screen(), set_cursor(), next_row(), draw commands
print() to the monitor window for debugging
time(), clear(), system(), system_high_res(), event()
7. Sensors
The sensing pages let the robot detect contact, light, colour, object presence, distance, orientation, acceleration, and more. This is where robot behaviour starts becoming reactive instead of pre-planned.
| Sensor | Key methods | What it is useful for |
|---|---|---|
| Bumper | pressing() |
Collision detection and touch triggers |
| Touch LED | pressing(), pressed(), released(), set_color(), set_blink(), set_brightness() |
Interactive input plus visual status |
| Color Sensor | is_near_object(), color(), brightness(), hue(), set_light() |
Colour-based tasks and reflected light sensing |
| Optical Sensor | is_near_object(), color(), brightness(), hue(), rgb(), set_light_power() |
Object and colour detection |
| Distance Sensor | is_object_detected(), object_distance(), object_velocity(), object_size() |
Obstacle sensing and approach logic |
| Inertial | heading(), rotation(), calibrate(), reset_heading(), acceleration(), gyro_rate(), orientation() |
Heading, turning accuracy, and motion tracking |
8. Logic tools around the hardware
These pages are not robot parts, but they matter just as much. They are the thinking tools behind the robot.
Store integers, floats, strings, Booleans, lists, tuples, and more.
Package reusable behaviour with def and optionally return.
Register functions, then run them together using broadcast() or broadcast_and_wait().
Use Thread(my_function) to run tasks in parallel, then stop() if needed.
Use built-in math functions, the math module, and urandom helpers like randint().
Use comparisons, logical operators, comments, and string formatting to make code readable and testable.
9. Extra hardware pages
Not every class will use these straight away, but they are still part of the API structure.
- Pneumatics:
extend(),retract(),pump_on(),pump_off(),pump(),installed() - Motion index: acts as a hub for motors, motor groups, and pneumatics
- Sensing index: acts as a hub for the brain, bumper, Touch LED, colour-based sensors, distance, and inertial tools
10. Common mistakes
If the robot keeps going forever, check whether you used drive() instead of drive_for() or turn() instead of turn_for().
The command belongs to something. You need drivetrain.drive_for(...), not just drive_for(...).
Add a small wait(20, MSEC) when you are constantly polling buttons or sensors.
Show values on the screen or print them to the console. Let the robot tell you what it is seeing.
11. Practice tasks
Write code that drives forward while the E ▲ button is being pressed. When the button is not being pressed, the robot must stop.
Write code that drives forward until the robot is 200 mm away from an object, then stops.
Official VEX links
Use these when you want the full original pages.