ROBOTC.net Blog  

Martin Mason, professor of Physics and Engineering at Mt. San Antonio College and ROBOTC user, has developed a new VEXduino Shield. He created a board that you can plug in VEX sensors but, combined with ROBOTC, uses an Arduino to control the robot instead of a Cortex or PIC. Combining the Shield with an Arduino, some VEX parts, and a small breadboard is a perfect recipe for teaching electronics with the ROBOTC for Arduino!

Read the rest of this entry »

The ROBOTC team is happy to announce the ROBOTC 3.59.0 BETA release. We’ve made a number of enhancements and repaired a number of user issues. Some of the major updates are:

• Added support for proxy server when activating ROBOTC.
• Add watchdog timer support to VEX Cortex to alleviate processor crashes that can occur with static.
• Fixed a bug in the NXT color sensor that now allows you to read individual RGB values.
• Updated with the latest version of the 3^rd party sensor drivers for NXT. (Thanks Xander!)

See below for the more detailed changelog. You can download ROBOTC 3.59.0 here!

Remember, we could not do this without your support and feedback. We hope you’ll continue to share your comments with us, either in the forums or on our Facebook or Twitter page.

3.54 to 3.59 BETA Changelog

VEX:

• Add watchdog timer support to VEX Cortex. This will allow the VEX Cortex User Processor to “restart” automatically once the processor crashes/is halted. Useful for any potential static issue that may cause the User Processor to “crash”.
• Change watchdog implementation from “windowed” watchdog to standard watchdog (no window, reset any time). Increase watchdog timeout to 0.75 seconds.
• In Debugger Motors display the last motor was not always properly updated. Fixed.
• Enable emulator for VEX PIC. Fix subsequent bug with “Motors” debugger display for VEX PIC locking up IDE when emulator is enabled; this bug should be limited to VEX PIC Emulator only.
• VEX PIC downloading was failing when master firmware was out of date. Getting stuck in a repetitive loop that wasn’t exiting. Fixed.
• VEX PIC was not executing user programs. Bug was that “start of flash file system VTOC” needed to be aligned on 4-byte boundary. Previous change had added a 1-byte field to the header preamble and there was not a corresponding 3-byte file added for VEX PIC. ARM platforms worked OK. This may also have broken Arduino (i.e. any 8-bit) platform).
• Added a Conditional Compile flag for tUARTs to avoid confusion between uartOne and UART1
• There are two separate flags for “allow any serial port for communications” — one for VEX Cortex and one for all other platforms. This was not obvious. Preferences “Environment” tab was only updating flag for non-Cortex; this has been changed to update the appropriate flag based on platform setting. The VEX Cortex flag can also be updated in the “VEX Cortex” tab.
• User configurable UART setup was screwed up for the platforms whose “uart 0″ is fixed as non-configurable and usable only for system communications port to PC — i.e. VEX Cortex, VEX PIC. The ROBOTC IDE was storing the data in the persistent data table (at start of flash file system) offset by one entry. I.E. data for “uart 1″ on VEX Cortex was stored in “uart 2″, etc.

LEGO:

• NXT color sensor read RGB individual values broken with pointer implementation. Change “getMemoryParmXXX” function calls to “getCommonParamaterValueXXX” function calls. Check rest of firmware for same mistake.
• New feature for 3^rd Party Sensor Driver Suite to set the two digital I/O lines on NXT sensors. Added two new sensor types (sensorCustom, sensorCustom9V) for this along with two new property intrinsic variables to set I/O line direction and values; these intrinsic variables are bit masks (2-bits) for the two lines.
• “setPixel” intrinsic (and corresponding “clearPixel” and “invertPixel”) take “unsigned” parameters. But implementation was using “signed” parameters and not properly range checking if parameters were negative. If negative, then should do nothing. Instead they were incorrectly wring to invalid buffer address which eventually caused a firmware crash.

Arduino:

• Fix issue for “Motors” tab for Arduino in “Motors and Sensors Setup” property sheet. Was incorrectly trying to setup “encoder information for motor”, but Arduino platform does not “associate encoder sensor with motor” — which is currently only a feature for VEX Cortex.

