ROBOTC.net Blog  

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.

Miniaturized SPRAT model controlled by 3 NXT bricks using ROBOTC.

ROBOTC community member Didier Coll has created more than a few awesome robots. In the past couple of months, though, he has made some truly spectacular bridge-laying robots using ROBOTC over multiple NXT bricks.

The first creation is an AMX-13 type bot, which (unlike the other two robots) carries the bridge on its front. Like the MLC-80 though (below), the AMX-13 is programmed to place the bridge and then drive across: it uses 2 motors and 8 actuators controlled via 2 ROBOTC-coded NXT bricks to achieve this goal.

The second robot is based off of the French Army’s current EFA design. Much like a real EFA, the robot drives to the middle of the ‘river’ and extends the folded bridge sections using a series of LEGO pistons; the robot stays in the middle of the bridge and the other robots effectively drive over it. The EFA model uses 2 NXT’s, 3 Multiplexors, 4 motors, and a staggering 10 actuators to perform this task.

Didier’s final robot is a replica of the SPRAT MLC-80 used during WWII. It uses 3 NXT bricks, a whopping 9 motors, 9 actuators, and 5 servos to place the bridge and drive across it, all controlled by ROBOTC for MINDSTORMS. A sample of the ROBOTC code used for this robot is below.

#pragma config(Sensor, S1,     HTIRL,          sensorI2CCustom)
#pragma config(Sensor, S2,     PSPNXV4,        sensorI2CCustom)
#pragma config(Motor,  motorA,           ,             tmotorNXT, openLoop)
#pragma config(Motor,  motorB,           ,             tmotorNXT, openLoop)
#pragma config(Motor,  motorC,           ,             tmotorNXT, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//
///----------------------------------------------------------------------------
/// didier  TWO MASTER SLAVE NXTBee modèle
//  NXT MARRON
///
///
///----------------------------------------------------------------------------

#include "drivers/mindsensors-ps2ctrl-v4.h"
#include "drivers/hitechnic-irlink.h"
#include "ROBOT DATA SPRAT 3 NXT ONE.h"
#include "didier GESTION SPRAT 3 NXT ONE.h";

///////////////////////////////////////////////////////////////////////////////

task main()
{
bNoPowerDownOnACAdaptor = true;   // will NOT power down when connected to AC adapter

bFloatDuringInactiveMotorPWM = false;  // the motors will NOT coast when power is not applied

StartTask (ROBOTData);
StartTask (gestionSPRAT);

while (true)
{
wait1Msec(10);
}
}

Want to see more pictures, videos, and information on these bots? Have any thoughts, comments, or questions? Check out Didier’s forum posts (links above) or comment below!

Looking for an awesome opportunity to test your ROBOTC skills this spring? Our friends at Parallax have the solution: the 2013 National microMedic Contest. The microMedic contest challenges participants to create cool, open-source medical devices powered by microprocessors and sensors. To motivate inventors to think outside-of-the-box, the microMedic challenge is giving away 100 free contest kits on a first-come, first-served basis and is also offering prizes to the winners of the contest (over $25,000 rewarded across 25 total winners). There are no restrictions on hardware or programming languages, so this is the perfect opportunity to hone your ROBOTC expertise with the VEX, LEGO, or Arduino platforms. For more information, please see the contest’s article on CS2N or the contest homepage on Parallax’s website.

“The U.S. Army’s Telemedicine and Advanced Technology Research Center (TATRC), Carnegie Mellon University Entertainment Technology Center, and Parallax Inc are offering over $25,000 in prizes to inspire the next generation of medical innovation. The 2013 National microMedic contest is an opportunity to show the country what citizens can do with new technology – encouraging technical innovation with significant use of microcontrollers and sensors in the medical industry. This contest is perfect practical application for STEM (Science, Technology, Engineering, Math) students around the nation.

The 2013 National microMedic Contest will create significant interest around new open-source medical applications. TATRC’s Dr. Brett Talbot, Medical Simulation Portfolio Manager, says about the contest “we’re looking for microcontroller-based projects for the health and medical simulation community that combine the latest use of sensors, 3D printing, CNC and science disciplines. This is a call to action for inventive people to put our skills to use for the benefit of Army personnel and civilians.”

Inventors and students are encouraged to participate by creating medical applications and products for possible use in the healthcare industry, medical simulation training, and the battlefield. STEM teachers are encouraged to get their classes involved. Over 100 free contest kits valued at over $40,000 will be given away on a first come first serve basis to qualified applicants. Use your favorite microcontroller or apply to receive a free kit that includes either the Parallax multi-core Propeller chip or a shield for use with the Arduino microcontroller. The kit also contains various sensors, LED displays, infrared emitters, a blood pressure cuff, heart rate monitor and many other components to spark your imagination. Use of the official contest kit is not required to win.

To help get competitors started Parallax Inc. is hosting resources such as mini tutorials with code examples for sensors, lists of application ideas and an online discussion forum specific to the microMedic National contest where contestants can ask questions and collaborate. Applicants have until July 31st, 2013 to submit their microMedic entries. Over $25,000 in prizes will be awarded to 17 educational winners and 8 winners from the public category. The award ceremony will be held in September 2013 at the TATRC Innovation Lab in Fort Detrick, MD. For more information on the 2013 microMedic Contest visit Parallax’s website.”

The Robot Virtual World team is thrilled to announce their latest level pack:  Robots to the Rescue – Operation Reset.

Robots to the Rescue – Operation Reset is the third version of our virtual world set in a crystal mining colony on Planet H99. An intergalactic storm has knocked out all of the systems in the colony, and it’s up to you to program the colony’s robots to restore power to Communication Towers, collect the Unobtanium energy crystals, and refuel the rocket. In game testing, some of the things middle and high school kids said were “It’s fun!”, “It’s like a video game!”, “I like that I get to see my code work immediately.”, and “I like the story behind the missions.”.

Operation Reset represents several months of hard work on new features and huge improvements to the Robot Virtual World technology. Here’s sneak peak of some of them:

Updated robot models with attachments:
Programmers will enjoy more interactivity with the world than ever before. Our Mammalbot (right) and Buggybot (left) robots are both included, and each have a Gripper and Vacuum attachment for delivering fuel barrels and collecting Unobtanium fuel crystals.

In-Game Tutorials:
When starting the first set of missions, players are presented with slideshow-style tutorials that explain the mission ahead and direct them to sample ROBOTC code they can use. All of the missions are designed to be solvable using either Standard ROBOTC or the Natural Language, so new and experienced programmers alike will enjoy solving the them.

Multiple Starting Points and Remote Control Zones
As players recharge the Communication Towers in the colony, they will unlock additional Mission Insertion points in the world. These insertion points allow the programmer to have consistent starting points as they write code to solve missions. Also, when a Communication Tower is recharged, direct robot control (using keyboard keys) in the nearby zone is unlocked, allowing you to remotely control the robot’s movements. Insertion points and remote control zones are displayed using the in-game Dashboard, which updates to reflect player progress.

Advanced User Interface
The brand new user interface conveys tons of information while taking up a minimal amount of screen space. As players complete missions, the “bubbles” corresponding to Communication Towers, Unobtanium Crystals and Fuel Barrels will be colored in. You can also switch between the Vacuum and Gripper attachments on the robot, change starting locations, and view recent in-game messages.

New Interactive Game Elements
As the robot travels through the mining colony, it will interact with new Bi-Directional Boost Pads (top) and Robot Lifts (bottom). Both elements will re-situate the robot in the world, providing consistency each time you run your code.

CS2N Achievements
When the robot completes missions or interacts with different in-game elements, the programmer will be rewarded with achievements. Users can create a Local account or use their CS2N account to track their progress and view their achievements. If you don’t already have a CS2N account, you create one for free, here: https://www.cs2n.org/signup

