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.

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.

A few months ago Parallax, makers of the popular STAMP microprocessor, released a new Board of Education (BoE) Shield for the Arduino. With ROBOTC for Arduino in the beta stage and a full-fledged release on the near horizon (expected third quarter 2012), the friendly folks at Parallax were kind enough to send us one of their Robotics Shield Kits (for Arduino) to prototype and test with.

Top and bottom views of Board of Education for Arduino. Note the header spacing on bottom side.

The kit includes a full Boe-Bot kit, an BoE Shield for Arduino, a Boeboost module, and a bag of basic electronic components (resistors, capacitors, microswitches, etc). In order to get the kit completely up and running, users will also need a compatible Arduino, a USB A to USB B cable, a compatible coding program (ROBOTC for Arduino), and either four (five with the BoeBoost) AA batteries or a compatible AC adapter.

From top left clockwise: Boe-Bot kit (we had assembled ours before taking pictures, hence some components being installed); Board of Education for Arduino; hardware kit; Boe-Booster; electronics components kit; Parallax screwdriver.

Once assembled, the Arduino can be programmed in ROBOTC for Arduino. Besides the pin layout and a few minor tweaks (on/off switch for servo power, for example), the Board of Education Shield is functionally  the same as the Arduino platform so programs coded for the Arduino are directly compatible with this kit.

Fully assembled Bot-Bot with Boe-Booster installed.

Even in its early stages, the ROBOTC for Arduino beta supports many of the features needed to code fully autonomous robots (with the applicable sensors installed). It is also continually upgraded and updated so that by the time the full version launches (expected third quarter 2012), users will be able to unlock the full potential of their robotic kits.

Board of Education with Arduino Uno attached.

All in all, this is a solid introductory kit into the world of robotics. Combined with the ROBOTC programming language, it makes for one powerful, flexible, user-friendly platform.

Fully assembled Bot-Bot with Boe-Booster, Board of Education for Arduino, and Arduino Uno installed.

Part Lego, part Arduino, part BoeBot, this is Frankenfollower. This robot was programmed in ROBOTC for Arduino, a port that is still in alpha stage of development but can be used quite nicely for programming the Arduino Duemilenova.  Other Arduino variants will be supported very soon.

The Arduino port of ROBOTC has some really cool features:

• Easy to use sensor and motor configuration UI
• Breakpoints and a debugger
• Ability to watch your variables live
• Multiple tasks (4 at the time of writing)

I’ve taken some pictures of the UI, so you can have a look.  Please note that the appearance of these UIs will probably change before the final version, so keep that in mind.

Main UI with some code (Frankenfollower’s code, actually)	Debugger UI with variables window docked on the right.	First configuration tab. This one allowed you to configure the platform and possible shields (up to 3 at the moment)
Motor and servos are configured here.  Encoders are currently not supported.	Analogue pins are setup in this tab.	Digital pins can be configured as PWM, input and output.

So as you can see, it’s all quite functional at the moment.  I’ve made a small video with some additional pictures of Frankenfollower and some footage of it in action.

I’m sure I’ll expand on Frankenfollower in the next few weeks, so keep an eye out on my blog!

Original article featured here: [LINK].

Hey ROBOTC Community!

We’re currently looking for Alpha Testers to help us work out the kinks in our new ROBOTC for Arduino software.

In order to sign up, we ask if you can spend 5 minutes giving us some information about what kind of Arduinos you have and what your background is. Sometime in the next week, we’ll send out an e-mail to everyone who we’re inviting into our Alpha trials to let them know they made it.

Every person who participates in the Alpha will receive a free copy of ROBOTC for Arduino once it is released.

To sign up, fill out our survey today!
http://www.surveymonkey.com/s/ROBOTCArduino