General:

• Added Support for Proxy Server when activating ROBOTC – Users can set Proxy preferences under “Detailed Preferences – General – Environment”.
• Incorrect generation of compiler error message when double pointer (i.e. “**”) is used.
• “Print” a range of pages was not working when the starting page was not ’1′. Fixed.
• Remove incorrect error message from error “Assignment between two different pointer types” when one side of ‘=’ is a ‘void *’.
• Compiler was incorrectly generating error message for “Expected a pointer expression in a pointer expression with ‘++’ or ‘-+’ operand. Compiler was incorrectly checking to verify the right operand was an integer value.
• Compiler was incorrectly generating error message for “Invalid pointer expression” in a pointer expression with ‘+’ or ‘-’ operand. One operand of the expression must be a pointer and the other operand must be an integer (without implied conversion of a pointer to an integer). Compiler was incorrectly checking for the integer — the expression incorrectly had a “!” in it!
• Change code generation of ‘var arg’ for pointers to be consistent with standard C — i.e. the value of the pointer is placed in the argument. This may result in an additional instruction generated when argument is a ‘string’; previously RobotC got too cute trying to save this extra instruction which only worked for “%s” format codes but was broken for “%d” on a pointer.
• In ‘sprintf” implementation for “%s” and “%p” format codes– change from  “get Address of parameter” to”get value of parameter” to match corresponding change in compiler code. Also minor cleanup of “%s” and “%p” format codes.
• Assignment expressions of “<char * variable> = <char constant> were generating compiler error because the “<char constant>” was evaluated as a “string” type. Added code in “get expression type” to check for this and not generate error as the compiler auto converts “string” to “char *” during code generation.
• Fixes an issue with the Live Start Page and “check for updates” that may have caused crashes.
• Improved validation of pointer expressions. Fix bug in calculating expression type of pointer expressions like “<ptr sub-expression> + <numeric constant>”; the result was (always?) incorrectly set as “long *”? Also added check that “=” of pointer is from a pointer of the same type – otherwise generate error message.
• Fixed consistency in implementation of “random” intrinsic property.
• Eliminate compiler error message in constant expression evaluation of sub-expressions using “*” operator. If either of the two operands is ‘zero’ then result is zero regardless of whether the other operand is a compile time constant.
• Do not generate additional errors — “too many parameters” specified — when procedure is “compiler generated undefined symbol”.
• When switch between “real robots” and “emulator”, the function that calculates “size of RAM pointer variable” was not being called. It adjusts between 2-byte (VEX PIC, Arduino) and 4-byte (Emulator, VEX Cortex, NXT) pointer sizes. No issue with VEX Cortex and NXT as they only use 4-byte pointers. But a problem with VEX PIC and Arduino where real robots use 2-byte RAM pointers! Added the appropriate call to function setup.
• Small code optimization for “postfix –”/postfix ++” operators to avoid temporary. In some cases they can be simplified to prefix operands.
• Incorrect initialization of static variables in “inner scope” for local procedure. They were initialized every time inner scope block was accessed rather than once on program startup.
• Debugger Panes for “Locals” and “Globals” (especially Globals) was not properly handling updates to ‘long’ and ‘float’ variables. Globals was completely broke — only lower two bytes of 4-byte variables was being updated which broke ‘long’ and ‘float’ variables. In both, ‘char’ variables were updating a short value — i.e. overwriting following characters.
• Fix problem with incorrect user code using a “short” variable and “sprintf” format code of “%f”. This can crash ROBOTC VM firmware if the short variable is not aligned on a 32-bit boundary.
• Add additional entries for StringFind for Character Constants and added test program.
• Redefine datalog opcodes and intrinsics. Legacy datalog incompatible with 3.5x VM operands which split memory variables and intrinsic properties into separate items.
• Firmware for all platforms now call “datalogHandlerInit()”. Conditional compile will define as NULL macro if a platform does not support Datalog. Datalog support is now conditionally compiled via “bHasDatalog” define rather than hard-coded as NXT only.
• Fix incorrect compiler type checking error when string constant is assigned to a char pointer.
• Fix bug in check for “is this a preprocessor string comparison expression”.
• Eliminate preprocessor string comparisons in Natural Language and replace with “defined(_Target_XXX_) where “_Target_XXX_” are three new system defined preprocessor variables — “_target_Robot_”, “_Target_Emulator_” and “Target_VirtWorld_”. Sample programs modified appropriately. Legacy user programs using legacy definitions will still work but will generate a compiler warning about non-standard extension.
• Add registry flag to enable compiler extension to allow preprocessor expressions support for string comparisons. Generate compiler error message if encountered without the flag being set.
• “cast” code generation fix. Previously when cast changed sign of result the ‘cast’ was applied before expression was converted to ‘int’ size used during a calculation. So casting a “ubyte” to “int” incorrectly converted it to a “signed char”. What should happen is “ubyte” expression gets evaluated into an “int” as part of expression evaluation (all expressions are evaluated at ‘int’ (or higher) level in “C”) and then the cast to “int” has no additional effect.
• Function to extract numeric “COMxxx”. Expanded syntax to support successful parsing of “(COM99)” previously would not accept extraneous characters.
• Add improved Dialog for selecting Communications Port. It uses a list box to display information about the port. Add check box to select any communications port.
• Compiler crash when parsing invalid syntax of ‘?’ expression. Compiler was not handling the case when “NULL” pointer returned from parsing sub-expression. The “NULL” was incorrect.