Gameplay Media and Support Material at RobotVirtualWorlds.com
We really want to make sure you know all of the support material that has been created to go along with Operation Reset. We’ve generated Getting Started Guides, Lesson Plans, and Programming Rubrics that will help you use the Robot Virtual World software in the classroom. The full set of materials can be found at http://www.robotvirtualworlds.com/ under Getting Started. Check out the site to find Gameplay videos, Mission Overview videos, World Maps, and more!

To download the Operation Reset virtual world, visit https://www.cs2n.org/activities/robot-virtual-worlds/operation-reset (log in with your CS2N account to view the download link) or http://www.robotvirtualworlds.com/. We value your feedback! Post any thoughts or ideas you have about Operation Reset at the ROBOTC.net forums.

Using Operation Reset requires a ROBOTC 3.x license. If you’re still using ROBOTC 2.x, check out our special promotional pricing available through the end of the year.

Back in April, we did an unboxing for the VEX Cortex Speaker which we blogged about, here.

Since then we have had many requests for an updated guide on how to play custom audio files through the Cortex Speakers. Today, the wait is finally over. We have updated our wiki pages to include an in-depth guide on how to convert a sound file into a Cortex-usable format using the open source program, Audacity [link].

Once the file is formatted and downloaded to the Cortex properly, the ‘PlaySoundFile(“filename.wav”)’ command is used to access the audio file and play it through the speaker port (example shown below).

task main()
{

//Play a Sound File (need to use the File Management to Upload First)
PlaySoundFile("1.wav");
wait1Msec(1000);

}

If you are interested in the Cortex Speaker and what can be played through it, check out the VEX forum post about playing Nyan Cat through the VEX Cortex speaker. As an added holiday bonus, how about the 12 Days of Christmas?

We are continually updating and improving all of our support material; if there is anything you think would make ROBOTC more accessible, don’t hesitate to comment below!

This is the first in a series of posts that will explain the new functionality behind the latest ROBOTC update. Beginning with ROBOTC 3.5 with all of the new functionality towards becoming an ANSI-C compliant language has brought some changes that may confuse veteran ROBOTC users. This week we’ll take a look at how global and local variables work in ROBOTC.

In previous ROBOTC releases, the compiler (the engine that converts your code from C-language to machine language) would treat all variables as “Global Variables” and would allocate (assign memory to) every variable when the program was compiled. This method caused issues because it would not allow the compiler to understand re-entrant functions (i.e. functions that could call themselves). This functionality was limiting because it prevent a key computer science concept called “Recursion” which is the ability to have a function call itself repeatedly (but not infinitely). Recursion is very useful when dealing with sorting data or calculating a series of data in different algorithms (one example: calculating a Factorial value – 5! = 5*4*3*2*1)

Example of Recursion: Calculating a Factorial Value

In ROBOTC 3.5, the compiler’s functionality has been extended in order to support recursive functions by supporting the concept of “Call Stack” variables. The idea of the Call Stack is that ROBOTC will now store local variables and return addresses of functions onto a Call Stack – This unlocks the ability to have recursive functions and variables that are truly “local”. With the Call Stack, ROBOTC is able to keep track of multiple calls of the same function and coordinate all of the variables so there’s no accidental overwriting of data or multiple copies of the same variables to keep track of – Everything automatically done by the compiler when the program is run!

A visual look at a “Call Stack” (from Wikipedia)

With the call stack, ROBOTC’s firmware assigns the memory address of local variables when they’re declared in the code (as opposed to compile time as before). Variables are allocated and discarded on the stack as needed – users do not need to modify their code to take advantage of this functionality. Programs do still need to specify a variable’s type and size ahead of time however. (i.e. no dynamically sized arrays)

Three different ways to allocate variables.

There is one big difference when it comes to debugging – users will see the old “Variables” display is now split between “Global” and “Local” variables in the ROBOTC Debugger. Because the ROBOTC IDE doesn’t know where the variable will be stored in the “call stack”, there’s no way to accurately know where the local variables are on the stack at any one time. What this means is that you will not be able to view your local variables during run-time like in previous versions of ROBOTC. This is a limitation of professional IDEs (Visual Studio, Eclipse, AVR Studio) that also support recursion and variable stacks. The new extended ANSI-C functionality brings ROBOTC close to the same level as those development environments including the same limitations when debugging.

Hey where are all of my variables?

The good news is that users have two options for debugging their program’s variables:

1. Suspend your program by using the “Step” button– When the program execution is suspended, the IDE is able to display all of the current local variables for the current function/task selected. This will not display every local variable in your program, but only the currently executing function/task.
   

   When the program is suspended, ROBOTC can load the “Call Stack” and display Local Variables accurately.

2. Use Global Variables– Because Global Variables are allocated at compile time, the ROBOTC IDE knows the memory location of every Global Variable and can keep track of these variables in the “Global Variables” debugger window. All Global Variables will be continuously updated as the program is executed.
   

   With Global Variables, ROBOTC know the address of the Variable at all times, so it is able to always display the value.

We understand some of the frustration that ROBOTC users are experience with the new ROBOTC 3.5 update with all of the new functionality, and we apologize for any issues. Our overall objective is to make ROBOTC as close to a true ANSI-C programming environment to make sure students and users are learning proper coding techniques.

As we continue to refine our implementation with the latest version of ROBOTC, we still are committed to addressing any reported issues and would love to hear from you if you are having any problems – Please send us a note using our Ticketing system at http://www.robotc.net/support/ or directly at support@robotc.net.

In February 2011, the Robotics Academy released our first version of Robot Virtual Worlds (RVW). Back then, we were striving to make a new educational breakthrough that would allow kids using the motivational effects of video games and robotics combined to learn all about programming. Users are able to program virtual robots using the exact same programming language that they used to control their real robots – they could work with a robot at school and then go home to continue their education using our unique simulation engine!

Since that initial release, we have learned an incredible amount about robot simulations, game development, and our customer’s expectations and desires. Since our initial beta release in February and our retail release in September of 2011, we have made great improvements that provide a much richer overall experience. Some of these new features include:

• Improved Robot Physics and Gameplay
• New and Improved Sensor Simulation
• Completely new robot models with new features such as gripper arms and elevator lifts.
• More “game” like worlds with real-time scoring and open ended challenge
• CS2N.org integration for earning achievements and badges
• Education tools like user tracking (via CS2N) to keep tabs on student progress

Today we’re announcing an extended free trial opportunity for everyone to try our latest Robot Virtual Worlds software until the end of the year. This extended trial is available to everyone, including those users who have already used their initial 60-day trial included with the Robot Virtual Worlds software. This extended trial will allow you to try Robot Virtual Worlds until the end of 2012. Our hope is that you’ll give our updated worlds a test drive and see the incredible improvements we’ve already made and continue to make every day. To find out how to download your free extended license, take a look below.

Steps for NXT Users to use the FREE license:

1. Install/Update to the latest version of ROBOTC (Currently 3.51) http://www.robotc.net/download/nxt/
2. Download the special extended LEGO trial license. This file will allow the Virtual Worlds to work until December 31, 2012 and can be installed on an unlimited number of computers at school or at a student’s home. This license WILL work even if your ROBOTC trial is already expired http://www.robotc.net/files/RobotVirtualWorlds_LEGO_InstallLicense.exe
3. Make sure ROBOTC is closed and run the installer for the extended trial license. This installer will automatically install and activate the extended trial.
4. To learn how to access the RVW once they are installed go to: http://www.robotc.net/download/rvw/step2a-setting-up-rvw.php

Steps for VEX Users to use the FREE license:

1. Install/Update to the latest version of ROBOTC (Currently 3.51) http://www.robotc.net/download/cortex/
2. Download the special extended VEX trial license. This file will allow the Virtual Worlds to work until December 31, 2012 and can be installed on an unlimited number of computers at school or at a student’s home. This license WILL work even if your ROBOTC trial is already expired. http://www.robotc.net/files/RobotVirtualWorlds_VEX_InstallLicense.exe
3. Make sure ROBOTC is closed and run the installer for the extended trial license. This installer will automatically install and activate the extended trial.
4. To learn how to access the RVW once they are installed go to: http://www.robotc.net/download/rvw/step2a-setting-up-rvw.php

The Curriculum Companion is designed for computer science and robotics classes. This product includes over 30 tabletop type classroom activities that mirror the activities found in the ROBOTC for MINDSTORM and ROBOTC for VEX Curriculums. Students can pick from several robot types. Students earn badges as they complete the RVW challenges that can lead to them earning a Robotics Academy Robotics Programming Certification.

The LEVEL Builder allows students and teachers to design their own levels. This initial product gives the level designer a 12’ by 12’ pallet to design on and uses existing models found in the curriculum companion. By this spring, students will be able to import their own models using standard modeling software. Eventually, our goal is to enable students to build their own robots and import them into RVWs!

Palm Island is a fantasy world where students can practice basic behavior based programming. This world is simple but interesting. The first level involves moving straight, second level turning, third level combining straight and turning… The world is designed so that students can practice simple behaviors to complete the challenge. Students should complete lessons in the movement section of the curriculum before they attempt Palm Island.

RING IT UP simulates this year’s FTC game. Ring It Up provides a game-like environment where students program TETRIX robots to solve game. The game keeps track of time and as your students play the game their scores are tracked. Students can program the robot’s wheels, arm, elbow, and gripper. The game simulation also features an automatically configured IR beacon so that students can test their IR beacon code.

SACK ATTACK simulates this year’s VEX Robot Game. Sack Attack provides a game-like environment where students program VEX robots to solve game. The RVW simulation keeps track of time and score as the robot competes in the game. The new game allows programmer to program the robot’s wheels, arm, elbow, and gripper. The game simulation also allows remote control.

Ruins of Atlantis is an underwater world where students can practice basic behavior based programming. Students collect jewels and coins in this game as they work through an underwater maze. The game includes our first underwater robot! Students should understand basic ROBOTC programming before they attempt to solve the game.

Operation Reset! We will release the third edition of Operation Reset in October of 2012. This is the most game-like world we’ve ever released. Students are required to program or remotely control robots on Planet H99. The colony was just hit by an intergalactic storm and all of the satellite communication towers need reset. The robots are also tasked to collect unobtanium, refuel a rocket, and solve a variety of unanticipated events.

We’ve just produced an exciting video that shows off the new RVW Level Builder! Check it out to see how easy it is to get started with the powerful new software.

Download the initial version of the software, here. For more information on the Level Builder, visit this page.

The ROBOTC Development team is proud to announce an update to ROBOTC  - Version 3.51 for the LEGO Mindstorms, VEX Cortex and PIC, Arduino, and Robot Virtual World platforms is now available! The new ROBOTC 3.51 update is free-of-charge for ALL existing ROBOTC 3.0 license holders. This build fixes a number of the issues reported by end users – A full change log is below.

Change log for ROBOTC 3.51 (since version 3.50):

