The VEX IQ Smart Motor has many functions to use when coding in VEXcode IQ. This can come in handy when coding arms, claws, and intakes as well as drivetrains and other mechanisms created using VEX IQ. Understanding how the motors can be coded will help to alleviate issues such as projects stalling or motors not working as intended.
Motor Encoder
Not only does the VEX IQ Smart Motor turn electrical energy into mechanical energy, as most motors do, it also has features that most motors do not have, which make it “smart.” One of its main features is the quadrature encoder. This encoder is mounted on the interior of the motor in order to track the speed and/or the position of the motor shaft.
Reports from the VEX IQ Smart Motor’s encoder make it possible to know:
- The direction of the motor’s turn (forward/reverse or open/closed)
- The position of the motor and the amount of the motor’s turn and position (either in turns or degrees)
- The speed of the motor’s turn (based on the encoder’s position over time)
Because the encoder reports the motor’s states, they can be used in behind-the-scenes calculations to make many of the Motion and Sensing commands work within the VEXcode IQ.
Coding Individual Motors
Before beginning to code individual smart motors in VEXcode IQ, you need to configure the motor. Individual motors are frequently used for additional mechanisms like intakes, arms, and claws. However all of the information does still apply to other mechanisms using individual motors.
Follow the steps in this article to configure your individual motor in VEXcode IQ.
With a single motor configured, commands to control that motor will appear in the Toolbox. You will notice there are different types of commands: waiting and non-waiting.
Waiting versus Non-Waiting Commands
Note that all of the images here show blocks. All of these projects can be rebuilt in Python or C++ and contain the same functionality as blocks.
Waiting commands block the project from continuing until the behavior is completed. These include commands such as [Spin for] and [Spin to position].
The project shown here uses a Clawbot (2-motor) template and all of the commands are waiting. So in series, the claw motor would close 90 degrees, the robot would drive in reverse, then the arm would spin up to reach position 180 degrees.
In contrast there are non-waiting commands. A non-waiting command will execute the behavior indefinitely or until told to change to another behavior. These include commands such as [Spin].
The project shown here uses a BaseBot with an intake added. Here the intake motor would begin to spin. The [Wait] command is a waiting command, so the intake would continue to spin until the 2 seconds were up, then move to the next command in the project which is a [Stop] command. Then the motor would stop spinning.
Motor Timeouts
When coding a motor as part of an arm or claw, it is important to remember the difference between waiting and non-waiting blocks and how those will impact the movement of your robot. Motor timeouts allow you to set a time limit for the motor to reach the intended target position. If it has not met that position when time expires, the motor will stop trying to spin and the project will move to the next command.
In this example, the motor timeout is set to 2 seconds. If the claw does not close to 90 degrees within 2 seconds, the motor will stop spinning at the 2 second mark then move to the next command and drive forward.
If you are unsure of how far to move a motor, use the sensor dashboard. The dashboard reports the position of the motor in degrees and revolutions, so as you move a motor (like opening and closing a claw) the numbers will change. Use this testing to determine how many degrees or rotations is needed to close a claw, raise an arm, spin an intake, etc.
See these articles to learn how to use the sensor dashboard.
Coding Smart Motors as Part of a Drivetrain
Before beginning to code a drivetrain in VEXcode IQ, you need to configure the drivetrain including the motors used. The motors are configured within the drivetrain to ensure they are controlled with the same commands like [Drive] and [Drive for].
Waiting and Non-Waiting Commands
When coding a drivetrain, waiting and non-waiting commands are available to control the movement of the robot.
Waiting commands block the project from continuing until the behavior is completed. These include commands such as [Drive for] [Turn for], and [Turn to heading].
The project shown here uses a Clawbot (2-motor) template and all of the commands are waiting. So in series, the robot would drive forward for 200 millimeters then turn right all by using the drivetrain.
In contrast there are non-waiting commands. A non-waiting command will execute the behavior indefinitely or until told to change to another behavior. These include commands such as [Drive].
The project shown here uses a BaseBot. Here the robot would drive forward indefinitely until the Bumper Switch was pressed. Then the project would move to the next command and the robot would stop driving and turn right for 90 degrees.