Do you get hungry? Do you enjoy eating food more than you enjoy making food? If you answered “Yes!” to both of those questions, you’ll be happy to know that the future engineers of America have you covered.

Students from two Project Lead the Way (PLTW) Schools have integrated the sensing and control capabilities of the VEX Cortex Robotics system with the advanced articulation capabilities of the LynxMotion Robotics system to create highly capable (and delicious) assembly lines.

The first two videos are brought to us by students in a Computer Integrated Manufacturing (CIM) class at Kings High School in California.

Robotic Sandwich Factory:

Buttered Toast Factory (complete with real-life toaster):

The work behind the last two videos was done by students in another CIM class at Lancaster High School in New York.

Coffee Manufacturing Line:

Widget Assembly Line:

Well done to all the students involved, and to the instructors that inspired them. Keep up the great work!

If you’re looking for more information, additional videos and explanation can be found on their respective YouTube channels.

VEX Robotics has released the following information on their website:

The VEX Robotics technical support team has identified an issue that some competition teams are experiencing in which the Cortex Microcontroller is unable to resume VEXnet link after a Microcontroller reset.

To help eliminate this issue at the VEX Robotics World Championship we are releasing a special version of the VEX Firmware, specifically for World Championship teams (3.21_Worlds). This firmware version modifies the Cortex re-initialization to help the VEXnet link reconnect in the event of a reset (i.e. caused by VEXnet Key “jostling”, power interruption, battery brownout, or static).

We know that competition teams dislike updating firmware so close to an event, so we are publishing this update in the hopes that teams will have a chance to test it “at home” before coming to VEX Worlds. If you’re comfortable with the new version, we strongly urge you to use it at the World Championship to help prevent potential problems related to a Cortex reset.

This firmware only updates a “back end” relinking protocol and it does not affect anything related to robot performance — you don’t need to tweak your autonomous mode, or anything like that.

Visit the VEX Forum thread on this firmware release for more discussions and to post any questions or concerns.

Download the 3.21_Worlds Firmware Update.

ROBOTC 3.05 contains a number of enhancements that should be very exciting for VEX Cortex users. This is a free update for all ROBOTC for Cortex and PIC users (yes, even if you were using 2.3x)!

The ROBOTC 3.05 installer now includes the VEX Cortex and Prolific USB-to-Serial drivers. You no longer need to remember to download and install these separately.