• Change joystick button commands to return a short to avoid “int == bool” comparison warning.
• Incorrect calculation of “sizeof” operator for ‘call by reference’ variables. Was returning the size of a single pointer rather the the size of the item!!
• Prevent crash when downloading header file to Emulator.
• Fixed bug in Tetrix motor encoders not reading correctly.
• Update File I/O intrinsic definitions to fix issues with string parameters.
• Operator precedence was changed so that it was all left-to-right order when precedence is equal. Except the assignment operators — +, ++, -+, *=, … are evaluated right-to-left.
• Trinary — improved calculation of expression type to avoid allocating a temp string variable when both true and false sides are “char *”.
• Update “motors and sensors setup to re-enable “encoder equipped” check box for Tetrix 12V motors.
• Add a separate string for “standard models” directory that is different from “sample programs” directory since TETRIX shares the sample programs with NXT but has a different standard models directory.
• Fix issue with VEX LCD assignment. If two ports are inadvertently assigned to VEX LCD only one is active. But removing assignment from inactive port was wiping out the mapping for the active port. Now when second port is assigned, any existing assignment on another port is changed to “uart none”.
• Code generation for char string on platforms that don’t support constant pool was not working right. e.g. “display const char string on VEX PIC LCD” was not working. Compiler was incorrectly attempting to store the string constant into the “constant pool” even through the result value was never used. Fixed.
• Debugger “Task Status” window was incorrectly trying to read address of “variable stack” from VEX PIC. VEX PIC does not support ‘variable stack’ and instead stores everything in global variables (and hence has no recursion). Fixed.
• Prevent IDE crash when trying to format an invalid property.
• Emulator was not automatically stopping motors for NXT and TETRIX.
• Improve definition of the two different enums for “LCD buttons” to make differences clear.
• Create compiler error when negative value is specified for size of array bounds.
• Fix bug introduced with “Matrix Controller” support when servo index name to numeric mapping is incorrect.
• Add new NXT high speed write function to write a single char. Previous opcode only wrote a pointer to an array of bytes and you had to specify the number of bytes to write.
• Tetrix Servo controller — hold servos on user program stop – variable was not working as expected – now fixed.
• Correct intrinsic definitions for ‘nxtWriteRawHS’ and ‘nxtReadRawBluetooth’.
• Cast of “(string *)” was incorrectly calculating the nested “*” level. E.g. “(string *) (char *)” was calculated as if it was “**” (double pointer) rather than “*” (single).
• Prevent IDE crash when closing file from ‘X’ on top right of main frame and debugger is open; the debugger should also be closed at same time. NOTE: Debugger was closed if you used the “Close” command on the file.
• Add code to generate compiler errors for mix of ‘*’ and ‘array index’ in a single expression.
• Add compiler error when trying to dereference (‘*’) an expression that is not a pointer.

The ROBOTC Development team is proud to announce that ROBOTC 3.50 for the LEGO Mindstorms, VEX Cortex and PIC, Arduino, and Robot Virtual World platforms is now available! The new ROBOTC 3.50 update is free-of-charge for ALL existing ROBOTC 3.0 license holders. Download today and try out all of the new features and enhancements available in ROBOTC 3.50!

Change log for ROBOTC 3.50 (since version 3.08):

MAJOR UPDATES:

• Full ANSI-C support to support pointers, recursion, and stacks with an updated compiler and updated robot firmware.
• New and Updated Debugger Windows:
  • “Local Variables” to monitor variables in the current task or function.
  • (Note: Local variables are only available when your program is suspended)
  • “Global Variables” to monitor variables available to your entire program.
  • “Call Stacks” to monitor function calls in the currently selected task.
• Updated Documentation and Wiki (www.robotc.net/wiki) – Constantly Updating!
• Support for Standard C commands – sprintf(), sscanf(), support for character arrays, unsigned variables, etc.
• Support for the Arduino family of controllers (Uno, Mega, Mega 2560) with future support and expanded functionality for the Arduino Leonardo and Due controllers.
• Updated Robot Virtual Worlds support to include additional sensors and motors.
• Improved Robot Virtual Worlds performance to simulate more realistic physics and robot behaviors.
• Support for the new MATRIX building system with the NXT.

Robot Specific Fixes:

