ROBOTC.net Blog  

We ran into Paul Utley from Pitsco at the 2013 FIRST Championship who designed a model of the Curiosity Rover with TETRIX parts, NXT brick, and programmed in ROBOTC! We were lucky enough to get a short interview with him about it. Check it out here …
 
 
 
 
 
 
 
 

When it comes to setting up any new robot, the age-old saying ‘knowledge is power’ tends to ring particularly true. This is why one can find a variety of beginner guides already available, such as the Video Curriculum Trainer and the ‘Getting Started with NXT and TETRIX’ ROBOTC wiki guide. There’s no such thing as too much knowledge, though, and the more tools a roboticist has at their fingertips the higher their chance for success.

Because of this, we are pleasantly surprised by the depth of content covered by Avi, aka TheProgreammerDude’s YouTube tutorial video. Avi is a member of FTC team 5773. Not only is his tutorial straight from the screen of an FTC team programmer, it focuses on ROBOTC programming concepts specifically for the FTC competition (such as using competition templates and setting up a TETRIX robot using the Motors and Sensors Setup window).

If you’re looking add this video set to your ROBOTC toolkit, be sure to check out the first video in his series.

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!

In years past, the science and art fields were generally considered to be diametrically opposed; if something was scientific it usually didn’t have artistic value, and if it was a work of art it probably didn’t do much for the scientific community. Recently, though, the line between art and science has been blurred and blended in some very unique and interesting ways.

A prime example of this is a color-sensing “Coltar” made by Youtube user PhilippLens. By mixing imagination with ingenuity, PhilippLens created the hybrid guitar using a LEGO Mindstorms NXT brick with a color sensor and two touch sensors (one on the Coltar itself, the other on the ‘pick’). Using the touch sensors to control chords and the color sensor to control which notes are being ‘strummed’ allows the Coltar to emit a surprisingly large range of notes.

YouTube Direct Link 

For more information on this cool project, check out Philipp’s Reddit post. You can also download the code here.

The NXT X-Y axis plotter showcasing some simple shapes it drew.

When you think of a printer, what images come to mind? Generally, printers are considered necessary but frustrating (Office Space, anyone?) pieces of office equipment and like most other cubicle furnishings they are usually pretty boring.

Not so much anymore.

McNamara has yet again created something functional yet stylish, this time by turning an NXT and some Mindstorm parts into a surprisingly accurate X-Y axis plotter. Quite possibly the coolest thing about the plotter, though, is that (taken from McNamara’s blog) “An X–Y plotter is a plotter that operates in two axes of motion (“X” and “Y”)… The term was used to differentiate it from standard plotters which had control only of the “y” axis, the “x” axis being continuously fed to provide a plot of some variable with time.” This mean that the pen itself moves in both the X and Y directions (technically it moves in all 3 axis of motion, but the Z axis doesn’t come into play on this plotter, except to move the pen on and off the dry-erase board) and that the table stays in a static position; very cool.

Don’t take our word for it though; check it out on McNamara’s blog (complete with pictures, video, code, and building instructions)!

Simon Burfield, a.k.a. Burf has made a super cool model.  By model I mean chair and by chair I mean omnidirectional wheelchair. Oh and it’s life-sized, too.  Yeah, it is capable of handling no less than 90 kg!  I saw a video of an early prototype a few weeks ago but this new one is even better-er!

Some facts:

• It uses 7 Mindstorms bricks. One for controlling and 6 that are used for moving.
• Each driving NXT has two motors attached to it.  I presume that a third motor would probably be pushing it when it comes to providing current.  It’s not easy to push that much LEGO and human meat around.
• The master NXT has 4 touch sensors connected (forward, back, left and right) and 2 motors to switch on the drive touch sensors.
• It uses Rotacaster’s omniwheels to make it possible to move in any direction (except up, of course).
• It is programmed in ROBOTC (of course)

Here’s one of the videos he made:

YouTube Direct Link 

Isn’t this awesome? Go check out the other pictures and videos on the original article page: [LINK]. [via BotBench]

This project was submitted by ROBOTC user Michael B. He uses an NXT robot equipped with a HiTechnic EOPD (Electro Optical Proximity Detector) to determine the robots surroundings and then intelligently create and navigate a path through the maze maze.

From the creator:

It shows a robot solving a maze very similar to the micro mouse challenge. It’s an excellent application of 2D arrays. It’s also the most accessible task I could conceive of that would require students to build robots that remembered stuff about their surroundings, related that information and build on it, and then use that information to make intelligent decisions.

Here’s video of the Macro Mouse in action, with lots of additional detail:

NeXT-Generation, over on the ROBOTC forums, posted a very cool project he’s been working on for the last two months.  It’s an automated brick sorter made with a combination of Mindstorms NXT, Power Functions and Pneumatics.

YouTube Direct Link 

The video might be long but it’s well worth watching!

Naturally, we asked him questions about his creation:

What motivated you to make this?

I wanted to build a robot that was interactive and would entertain smaller kids, and be mechanically interesting to older ones, and even adults. Here’s what happened: I planned for it to be able to “learn” where the colors were supposed to go. You could tell it if it put the brick in the right or wrong area until it learned where they all belonged. But, mechanical glitches in the construction that I didn’t have time to fix prevented that from happening. I probably would have made another console with the other NXT with the yes/no buttons, and it could make sounds and use the display to interact.

How long did it take?

Well, if you count total time it’s been built, about two months. But, now here’s the catch: I’ve really only been working on it for about one month, because I got sick twice over the last two months, so in total I was out of it for about a month. During that month I was also working on other stuff. Probably about a week was lost to messing with my Boe-Bot and Pololu 3Pi.

Do you have any plans for future improvements or modifications?

I plan to revisit the same kind of concept, but with no deadline so that I can work out any problems that come up.

What is the average air speed of a laden swallow?

The average airspeed of a laden swallow is 42.

A very cool project, indeed!

Ever wanted to plot your path on a roadtrip or walk through the woods? Wanted to see where your robots went while you were asleep?

Dexter Industries has just made it super easy to do this and even more with ROBOTC using their dGPS sensor for the LEGO Mindstorms NXT!

The dGPS Sensor is $105.00 and is available from Dexter Industries.
Note: ROBOTC users can save 10% by typing in “robotcdgps” (without quotes)  in the coupon code area at checkout and receive 10% off the price of the dGPS until March 1st, 2011!

Using ROBOTC, the NXT and the dGPS sensor, you can download the included sample program program, drag it all over the earth, and then snap! open the file in Google Earth and see where you went.  In five easy steps:

1. Download and send the sample program to your NXT.
2. Attach the dGPS sensor to sensor port #1 and wait until it gets a signal.
3. Start the program and proceed to wander around.
4. Stop roaming. Connect your NXT back to your computer and using the NXT’s File Management dialog  (Robot – NXT Brick – File Management), download the file “Path.txt” to your desktop.
5. Rename the file to “Path.kml”.  Double click the file to open with Google Earth and…  Voila.

Here’s a short video produced by the guys over at Dexter Industries showing off the cool new technology: