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.

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.”

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.

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.

The ROBOTC Development team is proud to announce thatROBOTC 3.5 for the LEGO Mindstorms, VEX Cortex and PIC, Arduino, and Robot Virtual World platforms will be available on September 7^th, 2012. The new ROBOTC 3.5 update will be free-of-charge for ALL existing ROBOTC 3.0 license holders. Download a Beta version (3.45) today to get a sneak peak at all of the new features and enhancements available in ROBOTC 3.5!

ROBOTC 3.5 has a number of new features and enhancements:

• 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) – Still in progress!
• 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.
• Many general enhancements and bug fixes – more in-depth change log to come with the ROBOTC 3.5 official release.

Please remember that the Beta available today should not be installed across entire school sites–this is a beta version, so install at your own risk!

You can participate in the ROBOTC 3.45 Beta version by downloading a copy here. Please note that the Beta version will uninstall your existing version of ROBOTC; the Beta will use your existing licensing so there is no need to ‘Deactivate’ before installing. If you have any issues/questions with the ROBOTC Beta, please e-mail betasupport [at] robotc [dot] net for assistance and to alert us of any issues to be fixed between now and release day.

Close up of the ‘Scaredy Bot’. Note the two VEX Light sensors side by side that provide the control for the robot’s movement.

YouTube Direct Link 

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.

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.

YouTube Direct Link 

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!

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.

The RC cars for the Arduino guided project to convert an RC car into a robot have arrived.

We tried to select cars with various features, sizes, prices, and body designs in an attempt to get a good sample of the insides of RC cars. In the end we selected the following six RC cars.