We’ve heard your feedback! The new “Automatically Update VEX Cortex” option will detect if your Cortex is out-of-date, and automatically download the latest version of the Master CPU and ROBOTC Firmware files if needed. There’s no need to go through the long process of manually downloading each firmware, or put the VEX Cortex in “bootload” mode! The same functionality has been implemented for the VEXnet Joysticks as well.

Also included is a new version of the Master CPU Firmware from VEX Robotics. This version restores the functionality from the 2.x firmware, which allowed programs to run even when VEXnet was turned on (but not used).

New Standard Models! Standard models for the popular Robotics Academy robots and PLTW Training Testbeds have been added, and can be used to automatically configure all of the motors and sensors, hassle free.

New and improved sample programs! New sample programs for the VEX Mecanum Wheels and Line Tracking Kit have been added. others have been improved.

You now have the ability to give your robot a custom name. This will be a crucial enhancement for competition teams, and should be helpful for classroom settings, too.

One cool new product for the VEX Robotics system are the VEX Mecanum Wheels.

Where traditional wheels only allow your robot to move forward, backward, and turn, mecanum wheels allow your robot to  move in all four directions -  forward, backward, left and right, while still maintaining the ability to turn. Your robot is able to accomplish this thanks to their unique design. Each wheel (which must be connected to its own, independent motor) contains rollers offset by 45 degrees from the wheel and the robot’s drive train. Instead of the motors introducing force in just the forward-backward directions, each wheel introduces force at 45 degree angles (45, 135, 225, 315). The force vectors of the different wheels can then be combined and/or cancelled out to create motion in the X and Y axis.

Here’s video of the Mecanum wheels in action (the code running on the robot can be found later in the post):

To give the wheels a test run, we built the robot below. Notice that if you’re looking down on the robot, the spokes or rollers of the wheels should point inward to create an X. If you’re looking at the bottom of the robot, they should point out to create a baseball diamond. There are two sets of two wheels - all four are not identical.

When you decide to incorporate your own mecanum drive system, be sure to follow the X/diamond rule or your robot will not behave as expected. Also know that equal weight distribution and consistent build quality are far more important when working with a mecanum drive. Remember that the robot moves based on adding and/or cancelling out the different force vectors produced by the four individual motors – if one or two motors can’t match the others the entire motion of the robot will be thrown off.

A fairly simple program can be written  to test the mecanum drive system. This program will use the left joystick on the remote control to move the robot forward-backward and right-left. The X axis on the right joystick will control the rotation of the robot.

#pragma config(Motor,  port2,           frontRight,    tmotorNormal, openLoop)
#pragma config(Motor,  port3,           backRight,     tmotorNormal, openLoop)
#pragma config(Motor,  port4,           frontLeft,     tmotorNormal, openLoop, reversed)
#pragma config(Motor,  port5,           backLeft,      tmotorNormal, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

/*+++++++++++++++++++++++++++++++++++++++++++++| Notes |++++++++++++++++++++++++++++++++++++++++++++
Mecanum Drive - Basic
- This program allows you to remotely control a robot with mecanum wheels.
- The left joystick Y-axis controls the robot's forward and backward movement.
- The left joystick X-axis controls the robot's left and right movement.
- The right joystick X-axis controls the robot's rotation.

[I/O Port]          [Name]              [Type]                [Description]
Motor Port 2        frontRight          VEX Motor             Front Right motor
Motor Port 3        backRight           VEX Motor             Back Right motor
Motor Port 4        frontLeft           VEX Motor             Front Left motor
Motor Port 5        backLeft            VEX Motor             Back Left motor
--------------------------------------------------------------------------------------------------*/

task main()
{
//Loop Forever
while(1 == 1)
{
//Remote Control Commands
motor[frontRight] = vexRT[Ch3] - vexRT[Ch1] - vexRT[Ch4];
motor[backRight] =  vexRT[Ch3] - vexRT[Ch1] + vexRT[Ch4];
motor[frontLeft] = vexRT[Ch3] + vexRT[Ch1] + vexRT[Ch4];
motor[backLeft] =  vexRT[Ch3] + vexRT[Ch1] - vexRT[Ch4];
}
}