• NXT I2C sensors were incorrectly initializing clock and data lines as outputs when first configuration. They were correctly left as inputs after first message was sent. Change was to initialize as inputs. Before change, the first I2C message on an empty port will incorrectly appear to succeed.
• Ignore HiTechnic Textrix Motor Controller spurious encoder counts. I.E. if encoder value read is hex ‘FF80xxxx’ then force a reread. Always accept the re-read value.
• Eliminate Z-Axis from VEX joystick window as is unused.
• Arduino boards now support controlling LEDs from PWM pins.
• Arduino boards now will read zero when connecting analog to ground.

Interface Updates/Fixes:

• Add “Show Current Program Counter” button to Debugger.
• Add new template for “New File”. All new programs will start with a task main structure. This template can be modified by the user (it lives in  /Sample Programs/Platform/Templates)
• Always force “Save As” for all template files. Before the files were being saved in a default directory.
• Allow any serial port to be used with VEX PIC systems.
• Allow user entered blank (empty) lines before first “#pragma config(” lines. Currently generates a compiler error.
• Improve placement of related compiler generated errors to appropriate line numbers.
• Fix bug where “Motors and Sensors Setup” did not work on empty files.
• Properly restore floating “Debugger Panes” when Debugger is invoked.
• Changed Checkmarks to Radio Icons for many menu items. This shows a “dot” instead of a “check mark” in the menu icon field.
• Created tooltip strings in resource file for all missing commands.
• Prepare to add two new Debugger panes to display “Breakpoints” and “Bookmarks”. Based on the existing “Compiler Errors” pane architecture. The new panes are displayed but the content is still empty.
• Better synchronization of breakpoints between “Source File” and “Disassembly Listing”. Previously when breakpoint was added/removed in one window the corresponding change was not properly made in the other window. Now the breakpoint ICONs are always refreshed whenever a window is “Activated” (i.e. made topmost).
• Add two new menu commands for “increase indent” and “decrease indent”.
• Tweak “auto close breakpoint hit” message box implementation. Add a check mark to the dialog.
• Add new “Compile OR Compile+Download” toolbar.
• Debug “Task Status” window — minor enhancements.
• FONT name was not being updated in Preferences “Font” tab correctly. Fixed.

Compiler and Command Updates/Fixes:

• Pointer support. New functions positioning for improvements in the dereference (“*”) and address of (“&”) unary operators.
• New “#pragma debugWindows(…)” to specify a list of Debugger Windows that should be opened.
• Add new intrinsic function “DebugStreamClear” to allow programs on robot to clear the debug stream.
• Support for “Implied Pointers” in functions.
• Fixed compiler priority for binary and unary versions of ‘&’, ‘*’, ‘+’ and ‘-’ operators.
• Support for unsigned longs.
• Add new intrinsic function for “round”.
• Added support for ‘atan2′.
• Allow ‘struct’ pointers as valid function return types.
• Fix issue in ‘struct’ declaration causing a random memory overwrite in ROBOTC IDE.
• Support pointer variables for ‘++’ and ‘–’.
• ‘sizeof’ operator now accepts argument types of ‘char’, ‘short’, ‘long’, ‘float’, …
• Fix bug in evaluating “complicated” / compound constant expressions in “#if”.
• Add support for ‘%p’ format code in ‘sprintf’.
• Improve code generation for pointer references to ‘struct’.
• Added doubly nested ‘->’ operator.
• Fixed bug in unary ‘-’ VM opcode.
• Improve code generation for structure element access.
• Fix implementation of structure element access code generation; i.e. the “.” operator.
• Partially re-implement “sizeof” operator for proper calculation of ‘pointer’ and ‘reference’ variables.
• Add “drop down toolbar button” to “Compile and Download” toolbar to select “Download + Compile” or “Compile” only; vs two separate buttons.
• Add partial support for new download “write to RAM” message. Needed for new “local variables” window.
• Add support for new “trinary opcodes” (+, – and *) with ‘long’ operands. Previously trinary opcodes were for ‘short’ variables. Trinary opcodes are primarily used for efficient code generation for array and structure element access.
• Added definition for new “NoOp” command.