Archive for the ‘vex’ tag
Live Broadcast of the National Mexico VEX Tournament
Check out the live broadcast of the National Mexico VEX Tournament going on now! All of the teams are using ROBOTC. The broadcast is brought to you by Reeduca, a company dedicated to implementing new technology and robotics education in Mexico.
ROBOTC 3.59 BETA is Here!
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 3rd 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 3rd 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.
FTC Ring It Up and VEX Sack Attack v1.50 Now Available!
Following up from an earlier post, new versions of the FTC Ring It Up and VEX Sack Attack Virtual Worlds are now available!
In version 1.50 of Ring It Up, all arm, wrist, and gripper motors now include encoders, allowing you to get feedback and implement precise control over the robots. We’ve also swapped the Compass Sensor for the Gyroscope, which was highly requested by FTC teams. New Sample code for the encoders and gyroscope is installed with the world.
In version 1.50 of Sack Attack, we’ve added encoders to the arm motors on all of the robots, and a potentiometer to the scooper motor on Scooperbot, giving you very precise control. All robot models have also had the Compass sensor replaced with a Gyroscope, better aligning them with the real world VEX system. As with the Ring It Up world, Sample code for all of the new functionality is included.
We genuinely appreciate all of the feedback and comments we’ve received about these worlds, and we hope that these changes show that we’re listening. Keep the feedback coming!
Adding support for all of the new inputs required a significant update of our back end, so these versions require ROBOTC 3.54 or later to be installed. Happy programming!
RVW Update: VEX Sack Attack v1.2.1 Now Available!
Attention all VEX teams! We just released a substantial update to this year’s VEX Sack Attack virtual world. Download it here, or on the RVW Level Packs download page. Here’s what’s new:
New Robot: Clawbot
- Clawbot features a 4-wheel, 2-motor drive system, an arm motor, a gripper, and the full array of sensors. Best of all, it’s fully programmable in ROBOTC!
- Additional sample code for Clawbot is installed with the update, and can be downloaded here.
Pre-loads and Automatic Scoring
- Both Gripperbot and Scooperbot can be pre-loaded with a sack! You can control what side the robot starts on, whether it gets a pre-load, and enable the autonomous duration all from the main menu.
- Scoring is fully implemented in this new version.
- Earn normal points from sacks, bonus points from bonus sacks, and even more bonus points from the autonomous bonus and “parking” your robot before time runs out.
- A cool, new timer and scoreboard keeps track of the match in the top-left corner of the window. Compete with your classmates or teammates to see who can get the highest score before time runs out!
- Driver Control loads are also implemented once the autonomous period ends. Introduce them into the playing field by clicking on the green sack icons in the top-right corner.
Sensor View
- Ever wonder why your Ultrasonic sensor “sees” the values that it does? Enable the new Sensor View to see what’s triggering the Ultrasonic sensor and the heading of your compass.
Additional Enhancements
- We’ve improved the robot-sack interaction on all of the robots.
- The lighting and contrast of the game have been enhanced, making it easier to grab and score the sacks.
- Lots of small tweaks and adjustments.
To view the original post for the VEX Sack Attack virtual world (complete with video), visit this link.
VEX Sack Attack Referee Training Videos
John and Karthik at VEX Robotics have put together a fantastic set of videos for teams competing in the VEX Sack Attack Robotics Competition.
The 9-video series breaks down the rules for the competition, and shows how referees will interpret the different scenarios that may occur. It’s definitely a worthwhile watch for any teams competing this year (or anyone who wants to see John hug this years game object).
You can watch the full video series here, or on their YouTube page: http://www.youtube.com/playlist?list=PLEC832168771665F2
VEX/Arduino Bot Chases the Light
Close up of the ‘Scaredy Bot’. Note the two VEX Light sensors side by side that provide the control for the robot’s movement.
When someone thinks “robots’, they generally think of cold, calculating, emotionless machines. This couldn’t be further from the truth; all robots, from the complex humanoids to the basic welding arms seen in car plants, have complex and deep emotional personalities.
For instance, take a look at our new “Scaredybot”. Built entirely from VEX parts, an Arduino, and the sweat of our intern Dan West (by the way, great work Dan!), the Scaredybot is so ‘brave’ that it cannot stand being in the dark; given the choice, it will either chase a light source for dear life or spin blindly in place (desperately seeking a respite from the darkness).
On the technical side, the Scaredybot uses two VEX Light Sensors to compare light values on the left and right side of the robot and turns the robot towards whichever side is higher. By constantly moving side by side using swing turns (much like a line-tracking robot), the Scaredybot is able to track the light source as long as its sensors are able to read the light values. When the Scaredybot loses its light source, it spins in place until a light source is found again, at which point it starts to track it again.
RC Car to Arduino Robot – First car converted!
The Arduino is one of the most diverse robotics platforms. It truly opens the world of modern electronics to the students by allowing them to interface with all sorts of relevant, modern technology. We have seen this unfold in our latest project with the Arduino, the RC car hacking project.
For this project, we decided a good candidate to start with would be the New Bright RC ‘Interceptor’, a larger scale car that fit a standard-sized Arduino (in this case, an UNO) and a breadboard with lots of room to spare. This surplus of space opens up tons of options for adding sensors in the future. Plus, by tapping into the car’s standard battery we eliminated the need to add a second one. Since we needed to be able to control the RC car’s DC motors with the Arduino, we decided to use the VEX Motor Controller 29 to convert the PWM signals into corresponding voltage levels. This solution was cheap, easy, and effective; a true engineering triple play.
Once the Arduino was implanted into the RC car, it was time to tell the newborn robot to do something. Of course, we did this using our favorite programming software, ROBOTC for Arduino (more on this later).
Close up on the hacked internals of the 'Interceptor'.
It is important to realize that while most robots have a tank style drive system, the RC cars have the same steering system as that found in real-sized cars (Ackermann Steering). This unfortunately eliminates the possibility of making point turns, but it does open the doors to other interesting opportunities such as parallel parking (we plan on showcasing this in a later update).
Besides being incredibly awesome, this project also helps to expand upon the superb flexibility of the Arduino and VEX systems; although not specifically designed for one another, they can easily be used together with little or no modification to either system.
We could never allow you, the reader, to miss out on the hacking. If you are interested in this or any of our other current projects, we encourage you to take a look at the tutorials on our wiki. At the moment they are works-in-progress, but we are well on the way of having step-by-step guides for hacking a variety of vehicles, with different scales and sizes, and different methods of operation. We ultimately want the tutorials to act as guides to hack any RC vehicle, even if we do not cover it specifically.
Keep an eye on this blog and our wiki for the latest updates. If you have any hacking stories, we’d love to hear about them on our forums. Good luck, and get hacking!
Basic Electronics and Arduino: A Winning Combination
Electronics is an integral part of innovation, yet many electronic classes across the United States are being closed because of NCLB(1) and ever-shrinking school budgets. However, more and more schools are instead opening robotics courses. With the Arduino platform we saw an opportunity for educators to integrate basic electronic principles into existing robotics courses using the VEX, LEGO, and BoE hardware. Fortunately, Arduinos are very inexpensive and can be used not only as a mobile robot controller, but to create lots of other “smart” stuff as well.
Arduino on a NXT platform
The Arduino exposes students to a basic microprocessor concepts, prototyping on a breadboard, and basic electronics concepts through many cool projects. The Arduino takes the processor ‘out of the box’ and gives students the opportunity to ‘build from scratch’ electronics systems. To augment these features, we’ve developed lessons around LEGO, VEX, and the BoE bot at our ROBOTC wiki and by the end of the summer we will have a set of plans that allow students to turn a RC car fully autonomous. We have a team of folks dedicated to creating a series of lessons that makes teaching electronics through robots fun and easy, all while using technology that is already in your classroom.
In this regard, we have a very broad range of projects in mind for ROBOTC for Arduino; everything from basic LED control to creating homebrew sensors is covered. The end-goal for this research and development project is to expose students to a broad range of basic electronic concepts from simple circuitry to digital input (on/off switches) to analog inputs (potentiometer) to PWM concepts. As we continue to develop our ROBOTC for Arduino support materials, we need your help. We are asking you, the ROBOTC community, to recommend projects that you are working on and are willing to share with educators and hobbyists. Please consider sharing your project ideas and we will be glad to post them on both our blog and wiki. As always, keep an eye on our forum, Facebook, and Twitter pages for the most up-to-date news. Thanks!
Arduino on a BoE-bot platform.
Arduino on a VEX platform.
Major Improvements in ROBOTC 3.05 for VEX Cortex
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.
VEX Mecanum Drive using ROBOTC
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.
