ROBOTC.net Blog  

While scouring Vimeo a couple weeks ago, I came across a “Vimeo Staff Pick” time-lapse video featuring beautiful landscapes, lakes, mountains, and skies called “Hdr Skies.” When looking in the description for more details, I noticed that ROBOTC was listed! I sent the creator, Tanguy Louvigny, an email to learn more about his process with ROBOTC and time-lapse photography. He was nice enough to answer some questions for us …

- When did you start using ROBOTC?

I started using ROBOTC some 3 years ago, when I started my TETRIX based time-lapse rig project.

- What made you decide to program your time lapse rig with ROBOTC?

Version 2 of my rig used three motors to move the camera on three different axis, and was thus more complex to program. That’s when I decided I needed something more convenient and powerful to be able to control the TETRIX encoders and synchronize the motors with the camera shots. ROBOTC was the solution to my problems and worked like a charm.

- What did you use to build your rig?

My goal with this project was to construct a motorized base for my camera to add movement in my time lapse clips. The first, one axis version of the rig simply used a LEGO MINDSTORMS NXT 2.0 kit to support the camera. For version 2, I needed more robust parts and powerful motors to be abled to sustain the weight of new and bigger cameras, so I went for a TETRIX kit that I would couple with the MINDSTORMS brick to control the motors.

- How long was this video in production?

The ”Hdr skies” video was a compilation of one year of time lapse shots. Since then, as I shoot more, I try to achieve a new video every six months or so.

- How has your experience been with ROBOTC?

I had a great time programming with it, I already knew a bit of C, so I found it very easy and natural to use, in fact so simple I was rapidly able to code all my ideas with ease!

- Do you have any other projects coming up that you are using ROBOTC with?

My next project is a new TETRIX based five axis rig using a motorized jib. I’ll use ROBOTC to control the motors and build a new MINDSTORMS interface to program the moves. I’m also exploring new possibilities to use ROBOTC to fire the camera directly, thus simplifying the robot/camera synchronizing part.

Tanguy also mentioned that all his time lapse videos are made with the rig.

Thank you so much Tanguy for sharing your awesome project! Do you have a cool projects that you created using ROBOTC? If so, let us know! We’d love to feature it here.

The ROBOTC team is happy to announce the ROBOTC 3.59.0 BETA release. We’ve made a number of enhancements and repaired a number of user issues. Some of the major updates are:

• Added support for proxy server when activating ROBOTC.
• Add watchdog timer support to VEX Cortex to alleviate processor crashes that can occur with static.
• Fixed a bug in the NXT color sensor that now allows you to read individual RGB values.
• Updated with the latest version of the 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.

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.

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]

You guys really have to watch this one. It’s made by one of our very talented users on the forums, nicknamed “shep”. It’s an arm that’s based off of the flexpicker industrial arms that you see on assembly lines. Here’s the video:

YouTube Direct Link 

Here’s shep’s description:

This robot is based on the ABB Flexpicker industrial pick and place robot. It uses four NXT microcontrollers with various Lego sensors and motors. It is very easy to program, each position uses an array element containing 3 motor positions, 3 motor speeds and an action such as grip, release or pause. I can easily teach it to pick anything up as long as it can reach it and it will fit into the end effecter. The robot is programmed using RobotC 1.45.

Good job Shep!

The Robotics Academy is proud to announce the arrival of ROBOTC for Mindstorms 2.0. This new version of ROBOTC is coming almost a year after the release of ROBOTC for Mindstorms 1.40. ROBOTC 2.0 adds a lot of new feature and functionality to the popular programming language for LEGO NXT robots.

ROBOTC for LEGO MINDSTORMS is a ANSI-C based programming language for the MINDSTORMS NXT and RCX robotic systems. ROBOTC offers users a common programming language across different popular robotic platforms; with a unique powerful run-time debugger that give a user complete feedback on all input, outputs, and variables in their programs.

Read the rest of this entry »