The program above, however, isn’t perfect. If the joysticks don’t center perfectly at zero, or if the driver unintentionally moves the joysticks along multiple axis, the movement of the robot will be thrown off. With a few variables and a little bit of logic, we can ignore these erroneous values and provide smoother control of the robot:

#pragma config(Motor,  port2,           frontRight,    tmotorNormal, openLoop)
#pragma config(Motor,  port3,           backRight,     tmotorNormal, openLoop)
#pragma config(Motor,  port4,           frontLeft,     tmotorNormal, openLoop, reversed)
#pragma config(Motor,  port5,           backLeft,      tmotorNormal, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

/*+++++++++++++++++++++++++++++++++++++++++++++| Notes |++++++++++++++++++++++++++++++++++++++++++++
Mecanum Drive with Deadzone Thresholds
- This program allows you to remotely control a robot with mecanum wheels.
- The left joystick Y-axis controls the robot's forward and backward movement.
- The left joystick X-axis controls the robot's left and right movement.
- The right joystick X-axis controls the robot's rotation.
- This program incorportes a threshold/deadzone that allows very low Joystick values to be ignored.
This allows the robot to ignore values from the Joysticks when they fail to center at 0,
and provides a margin of error for the driver when they only want the robot to move in one axis.

[I/O Port]          [Name]              [Type]                [Description]
Motor Port 2        frontRight          VEX Motor             Front Right motor
Motor Port 3        backRight           VEX Motor             Back Right motor
Motor Port 4        frontLeft           VEX Motor             Front Left motor
Motor Port 5        backLeft            VEX Motor             Back Left motor
--------------------------------------------------------------------------------------------------*/

task main()
{
//Create "deadzone" variables. Adjust threshold value to increase/decrease deadzone
int X2 = 0, Y1 = 0, X1 = 0, threshold = 15;

//Loop Forever
while(1 == 1)
{
//Create "deadzone" for Y1/Ch3
if(abs(vexRT[Ch3]) > threshold)
Y1 = vexRT[Ch3];
else
Y1 = 0;
//Create "deadzone" for X1/Ch4
if(abs(vexRT[Ch4]) > threshold)
X1 = vexRT[Ch4];
else
X1 = 0;
//Create "deadzone" for X2/Ch1
if(abs(vexRT[Ch1]) > threshold)
X2 = vexRT[Ch1];
else
X2 = 0;

//Remote Control Commands
motor[frontRight] = Y1 - X2 - X1;
motor[backRight] =  Y1 - X2 + X1;
motor[frontLeft] = Y1 + X2 + X1;
motor[backLeft] =  Y1 + X2 - X1;
}
}

Both of the above pieces of sample code will be included in ROBOTC 3.05. The VEX Mecanum wheels, along with all of your hardware needs can be purchased from the Robomatter store.

The VEX Robotics System includes a growing, powerful set of official sensors. That said, the electronics world is overflowing with other types of cool and useful sensors. The great news is, both the VEX PIC and the VEX Cortex microcontrollers are extremely versatile and can be used with many of these sensors. Both the VEX PIC and VEX Cortex can be used with Analog Sensors that operate between 0 and 5 volts (+/- .5 volts), and have Power, Ground, and Signal lines.

One such sensor is the Sharp GP2D12 IR Rangefinder.

The Sharp IR Rangefinder allows your robot to determine distance from the nearest object, much like the VEX Ultrasonic Rangefinder. Unlike the VEX Ultrasonic Rangefinder, which uses  sound waves to measure distance, the Sharp IR Rangefinder uses infrared light. On one side of the sensor an infrared LED shines a beam of light, which is reflected back by the closest object, and detected by the receiver on the other side of the sensor. The sensor then uses a method called triangulation to determine how far away the object was.

The basis for triangulation is that objects at different distances will reflect the infrared beam back to the receiver at different angles. The varying angles produce different voltage levels in the sensor, and in turn sensor values that can be used to calculate distance. See below:

