VEX V5 PYTHON | 01.2 MOTOR CONFIGURATION
Guide objective
Map your robot’s motor ports, match each motor’s physical cartridge to its software setting and test direction before grouping motors.
01 | CONFIGURATION CONNECTS CODE TO HARDWARE
A command such as left_front.spin(FORWARD) is useful only if left_front identifies the correct motor, its settings match the hardware and its direction makes sense for the mechanism.
Get those three things right before writing a drivetrain or autonomous routine. Otherwise, a robot that turns when it should drive forward may look like a coding problem when the real issue is a reversed motor or an incorrect port.
Continue in the desktop VEXcode V5 application from the previous guide. The online editor is an alternative if installation is unavailable. This guide uses the Devices panel to maintain motor configuration.
02 | BUILD A PHYSICAL PORT MAP
Follow each motor’s Smart Cable to its numbered Smart Port on the V5 Brain. Smart Ports are numbered 1 to 21. Record the actual connection rather than assuming that the previous team’s configuration is correct.
Identify left and right from the robot’s perspective facing its intended forward direction. Use names that describe a job or location, such as left_front, right_rear, intake or lift.
| Motor name | Brain port | Physical cartridge | Intended positive action |
|---|---|---|---|
| left_front | 3 | Green | Wheel drives robot forward |
| right_front | 1 | Green | Wheel drives robot forward |
| intake | 7 | Blue | Roller brings game objects in |
These ports are examples, not defaults for your robot. Label cables and update the map whenever wiring changes. One configured port should identify one physical Smart device.
03 | MATCH THE INTERNAL GEAR CARTRIDGE
The interchangeable cartridge inside a V5 11W Smart Motor changes its mechanical gearing. Match the cartridge installed in the motor to the setting selected in VEXcode.
| Cartridge | Internal ratio | Nominal output speed | Mechanical trade-off |
|---|---|---|---|
| Red | 36:1 | 100 rpm | Lower speed, higher available output torque |
| Green | 18:1 | 200 rpm | Intermediate speed and torque |
| Blue | 6:1 | 600 rpm | Higher speed, lower available output torque |
RPM means revolutions per minute. These are nominal speed ratings; actual motion depends on load and operating conditions. Torque is the turning effect available to move a mechanism.
This table describes the cartridge-based 11W motor, not every V5-compatible motor type. Confirm which hardware you have.
04 | SOFTWARE CANNOT SWAP PHYSICAL GEARS
Selecting blue in VEXcode does not turn a physically green cartridge into a blue cartridge. The software setting tells the system how to interpret and control that motor; the installed gears still determine its mechanical ratio.
To change the cartridge, follow the official hardware procedure with the motor disconnected from power. Then update the software configuration to match.
Also distinguish internal cartridge gearing from external gears or sprockets. An external reduction can change wheel or mechanism speed after the motor output. Do not put an external drivetrain ratio into the cartridge selection.
05 | ADD A MOTOR IN THE DEVICES PANEL
- Open your Python project and the Devices panel.
- Choose Add a Device, then Motor.
- Select the Smart Port from your physical map.
- Give the motor a meaningful name. For the first test, use test_motor.
- Select the red, green or blue cartridge matching the installed 11W motor cartridge.
- Choose Normal initially, unless a previously verified direction setting is recorded.
- Finish the device setup, save and inspect the generated configuration.
VEXcode creates the motor definition in its generated region. Do not add your own instructions inside that region. Put test functions and settings below # Begin project code.
Do not also define a manual Motor object for the same device. If you later choose manual configuration, maintain it deliberately outside the generated region and avoid conflicting generated definitions.
06 | WHAT DOES REVERSED MEAN?
Reversed swaps the motor’s configured positive and negative directions. The same FORWARD command can therefore make the motor shaft rotate the opposite way after reversal is enabled.
FORWARD does not automatically mean the robot drives forward. Motor mounting, gears and chains affect the final mechanism. Test the output you care about: wheel direction, intake action or lift movement.
Mirrored left and right motors often need different reversal settings so the same logical forward command moves both wheels towards robot-forward. There is no universal rule that all right motors must be reversed; the build determines it.
Set one consistent meaning for each motor’s positive action. For an intake, it might mean collecting objects. For a lift, it might mean moving upwards.
07 | RUN ONE SHORT DIRECTION TEST
Use a loose test motor or a securely supported drivetrain with wheels clear of the floor. Keep fingers, cables and loose clothing clear. Do not apply this generic spin test to a loaded lift, claw or mechanism close to a physical stop.
Configure just the motor you are testing as test_motor, then add the following below the project-code marker. Download to the intended Brain slot and run while ready to stop the program.
# Configure one motor named test_motor in the Devices panel first.
# Place this code BELOW # Begin project code.
# Replace any earlier demonstration main() and its call.
TEST_SPEED = 15 # Percentage of configured motor speed
TEST_TIME_MS = 300 # Short direction test
def main():
brain.screen.clear_screen()
brain.screen.set_cursor(1, 1)
brain.screen.print("Testing one motor")
test_motor.set_stopping(BRAKE)
test_motor.spin(FORWARD, TEST_SPEED, PERCENT)
wait(TEST_TIME_MS, MSEC)
test_motor.stop()
brain.screen.set_cursor(2, 1)
brain.screen.print("Test complete")
main()
The motor runs at 15 percent for 300 milliseconds, then stops using brake mode. Braking helps stop rotation but does not guarantee an immediate stop under every load.
The speed is a percentage of the configured motor’s range, not a universal RPM. The same percentage on differently geared motors does not mean the same shaft speed. A heavily loaded motor may not move at this low setting; investigate the load rather than immediately increasing power.
08 | CORRECT DIRECTION WITHOUT HIDING THE CAUSE
- Record which physical motor moved and its output direction.
- If the wrong motor moved, stop and correct the port mapping.
- If the correct motor moved in the wrong logical direction, change Normal/Reversed in its device settings.
- Save, download again and repeat the identical short test.
- Record the verified setting before moving to another motor.
A change in configuration does not update an already downloaded program. Download the new project before judging the result.
Avoid compensating for a configuration mistake by scattering REVERSE commands through your code. First establish a consistent motor direction, then use FORWARD and REVERSE to express the action you intend.
09 | VERIFY MOTORS BEFORE GROUPING THEM
Test each drivetrain motor individually. Motors connected to the same wheel system must help each other rather than fight each other. If two motors share a rigid mechanism, do not run one against an unverified powered motor; isolate or support the test appropriately.
| Check | Record |
|---|---|
| Identity | The configured name moves the expected physical motor |
| Port | The Brain port matches the wiring map |
| Cartridge | The selected setting matches the physical cartridge |
| Direction | FORWARD produces the chosen positive output action |
| Repeatability | The result remains correct after saving and downloading |
Once these checks are complete, the next guide combines motors into left and right drivetrain groups. Grouping is easier when each motor already has a verified identity and direction.
10 | TROUBLESHOOT THE CONFIGURATION
- No movement: check power, cable seating, selected slot, successful download and the motor’s configured name.
- Wrong motor moves: inspect the actual port map before changing direction.
- Wrong output direction: check mounting and the reversal setting.
- Unexpected speed: check the cartridge, speed units, external gearing and load.
- Motors fight or strain: stop immediately and check their individual directions and mechanical connection.
- Changes disappear: confirm your user code is below the generated region rather than inside it.
CHALLENGES | MAKE A VERIFIED MOTOR MAP
- Audit your robot: draw a labelled port map showing every motor and its role.
- Identify gearing: record each cartridge and explain its speed/torque trade-off.
- Configure one motor: add test_motor using its actual port and cartridge.
- Test and reverse: run the short supported-wheel or loose-motor test. Change reversal and observe the difference, then keep the correct logical direction.
- Repeat systematically: verify each drivetrain motor and record its Normal/Reversed setting.
- Check your saved project: close and reopen it, confirm the generated devices and user code remain in their correct sections.
- Explain the distinction: tell a partner why selecting a different cartridge in software does not physically change the motor’s gearing.
Success evidence
A saved project, an accurate port map and a short test log naming each motor, cartridge, reversal setting and observed output direction. All user code remains below # Begin project code.
OFFICIAL REFERENCES
- VEX guide: configure motor ports, cartridges and direction
- VEX guide: change a physical motor cartridge
- VEX V5 Python motor API
- Official VEXcode V5 downloads
Follow the current VEX instructions if your interface differs. This is an independent learning resource; VEX and VEXcode are trademarks of their respective owners.