The Sharp IR Rangefinder provides very reliable distance values ranging from 10 to 80 centimeters away. One big advantage with using the IR Rangefinder is that it’s not affected by soft for angled objects that cause the VEX Ultrasonic Rangefinder to fail.

One challenge with using the sensor is that the raw values provided do not directly correlate to useful distance values, and they’re also non-linear. This means that we must perform a calculation on the raw sensor data first. Documentation for the sensor tells us that we can calculate the distance using the following formula:

Voltage = 1 / ( Distance + 0.42 )

Which, when rearranged gives us:

Distance = (1/Voltage) – 0.42

One additional challenge is that we can’t directly access the voltage returned by the sensor in our program. What we can access is the sensor value, which is proportional to the voltage – we’ll just have to take a conversion factor into account.

Below is a sample program written for the Sharp IR Rangefinder. It contains the function “IRValue()” which will perform the necessary calculation and return the useful distance data, in centimeters. Note that the “sensorPotentiometer” type was used, since there is no “IR Rangefinder” sensor type in ROBOTC, and the Potentiometer type will return the full, unmodified analog data (unlike other sensor types like the Gyro).

#pragma config(Sensor, in5,    sharp,               sensorPotentiometer)
#pragma config(Motor,  port2,           rightMotor,    tmotorNormal, openLoop, reversed)
#pragma config(Motor,  port3,           leftMotor,     tmotorNormal, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

//Function uses data from the IR Rangerinder to calculate and return distance
int IRValue(tSensors sensorPort, float conversionFactor = .0000469616, float k = .42)
{
return (1.0 / (SensorValue[sensorPort] * conversionFactor)) - k;
}

task main()
{
wait1Msec(2000);
clearLCDLine(0);
clearLCDLine(1);

//While true...
while(true)
{
//If the robot is greater than 25 cm away...
if(IRValue(sharp) > 25)
{
//Move Forward
motor[rightMotor] = 30;
motor[leftMotor] = 30;
}
else
{
//Stop
motor[rightMotor] = 0;
motor[leftMotor] = 0;
}

//Display IR Sensor Data to LCD
displayLCDString(0, 0, "IR Value:");
displayLCDNumber(0, 9, IRValue(sharp), 3);
displayNextLCDString("cm");
}
}

Our Sharp IR Rangefinder was previously configured wired for an older microcontroller called the Handy Board. Like the VEX Cortex and PIC, it had wires for Power, Ground, and Signal, so we were able to use simple jumper wires to adapt it for the Cortex.

Front of the robot with Sharp IR Rangefinder:

Top of the robot, with connection from Sharp IR Rangefinder to VEX Cortex Analog Port 5:

And finally, here’s a video of the code from above running on the robot:

For more information on interpreting and using the data provided by the Sharp IR Rangefinder, check out this tutorial.

The new VEX Yaw Rate Gyro is one of the more sophisticated sensors in the VEX Robotics System – but it’s also one of the most useful and powerful. Among other things, the Gyro allows your robot to make very precise, consistent turns.

Other sensors, like the Shaft Encoders, allow you to control your robot’s turns… but indirectly. The Shaft Encoders can measure the rotation of the axles (or shafts) of your robot’s drive train. By monitoring how much the axles spin, you can also monitor and control how much your robot moves forward or turns. (As a side note, some great tutorials on using the Shaft Encoders to do just that can be found in the Movement section of the VEX Cortex Video Trainer.)

The Gyro, on the other hand, actually measures the rotation of your robot. Factors such as wheel slippage and varying surface friction that cause inconsistencies with Shaft Encoder-based turns are far less problematic with the Gyro; your robot will turn until it reaches the target you set – no matter how much the wheels slip or how long it takes!

#pragma config(Motor, port2, rightMotor, tmotorNormal, openLoop)
 #pragma config(Motor, port3, leftMotor, tmotorNormal, openLoop, reversed)
 //*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//

/*+++++++++++++++++++++++++++++++++++++++++++++| Notes |++++++++++++++++++++++++++++++++++++++++++++
 Gyro Based Turns - Basic
 -This program instructs your robot to turn for the specified number of degrees in "degrees10".
 -For best sensor results, clear out the gyro and manually configure it at the begging of the code.
 -The Gyro is configured by default to provide values from 0 to -3600 for clockwise rotation,
 and 0 to 3600 for counter-clockwise rotation

Robot Model(s): Swervebot

[I/O Port] [Name] [Type] [Description]
 Motor Port 2 rightMotor VEX Motor Right side motor
 Motor Port 3 leftMotor VEX Motor Left side motor
 Analog Port 8 in8 VEX Gyro Top-center mounted,
 away from the Cortex
 --------------------------------------------------------------------------------------------------*/

task main()
 {
 //Completely clear out any previous sensor readings by setting the port to "sensorNone"
 SensorType[in8] = sensorNone;
 wait1Msec(1000);
 //Reconfigure Analog Port 8 as a Gyro sensor and allow time for ROBOTC to calibrate it
 SensorType[in8] = sensorGyro;
 wait1Msec(2000);

//Adjust SensorScale to correct the scaling for your gyro
 //SensorScale[in8] = 260;
 //Adjust SensorFullCount to set the "rollover" point. 3600 sets the rollover point to +/-3600
 //SensorFullCount[in8] = 3600;

//Specify the number of degrees for the robot to turn (1 degree = 10, or 900 = 90 degrees)
 int degrees10 = 900;

//While the absolute value of the gyro is less than the desired rotation...
 while(abs(SensorValue[in8]) < degrees10)
 {
 //...continue turning
 motor[rightMotor] = 25;
 motor[leftMotor] = -25;
 }

//Brief brake to stop some drift
 motor[rightMotor] = -5;
 motor[leftMotor] = 5;
 wait1Msec(250);
 }

Here’s a video of the robot moving, based on the code:

And again, just in case you missed it, a more detailed explanation of the program can be found in this tutorial video:

The VEX Gyro can be purchased from the RoboMatter store.

Article written by Steve Comer

Remote control cars are great for having fun. They can be driven off-road, taken off jumps, and raced among other things. VEX robots are great for learning. They can be used to teach programming, math, problem solving, and other engineering skills. What do you get if you put them together??

Well, I can tell you. You get a rugged 4WD truck that is still tons of fun to drive around outside, but can also be used as a teaching tool.

Follow this link for more photos: http://s1081.photobucket.com/albums/j353/comeste10/VEX%20Rover%20Extras/

I started off with a MINDS-i Lunar Rover kit which is driven by a 7.2V DC motor and steered with a standard hobby servo. I removed the solar panel from the Rover and in its place put a VEX Cortex microcontroller and an LCD screen. On each side, I attached a VEX flashlight from the VEXplorer kit and I mounted an ultrasonic sensor to the front. It just so happens that VEX bolts and nuts fit quite easily into the beams of the MINDS-i rover.

I did all the programming in RobotC. See bottom of the page to view my RobotC code.

In order to control the stock motor and servo with the Cortex, I had to make a few modifications. I soldered the two wires to a 2-pin head which I then connected to the Cortex with a VEX motor controller.

For the servo, I used three single male-to-male jumper cables.

The video demonstrates the rover in autonomous mode where it makes use of the ultrasonic sensor to avoid bumping into walls. Remote control is also demonstrated using the VEXnet controller over Wi-Fi.

This is just a small sampling of the possibilities with this combination type of platform. Don’t let my initial direction limit you. It would be great to see some new combination robots. Get out there and start building!

This is my RobotC Code for the behaviors seen in the video.

AUTONOMOUS MODE:

#pragma config(UART_Usage, UART2, VEX_2x16_LCD)
#pragma config(Sensor, dgtl1,  sonar,               sensorSONAR_inch)
#pragma config(Motor,  port1,           L,             tmotorServoStandard, openLoop)
#pragma config(Motor,  port2,           servo,         tmotorNormal, openLoop)
#pragma config(Motor,  port3,           drive,         tmotorNormal, openLoop)
#pragma config(Motor,  port10,          R,             tmotorNormal, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//
/////////////////////////////////////////////////////////////////////////
//  Author  : Steven Comer//  Program : Rover drives straight until near an object, it then slows,
//            stops, then backs up and turns.
//  Updated : 8 June 2011 @ 10:20 AM
/////////////////////////////////////////////////////////////////////////
task main()
{

  //pause at start and turn on headlights
  wait1Msec(2000);
  motor[R] = -127;
motor[L] = -127;
while(true)
{
clearLCDLine(0);
    displayNextLCDNumber(SensorValue(sonar), 3);

    //++++++++++++++++++++++++++++++CLEAR++++++++++++++++++++++++++++++++
if( SensorValue(sonar) > 20 || SensorValue(sonar) == -1 )
{
motor[servo] = -2;
motor[drive] = 50;
}
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//+++++++++++++++++++++++++++++APPROACH++++++++++++++++++++++++++++++
else if( SensorValue(sonar) <= 20 && SensorValue(sonar) > 15 )
{
motor[drive] = SensorValue(sonar) + 25; //power decreases
}
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//+++++++++++++++++++++++++++STOP AND TURN+++++++++++++++++++++++++++
else if( SensorValue(sonar) <= 15 )
{
//stop
motor[drive] = 0;
wait1Msec(500);
//back and turn
motor[servo] = random[50] + 60;
     //random degree
motor[drive] = -50;  //random power
wait1Msec(1000);
}
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 }
}

REMOTE CONTROL MODE:

#pragma config(UART_Usage, UART2, VEX_2x16_LCD)
#pragma config(Sensor, dgtl1,  sonar,               sensorSONAR_inch)
#pragma config(Motor,  port1,           L,             tmotorServoStandard, openLoop)
#pragma config(Motor,  port2,           servo,         tmotorNormal, openLoop)
#pragma config(Motor,  port3,           drive,         tmotorNormal, openLoop)
#pragma config(Motor,  port10,          R,             tmotorNormal, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//
/////////////////////////////////////////////////////////////////////////
//  Author  : Steven Comer
//  Program : Remote control rover with VEXnet controller
//  Notes   : Throttle is Ch 2 (right joystick)
//            Steering is Ch 4 (left joystick)
//            Headlights are Ch 5U/5D and 6U/6D (on/off)
//  Updated : 10 June 2011 @ 12:30 PM
/////////////////////////////////////////////////////////////////////////
task main ()
{
 while(true)
{
//right headlight
if(vexRT[Btn6U] == 1)
motor[R] = -127;
if(vexRT[Btn6D] == 1)
motor[R] = 0;
//left headlight
if(vexRT[Btn5U] == 1)
motor[L] = -127;
if(vexRT[Btn5D] == 1)
motor[L] = 0;
//driving
motor[servo] = vexRT[Ch4];   //steering
motor[drive] = vexRT[Ch2];   //throttle
//LCD screen
displayLCDCenteredString(0,"VEX");
displayLCDCenteredString(1,"ROBOTICS");
}
}

No official vision system available for the VEX Cortex? No problem.

Thanks to some really cool work by Xander, I2C sensors for the NXT can now be used on the Cortex as well (with a little bit of effort). As we’ve covered in some of our previous posts, ROBOTC and the VEX Cortex unlock a ton of cool robotic applications – controlling pneumatics, controlling high torque and high speed motors through relays, outputting to the LCD screen, ect. Being able to use the repository of I2C sensors available for the NXT on the Cortex unlocks many, many more.

To demonstrate this, we’ve chosen the Mindsensors NXTCam. With the NXTCam, you’re able to connect it to a computer over USB and “teach” it to track up to 8 different colors. Once it’s hooked up to your robot, it returns data related to the colors it’s tracking – size, x and y positions, ect. This make it ideal for tracking a colored object, distinguishing between multiple different colors, and even advanced line tracking (more on that in a future post).

In this video, we’ve trained the NXTCam to track the color red. ROBOTC code uses the data from the camera to center the robot on the red ball and drive up to it until it’s within a certain distance.